Re: 2 years student project
Many of the ideas on that page are stale. I believe that the most promising approach would be to figure out what area of the system you're most interested in, e.g. networking, file systems, virtual memory, scheduling etc., make an honest appraisal of your development abilities (the rate at which you can come up to speed working with a large body of code and your ability to read technical documentation), and then contact the mentor for one of the Ideas in your area of interest to discuss how to proceed further. In order to have any likelihood of success you'll need to find someone who is willing to take the time to discuss things with you on a regular basis. I hope this helps. Cheers On Sat, Jan 14, 2012 at 1:38 PM, Matthieu Hauglustaine matt.hauglusta...@gmail.com wrote: Dear all, We are a group of french CS students at Epitech, currently in 3rd year. As part of our formation we have to start working on our end of scholarship project. We will have 2 years to complete this project, and the only obligation we have is to be innovative. The first step is to submit our subject for validation, and this must be done for the end of the month, We would really like to take this opportunity to contribute to the FreeBSD project. Our formation is focused exclusively on the learn by doing it yourself philosophy and we have many projects in different domains behind us (mainly in c and c++). We've spent some time looking around the ideas presented on this page: http://wiki.freebsd.org/IdeasPage. Lots of these projects are extremely interesting and, among others, porting HFS+ and Space Communication Protocol Standards are on our list of potential projects. Maybe their are other unlisted ideas that would be nice student projects while still useful to the community? However, what should be the first move here? Who should we contact? Would someone with more experience in FeeBSD development take the role of mentor? We are hoping for some guidance so we could be as effective as possible. Regards, Matthieu Hauglustaine ___ 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 ___ 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: Where to ask about a 7.2 bug, and debugging sys/queue.h errors
On Thu, Aug 25, 2011 at 11:16 PM, Charlie Martin crmar...@sgi.com wrote: We're having a crash in some internal code running on FreeBSD 7.2 (specifically 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE and yeah, I know it's quite a bit behind) in which after 18-30 hours of running load tests, the code panics with: panic: Bad link elm 0xff0044c09600 next-prev != elm cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0x8019119a = db_trace_self_wrapper+0x2a panic() at 0x80307c72 = panic+0x182 devfs_populate_loop() at 0x802a43a8 = devfs_populate_loop+0x548 First question: where's the most appropriate place to ask about this kind of bug on a back version. Probably -stable. I don't know how many developers are still running 7. Most are on 8 at this point. Second: does this remind anyone of any bugs? Googling came up with a few somewhat similar things but hasn't provided much insight so far. This panic is very common when list updates aren't adequately serialized. Third: I tried compiling with the sys/queue.h QUEUE_MACRO_DEBUG defined in order to get more useful information from the panic. The kernel build fails in pmap.c when this macro is defined, giving an error saying the CTASSERT macro is resolving to a negative array size. Is there any particular secret to using this macro (like, no one goes there any more?) This is because you are running amd64 and the the pv_entry constants were defined assuming the default (smaller) list entry structure. I once fixed this in a local tree, but I think I was so dismayed at the obviousness of the bug I was tracking down that I neglected to commit the pmap update. It shouldn't be too hard to calculate the correct constants. Cheers ___ 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: kernel panics in in_lltable_lookup (with INVARIANTS)
Try this:
Index: sys/net/flowtable.c
===
--- sys/net/flowtable.c (revision 196382)
+++ sys/net/flowtable.c (working copy)
@@ -688,6 +688,12 @@
struct rtentry *rt = ro-ro_rt;
struct ifnet *ifp = rt-rt_ifp;
+ if (ifp-if_flags IFF_POINTOPOINT) {
+ RTFREE(rt);
+ ro-ro_rt = NULL;
+ return (ENOENT);
+ }
+
if (rt-rt_flags RTF_GATEWAY)
l3addr = rt-rt_gateway;
else
You'll need to apply this by hand as gmail munges the formatting.
-Kip
On Fri, Aug 21, 2009 at 16:43, Brian Somersbr...@freebsd.org wrote:
Hi,
I've been working on a fix to address an issue that came up with
our update of openssh-5. The issue is that openssh-5 now uses
pipe() to create stdin/stdout channels between sshd and the server
side program where it used to use socketpair(). Because it uses
pipe(), stdin is no longer bi-directional and cannot be used for both
input and output by a child process. This breaks the use of ssh
as a tunnel with ppp on either end (set device !ssh -e none host
ppp -direct label)
I talked with des@ for a while and then with the openssh folks and
have not been able to resolve the issues in openssh that made them
choose to enforce the use of pipe() over socketpair(). I now have a
patch to ppp that makes ppp detect that it's connected via pipe() and
causes it to use stdin for input and stdout for output (usually it expects
just one descriptor). Although I'm happy with the patch and planned on
requesting permission to commit, I've bumped into a show-stopper
that seems unrelated, so I thought I'd ask here if anyone has seen
this or has any suggestions as to what the problem might be.
The issue
I'm seeing a panic when I send traffic through a ppp link:
panic string is: sin_family 18
Stack trace starts:
in_lltable_lookup()
llentry_update()
flowtable_lookup()
ip_output()
The panic is due to a KASSERT in in_lltable_lookup() that expects the
sockaddr to be AF_INET. Number 18 is AF_LINK.
AFAICT this is happening while setting up a temporary route for the
first outbound packet. I haven't been able to do much investigation
yet due to other patches in my tree that seem to have broken all my
kernel symbols, but once I get a clean rebuild I should be back in
business.
If anyone has any suggestions, I'm all ears!
Cheers.
--
Brian Somers br...@awfulhak.org
Don't _EVER_ lose your sense of humour ! br...@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
--
When harsh accusations depart too far from the truth, they leave
bitter consequences.
--Tacitus
___
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: Debugging via DDB
On Thu, May 28, 2009 at 9:27 PM, David N david...@gmail.com wrote: Hi, I know this might sound like a newbie question. I'm trying to debug a Lockup on 7.2-RELEASE. I've compiled DDB and KDB into the kernel and make installkernel. (Can this be called a deadlock?) The machine still response to pings, but it looks like all disk activity has stopped. I can break into the debugger using CTRL-ALT-ESC, but after that, i dont know what I'm looking for in particular. bt (backtrace) gives me the stuff like the keyboard mutex ( i assume it was the last thing that happened, but obviously it was the break) Should I be including WITNESS? Include WITNESS. ps to list processes, show proc to see proc info, thread no to switch to a thread, show locks to see locks held, show sleepc to see what you're blocked on (if a sleepq), and show alllocks to see all locks held -Kip ___ 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: ZFS ARC Cache: What is the lowest tested size
On Mon, May 4, 2009 at 10:12 AM, Mark Saad ms...@datapipe.com wrote: Hello List Worked on breaking ZFS we came across a interesting question; What is the lowest tested ZFS ARC Cache size ? I haven't tested it with just over 64MB, but the code indicates that that is the lowest you should try. http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/arc.c 3500 /* 3501 * Allow the tunables to override our calculations if they are 3502 * reasonable (ie. over 64MB) 3503 */ 3504 if (zfs_arc_max 6420 zfs_arc_max physmem * PAGESIZE) 3505 arc_c_max = zfs_arc_max; 3506 if (zfs_arc_min 6420 zfs_arc_min = arc_c_max) 3507 arc_c_min = zfs_arc_min; Also could you reliably run with it set to 0 ? For better and worse, ZFS isn't primarily a file system. It is a transactional object store that has a file system as one type of object. The ARC is not a file system buffer cache, it caches virtual device blocks. You might think of it as being more like a very large write-back drive cache. It might work with less than 64MB, but the ARC buffers are what ZIO sends down to disk so it certainly would not work with zero. Cheers, Kip ___ 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: NetBSD 5.0 statistics
On Thu, Apr 30, 2009 at 7:50 AM, Oliver Pinter oliver.p...@gmail.com wrote: Is the FreeBSD's FS management so slow? http://www.netbsd.org/~ad/50/img15.html Or so big is the difference between the two cpu scheduler? http://www.netbsd.org/~ad/50/img0.html We would need more information about the disk hardware, amount of memory etc. to really provide an answer. We've had a lot of difficulties testing against NetBSD in the past because NetBSD wouldn't boot on recent hardware (ACPI issues IIRC). Looking at the processor he is using it would appear that that has probably been fixed. -Kip ___ 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: Linux setpci equivalent in FreeBSD?
man pciconf(8) - it lets you set config space bits
-Kip
2009/4/14 Zahemszky Gábor ga...@zahemszky.hu:
Hi!
I'v found (well, mav@ found it) on a wiki page (*) a trick to use some
TI sdhci cards. They use the setpci command, to set some bits in the HW.
Are there any tool under FreeBSD to do the same?
Thanks,
Gábor at Zahemszky dot HU
(*) http://www.gentoo-wiki.info/Acer_Ferrari_4005WLMi#SDHCI
--
#!/bin/ksh
Z='21N16I25C25E30, 40M30E33E25T15U!';
IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ ';
set -- $Z;for i;{ [[ $i = ? ]]print $ibreak;
[[ $i = ??? ]]j=$ii=${i%?};
typeset -i40 i=8#$i;print -n ${i#???};
[[ $j = ??? ]]print -n ${j#??} j=;typeset +i i;};
IFS=' 0123456789 ';set -- $Z;for i;{ [[ $i = , ]]i=2;
[[ $i = ?? ]]||typeset -l i;j=$j $i;typeset +l i;};print $j
___
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
--
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke
___
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_setup_intr (9)
in HEAD, see intr_event_handle in sys/kern/kern_intr.c Cheers, Kip On Thu, Feb 12, 2009 at 12:31 PM, Alexej Sokolov bsd.qu...@googlemail.com wrote: hello, from man: int bus_setup_intr(device_t dev, struct resource *r, int flags, driver_filter_t filter, driver_intr_t ithread, void *arg, void **cookiep); The function filter returns value of type driver_filter_t (int). This function will run if interrupt happen. Question: Which function will get this returned int value of filter function. Or How/where can I catch it ? Alexej ___ 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 ___ 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: crash at in_pcb.c
The code in 7.0 is actually locked quite differently. Could you please
try and reproduce on 7.0 and RELENG_7?
Thanks,
Kip
On Wed, Oct 29, 2008 at 8:45 PM, Jerry Toung [EMAIL PROTECTED] wrote:
Hello List,
I can realiably reproduce this crash. We have a deamon that accept several
connections
per sec. We use iperf and Microsoft Web application stress 1.0 to push
traffic to the FreeBSD box.
Without further delay, the crash dump is below. I've been troubleshooting,
but I am no longer sure
if this is a race condition or a stack corruption. The socket pointer
between frame 12 and 11 is different.
This is on 6.2, but the code for 7.0 is identical, so I think it still
applies.
Any hint, patching or troubleshooting this is appreciated.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x2aef0210
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0769098
stack pointer = 0x28:0xef781bc0
frame pointer = 0x28:0xef781bd0
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 = 1166 (ndaemon)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 8h32m25s
Dumping 3325 MB (3 chunks)
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) l *0xc0769098
0xc0769098 is in in_pcblookup_local (/usr/src/sys/netinet/in_pcb.c:923).
918 /usr/src/sys/netinet/in_pcb.c: No such file or directory.
in /usr/src/sys/netinet/in_pcb.c
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc06c2812 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:412
#2 0xc06c2bbd in panic (fmt=0xc0940872 %s) at
/usr/src/sys/kern/kern_shutdown.c:573
#3 0xc08f3e4e in trap_fatal (frame=0xef781b80, eva=720306704) at
/usr/src/sys/i386/i386/trap.c:838
#4 0xc08f3b57 in trap_pfault (frame=0xef781b80, usermode=0, eva=720306704)
at /usr/src/sys/i386/i386/trap.c:745
#5 0xc08f3745 in trap (frame=
{tf_fs = -277348344, tf_es = 40, tf_ds = -913309656, tf_edi = 6,
tf_esi = 0, tf_ebp = -277341232, tf_isp = -277341268, tf_ebx = -1062683820,
tf_edx = 720306704, tf_ecx = 14063, tf_eax = 720306704, tf_trapno = 12,
tf_err = 0, tf_eip = -1065971560, tf_cs = 32, tf_eflags = 66050, tf_esp = 0,
tf_ss = -1062683820}) at /usr/src/sys/i386/i386/trap.c:435
#6 0xc08dddba in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc0769098 in in_pcblookup_local (pcbinfo=0x2aef0210, laddr={s_addr =
0}, lport_arg=720306704, wild_okay=1)
at /usr/src/sys/netinet/in_pcb.c:923
#8 0xc0768452 in in_pcbbind_setup (inp=0xc97150b4, nam=0x36ef,
laddrp=0xc97150ec, lportp=0xc97150ce, cred=0xc8726780)
at /usr/src/sys/netinet/in_pcb.c:464
#9 0xc0767f56 in in_pcbbind (inp=0xc97150b4, nam=0x2aef0210,
cred=0xc8726780) at /usr/src/sys/netinet/in_pcb.c:240
#10 0xc077f272 in tcp_connect (tp=0xc9897000, nam=0xc98a1ba0, td=0xc990e180)
at /usr/src/sys/netinet/tcp_usrreq.c:864
#11 0xc077e141 in tcp_usr_connect (so=0xc9897000, nam=0xc98a1ba0,
td=0xc990e180)
at /usr/src/sys/netinet/tcp_usrreq.c:369
#12 0xc06fec4e in soconnect (so=0xc97b39bc, nam=0xc98a1ba0, td=0xc990e180)
at /usr/src/sys/kern/uipc_socket.c:558
#13 0xc07046a8 in kern_connect (td=0xc990e180, fd=89, sa=0xc98a1ba0) at
/usr/src/sys/kern/uipc_syscalls.c:536
#14 0xc070460f in connect (td=0xc990e180, uap=0xef781d04) at
/usr/src/sys/kern/uipc_syscalls.c:505
#15 0xc08f4193 in syscall (frame=
{tf_fs = 135725115, tf_es = 59, tf_ds = -1088487365, tf_edi =
135745024, tf_esi = -1089511444, tf_ebp = -1089514536, tf_isp = -277340828,
tf_ebx = 671753396, tf_edx = 0, tf_ecx = 135524256, tf_eax = 98, tf_trapno =
0, tf_err = 2, tf_eip = 674451435, tf_cs = 51, tf_eflags = 642, tf_esp =
-1089514580, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:984
#16 0xc08dde0f in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:200
#17 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) f 7
#7 0xc0769098 in in_pcblookup_local (pcbinfo=0x2aef0210, laddr={s_addr =
0}, lport_arg=720306704, wild_okay=1)
at /usr/src/sys/netinet/in_pcb.c:923
923 in /usr/src/sys/netinet/in_pcb.c
(kgdb) i loc
phd = (struct inpcbport *) 0x2aef0210
tmphd = (struct inpcbport *) 0x2aef0210
match = (struct inpcb *) 0x0
inp = (struct inpcb *) 0x2aef0210
tmpinp = (struct inpcb *) 0x2aef0210
matchwild = 6
wildcard = -1062683820
lport = 14063
(kgdb) p phd
$1 = (struct inpcbport *) 0x2aef0210
(kgdb) p phd-phd_port
Cannot access memory at address 0x2aef021c
(kgdb) f 12
#12 0xc06fec4e in soconnect (so=0xc97b39bc, nam=0xc98a1ba0, td=0xc990e180)
at /usr/src/sys/kern/uipc_socket.c:558
558 /usr/src/sys/kern/uipc_socket.c: No such file or directory.
in
new mailing list for xen
I've been getting a lot of recurring questions about the status of Xen support in FreeBSD and Xen configuration issues - the answers to which are changing frequently enough that simply adding a FAQ wouldn't make sense. I expect that initially the mailing list will be the Dailykip, consisting of regular updates about enhancements combined with a steady influx of bug reports and configuration questions. If you're planning on testing out FreeBSD on Xen, please subscribe to freebsd-xen. Cheers, Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sun4v arch
Hi Peter, There really isn't any magic to bringing up a port. You compile it, install it, and then run it until it breaks. Once it breaks you spend a lot of time instrumenting the code to track down what went wrong. Then, depending on the amount of technical insight you have in to the issue, you go through a number of iterations until it is fixed. Fixing the pmap issue is just (notice the quotes) a matter of tracking down the missing TLB shootdowns. For anyone who chooses pick this up it will be very educational. It will also be very time consuming. -Kip On Sat, Aug 23, 2008 at 9:23 PM, Peter Jeremy [EMAIL PROTECTED] wrote: On 2008-Aug-23 22:40:55 -0500, Mark Linimon [EMAIL PROTECTED] wrote: My understanding is the the port is in a pre-alpha state due to unfinished work in the kernel, so expecting there to be any userbase is premature. Except that the wiki gives a far more optimistic picture. All of our 'new' architectures which are in this state have so few non- developer users that there is hardly any reason to submit PRs. AFAICT the active developers already know what's missing :-) That makes it very difficult for someone outside that group to come up to speed. I can't find anything in the freebsd-sun4v archvies. I was hoping that there would be a list somewhere of what state various subsystems were in and what remained to be done. wiki.freebsd.org sounds like the ideal place for this. On 2008-Aug-23 20:39:29 -0700, Garrett Cooper [EMAIL PROTECTED] wrote: Maybe some time should be spent looking at stuff from NetBSD to see whether or not they've solved some already critical porting pieces that FreeBSD lacks in this architecture? I can't find anything that suggests NetBSD runs on sun4v. Their sparc64 port only covers the US-I/II families and there's no mention of sun4v. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sun4v arch
On Sat, Aug 23, 2008 at 9:34 PM, Sevan / Venture37 [EMAIL PROTECTED] wrote: I can't find anything that suggests NetBSD runs on sun4v. Their sparc64 port only covers the US-I/II families and there's no mention of sun4v. OpenBSD/sparc64 supports the sun4v architecture has done for a while. Heh. The bugs that FreeBSD exhibits on sun4v won't be hit on UP and are much less prevalent without preemption. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the future of sun4v
Well, let's see what architecture the upcoming Rock CPUs are; judging their feature list they appear to be a continuation of the Fujitsu sun4u line rather than a successor of UST1/2 :) That is not what I've heard. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
request for testers - xen support for domU in head
Basic Xen support for 32-bit in PAE mode is in CVS. Please see the wiki for general information: http://wiki.freebsd.org/FreeBSD/Xen Please be forewarned that I am not claiming that this is production-ready. There are many known limitations. If you would like to take it for a test drive and report bugs please give it a spin. Thanks, Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: request for testers - xen support for domU in head
p Hi Kip, Thanks very much for the effort here. I'm looking forward to trying it out and providing feedback. I'm not really familiar with Xen, but perhaps enough to ask this question: Does this mean that Amazon EC2 will be able to boot FreeBSD instances? The last time I spoke with them they were using 3.0.3 which uses some older interfaces which I don't currently support. Nonetheless, I do intend to support EC2 in the near future. Thanks, Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
the future of sun4v
I apologise for cross-posting. I believe that there is a general expectation by freebsd users and developers that unsupported code should not be in CVS. Although sun4v is a very interesting platform for developers doing SMP work, I simply do not have the time or energy to maintain it. If someone else would like to step up and try his hand I would be supportive of his efforts. In the likely event that no one steps forward by the time that 7.1 is released I will ask that it be moved to the Attic. Thanks, Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xen in HEAD
On Sun, Aug 17, 2008 at 2:48 PM, Eric Masson [EMAIL PROTECTED] wrote: Matthew Macy [EMAIL PROTECTED] writes: Hi Kip, Xen support will be MFC'd when it proves to be sufficiently stable for some uses. It probably won't make the freeze for 7.1. Xen 3.2 is the initial target. Dom0/DomU or DomU only please ? DomU only to start off with. The currently planned progression is: stabilize in HEAD - SMP - x86_64 - dom0 -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with ieee80211 dependencies...
Nothing jumps out at me, can you send the output of the build failure? -Kip On Fri, Jun 27, 2008 at 4:29 PM, Martes Wigglesworth [EMAIL PROTECTED] wrote: I am having a hard time compiling a new kernel when I remove the wireless aspects of the config file. I have removed all options/devices that seem to still require ieee80211 however, I still find that the network section of the compile do not work. I.E. that is where the compile stops, and indicates that an unknown reference to ieee80211 functions... What in the GENERIC config file requires ieee80211? I have included my config file below: cpu I686_CPU ident DATASERVER # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. makeoptions DEBUG=-g# Build kernel with gdb(1) options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates options UFS_ACL # Support for access control options UFS_DIRHASH # Improve performance on big options UFS_GJOURNAL# options MD_ROOT # MD is a potential root device options PROCFS # Process filesystem options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY options SCSI_DELAY=5000 options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI options AUDIT # Security event auditing # To make an SMP kernel, the next two lines are needed # CPU frequency control device cpufreq # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicam# ATAPI emulation? device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. device ahd options AHD_REG_PRETTY_PRINT # output. Adds ~215k to driver. device amd # AMD 53C974 (Tekram DC-390(T)) device hptiop # Highpoint RocketRaid 3xxx series device isp # Qlogic family #device ispfw device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct SCSI access) device ses # SCSI Environmental Services # RAID controllers interfaced to the SCSI
Re: vkernel GSoC, some questions
On Sun, Mar 16, 2008 at 8:06 PM, Adrian Chadd [EMAIL PROTECTED] wrote: On 16/03/2008, Robert Watson [EMAIL PROTECTED] wrote: Another avenue to consider is the Linux KVM virtualization technology, which is seeing a high level of interest in the Linux community and sounds increasingly mature and well-exercised. It would also offer interesting migration benefits for Linux users wanting to try FreeBSD, allowing them to trivially create new FreeBSD installs under their existing Linux install. We had an SoC project last year but I'm not sure what the outcome was; it would be useful to give Fabio a ping and see how things are going. Obviously, anyone doing this project would need to manage the license issues involved carefully. Wasn't part of the original KVM idea to support a hypervisor interface to a parent, sort of Xen-like, providing interrupt, VM and inter-VM IPC hooks? I remember seeing this stuff a while back but for some reason all I read about KVM - outside of what Redhat are doing with it and Xen now - focuses on hardware virtualisation. A BSD-licenced KVM hypervisor + FreeBSD kernel might be an interesting project. I'm pretty sure Rusty wrote a very very lightweight KVM hypervisor as a demonstration which may serve as a starting point for things. Nope. It is called lguest, is GPL, IBM has the rights to it and has no interest in changing the license. Using KVM for architectural ideas while starting from a fresh codebase is really the only way to go if you are concerned with licensing. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mlock COW
On Sun, Mar 9, 2008 at 2:24 PM, Jonathan Chen [EMAIL PROTECTED] wrote:
I've been battling with a bug related to mlock and COW pages. Since I'm
basically clueless when it comes to the VM subsystem, I was hoping someone
with more clue can look at my fix and let me know if I'm doing the right
thing here.
The problem: User programs will crash (SEGV/BUS) if COW pages become
writable after the pages are mlocked. This happens if shared libraries is
loaded in a program after a call to mlockall(MCL_FUTURE), and can be seen
with amd and ntpd when nss_ldap is used in the system. Included at the end
of this message is a sample program that demonstrates the problem.
I think the problem is mlock wires the pages that are backing those
mappings. So you're writing to a page that you don't have write access
to. You're best off ensuring that you have a private copy of all those
pages before mlocking().
The solution: Forcibly wire the page via vm_fault_wire() when the page
protection bits are changed. This seems to make the problem disappear, but
I'm not sure if causing a fault on vm_map_protect() is a good thing to do.
Uhm no. Don't do that.
Am I correct in thinking vm_fault_wire() will cause the COW page to be
copied immediately? I think this is the right thing to do, given the page
is supposed to be wired, but I'm not sure if somewhere in the vm fault
routines might be a better place to put the fix. I'm also not sure what
the last argument to vm_fault_wire() (fictitious) means, I just copied the
argument from another invocation. My patch (against 7-STABLE) is included
below.
I'm not certain what the correct semantics are. You're patch *may* be OK.
-Kip
I'll commit this if someone blesses the fix as the right thing.
Index: sys/vm/vm_map.c
===
RCS file: /home/ncvs/src/sys/vm/vm_map.c,v
retrieving revision 1.388.2.3
diff -u -p -r1.388.2.3 vm_map.c
--- sys/vm/vm_map.c 18 Jan 2008 10:02:53 - 1.388.2.3
+++ sys/vm/vm_map.c 9 Mar 2008 20:55:50 -
@@ -1621,6 +1621,15 @@ vm_map_protect(vm_map_t map, vm_offset_t
current-end,
current-protection MASK(current));
#undef MASK
+ if ((entry-eflags
+ (MAP_ENTRY_USER_WIRED|MAP_ENTRY_COW)) ==
+ (MAP_ENTRY_USER_WIRED|MAP_ENTRY_COW)) {
+ vm_fault_wire(map, current-start,
+ current-end, TRUE,
+ entry-object.vm_object != NULL
+ entry-object.vm_object-type ==
+ OBJT_DEVICE);
+ }
}
vm_map_simplify_entry(map, current);
current = current-next;
bug demonstration code
===
#include unistd.h
#include stdio.h
#include stdlib.h
#include string.h
#include strings.h
#include fcntl.h
#include sys/mman.h
char *b;
int main() {
int fd = open(/usr/lib/libc.a, O_RDONLY);
if (fd 0) {
perror(open);
exit(1);
}
b = mmap(0, 1024, PROT_READ|PROT_EXEC, MAP_PRIVATE, fd, 0);
if (b == MAP_FAILED) {
perror(mmap);
exit(0);
}
if (mlock(b, 1024) != 0) {
perror(mlock);
}
if (mprotect(b, 1024, PROT_READ|PROT_WRITE|PROT_EXEC) != 0) {
perror(mprotect);
}
printf(memset crash now\n);
memset(b, 1, 1024);
printf(still alive\n);
}
-Jon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any 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: IRQ-CPU binding?
It can easily be done, there is no API for it in CVS. -Kip On 1/5/08, Ivan Voras [EMAIL PROTECTED] wrote: Hi, Is there a notion of binding interrupt handlers to specific CPUs in FreeBSD? Is there a way to find out that mapping from the userland, for debugging purposes? -- Sent from Gmail for mobile | mobile.google.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IRQ-CPU binding?
http://perforce.freebsd.org/changeView.cgi?CH=124874 HTH On Jan 5, 2008 4:55 PM, Ray Mihm [EMAIL PROTECTED] wrote: On Jan 5, 2008 12:16 PM, Kip Macy [EMAIL PROTECTED] wrote: It can easily be done, there is no API for it in CVS. I have a situation where this is needed. I would appreciate if you tell me how to do it. Ray. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Architectures with strict alignment?
Isn't it everything except x86? -Kip On Dec 29, 2007 12:11 AM, Erich Dollansky [EMAIL PROTECTED] wrote: Hi, Ivan Voras wrote: Hi, Which of the architectures FreeBSD supports (if any) have strict memory alignment requirements? (in the sense that accessing a 32-bit integer not aligned on a 32-bit address results in a hardware trap/exception). isn't this the case with SPARC and Itanium? I know, they are 64 bits. Erich ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: kqueue and libev
On Dec 17, 2007 1:25 PM, James Mansion [EMAIL PROTECTED] wrote: Kip Macy wrote: he's just plain misinforme Until we know what he is referring to we can't actually say that. -Kip OK he said I could post from our private email so here goes. There were bits in and around relating to the Solaris /dev/poll support (and the mechanism's limitations) which I've elided. I think the most telling thing is probably that drivers need to provide support and that a single mechanism in the driver doesn't support select and poll at the same time - which I guess lines up with the reported failure with USB serial. Does kqueue work with USB for example? How about an AIO request to read from a USB endpoint? It may well just be a case of 'fessing up to system limitations. James Compile and install rxvt-unicode on freebsd and run it with: urxvt # works, uses select (or maybe poll) LIBEV_FLAGS=8 urxvt # acts weird, uses kqueue (note: only works when urxvt isn't set[gu]id) The typical symptoms are either delayed notificatrions, no notifications at all or _continuous_ notifications and read failing with EAGAIN. Here is a ktrace showing the latter: http://ue.tst.eu/45eb8a3c3e812933cbe3172af2ee4a6c.txt kqueue works well with sockets (or with about anything on netbsd), but fails on more exotic types such as ptys. (I test on Freebsd 6.2 RELEASE, but got reports about problems with earlier and later versions, too, as well as on openbsd (which I didn't verify) and on darwin (which is completely broken)). You normally don't get useful writeable/readable state for files, No, I only want the same readyness notifications as with select or poll, as is documented in the manpage. (even on platforms where kqueue works this requires some heuristics and workarounds with kqueue due to design limitations (for example problems with close() or fork() that force constant rearming), but thats common in interfaces like kqueue, and by now well understood and handled by libev). Actually, until recently it was broken on pipes. We've never received any PRs to that effect so there is no way of knowing. You'll have better luck asking the author himself. To be more precise, this only manifested itself in erlang. Well, one should better document the types with which it works (which on freebsd apparently includes sockets and nothing else). I also think one should rethink the internal design if every driver needs its own kqueue support, as that will always force kqueue into a second-class citizen not suitable as replacement for select, as it's unreasonable to expect kqueue to just work when its so little used and requires such a high maintainance (linux' epoll for example works fine with everything because it doesn't require drivers to support epoll specifically, so it is unlikely that epoll fails when select would work for example, which is the case on freebsd and darwin). The fact that it works fine on everything I threw at it on netbsd is probably not the result of better design, but more better maintainance, so I wouldn't be surprised if some future version of netbsd failed in similar ways (OTOH, in the past, netbsd consistently was the less buggy platform regardless of topic, wether it was threads, ptys or kqueue, so I might get quite disappointed if that happened :) Interesting, that has been completely counter to my experience. However, I rely on a completely different set of subsystems. Do you have a set of regression tests for libev? It sounds like they would worth having to regression test kqueue. Thanks for your feedback. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: version hwpmc kernel module pmc library not match
Check ports 'cpuid' - Vendor ID: GenuineIntel; CPUID level 10 Intel-specific functions: Version 06f6: Type 0 - Original OEM Family 6 - Pentium Pro Model 15 - Extended model 0 Stepping 6 Reserved 0 Odds are you have a post-P4 Intel processor. -Kip On Dec 17, 2007 7:47 PM, binto [EMAIL PROTECTED] wrote: Hi, i run command for kernel profiling purpose: pmcstat -S instructions -O /tmp/sample.out and i get error: pmcstat: ERROR: Initialization of the pmc(3) library failed: No such file or directory I've compile my FreeBSD 6.3-PRERELEASE kernel in i386 machine : device hwpmc options HWPMC_HOOKS myquestion: - any suggestion to fix that error? - how to find what version number of the hwpmc in my machine? - does pmc have version too? Thanks Binto ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: kqueue and libev
Actually, until recently it was broken on pipes. We've never received any PRs to that effect so there is no way of knowing. You'll have better luck asking the author himself. -Kip On 12/15/07, James Mansion [EMAIL PROTECTED] wrote: Any idea what the author of libev is on about here (from http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod): unsigned int ev_recommended_backends () Return the set of all backends compiled into this binary of libev and also recommended for this platform. This set is often smaller than the one returned by |ev_supported_backends|, as for example kqueue is broken on most BSDs and will not be autodetected unless you explicitly request it (assuming you know what you are doing). and |EVBACKEND_KQUEUE| (value 8, most BSD clones) Kqueue deserves special mention, as at the time of this writing, it was broken on all BSDs except NetBSD (usually it doesn't work with anything but sockets and pipes, except on Darwin, where of course its completely useless). For this reason its not being autodetected unless you explicitly specify it explicitly in the flags (i.e. using |EVBACKEND_KQUEUE|). It looks like a decent library, but these comments seem unfortunate. Does anyone know what the author is concerned about? James ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: kqueue and libev
It looks like a decent library, but these comments seem unfortunate. Does anyone know what the author is concerned about? he's just plain misinformed Until we know what he is referring to we can't actually say that. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Before After Under The Giant Lock
I just want to add my 2 cents, that my recent experience with FreeBSD MP has been extremely positive. I tend to use highly CPU bound MP programs, typically lots and lots of floating point operations. It used to be that Linux beat FreeBSD hands down - now FreeBSD seems to have a slight edge! Basically my program runs about twice as fast when I run two threads as opposed to one - I cannot see doing any better than that! pure computation does not need kernel operations most of the time.. ie. multi-threading kernel wont help much ;) Yes, I know. But something else was also done to FreeBSD, perhaps fine tuning with the scheduler, that did bring about massive improvements. I assume you're using ULE. Jeff has gone to great lengths to take cache affinity into account. This may be what you are benefiting from. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Would like some simple volunteer work
On Nov 16, 2007 1:11 AM, Karl Sjodahl - dunceor [EMAIL PROTECTED] wrote: On Nov 16, 2007 10:40 AM, Fred Bertram [EMAIL PROTECTED] wrote: Hi, I'm a cs student from Australia. Just want to enhance my skills and hopefully benefit this online software community in some way. I enjoy C programming in particular, havn't really mastered it or other languages. I'd like to practice by doing whatever though if anybody understands where i'm coming from. Is this a good place to do this? Cheers -- *** Frederick James Bertram (08)93371109 10 Snook Crescent Hilton 6163 Western Australia - * People to tend to mail this and ask what they can do to help. Easiest thing is just to check out the source, find what ever intrests you and start to hack. Check out the PR database and find and error and try and solve it. It's not gonna be fun if anybody tells you what to do, you need to find what you find fun to do and then just do it. br dunceor The PR database is really the best place to start if you're really interested in helping. There are lots of small tasks there. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any hope to have things requested by NVidia in FreeBSD-7?
On Nov 16, 2007 2:16 PM, Remko Lodder [EMAIL PROTECTED] wrote: Yuri wrote: I read long time ago that the reason that NVidia can't have their driver on 64-bit platform is that FreeBSD kernel lacks some functionality. Is this functionality present in 7.0? Or when to expect this to be done? I have NVidia card but still run 32-bit system because of lack of driver. Yuri Hello, This discussion gets over and over again actually, no the required support is not yet there. There is a wiki page which denotes what is required to get this going. http://wiki.freebsd.org/NvidiaFeatureRequests If you desperately need this, then consider funding someone (this has popped up before, it's interesting to arrange something like this because you need a trustable intermediating party that can arrange this, the FreeBSD Foundation is currently not able to do so as far as I can recall); who will do the work for you or do it yourself. There is currently no other way to get the support you want. Thanks, remko Remko - relax :) The wiki isn't really an obvious place for people to look. If we don't already we should have a page on popular hardware with support issues. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any progress on FreeBSD/xen port?
On 11/6/07, Scott Oertel [EMAIL PROTECTED] wrote: On Thu, 11 Oct 2007 15:07:21 +0200, Paul Schenkeveld [EMAIL PROTECTED] wrote: Hi, For a large project involving virtual servers under Xen I've been asked to advice on using BSD for some services instead of Linux. In the Q2/2007 FreeBSD Status Report work on the FreeBSD/xen port is mentioned but the last report which came in yesterday does not mention Xen at all. Is someone still working on FreeBSD/xen or has work on the project stalled? Is there anything usable, even beta, around which I can use to get a feeling of what's involved in running FreeBSD under Xen? Thanks. Paul Schenkeveld Did you ever get any info on this subject? I'm very interested in the status of this project as well. I've committed to importing i386/PAE (UP) domU support for Xen by the end of the year. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Critical Sections for userland.
On 10/2/07, Daniel Eischen [EMAIL PROTECTED] wrote: On Tue, 2 Oct 2007, Alfred Perlstein wrote: * Daniel Eischen [EMAIL PROTECTED] [071002 20:02] wrote: On Tue, 2 Oct 2007, Alfred Perlstein wrote: * Daniel Eischen [EMAIL PROTECTED] [071002 19:46] wrote: On Tue, 2 Oct 2007, Alfred Perlstein wrote: Hi guys, we need critical sections for userland here. This is basically to avoid a process being switched out while holding a user level spinlock. Setting the scheduling class to real-time and using SCHED_FIFO and adjusting the thread priority around the lock doesn't work? Too heavy weight, we want to basically have this sort of code in userland: Well, yeah, but are you _really_ sure that you aren't just running something that should be real-time and have priority over other applications? SCHED_FIFO means you will run until you relinquish the CPU (you can only do this as root). If all your threads are well behaved, would this work? Have you tried it? No, because it wouldn't work. How do we know when to let go of the cpu? In my system, the kernel tells you without polling. You don't have to know when to let go of the cpu if your threads are well behaved (meaning they block on some event, or have periods when they wait). They will let go of the CPU normally. When they're busy, they will not be switched out (unless perhaps there is an interrupt thread that needs to run -- I'm not sure how real-time threads get scheduled against ithreads). If your threads are not well behaved (CPU hogs), then that isn't going to work because they'll probably bog down the system. See /sys/priority.h realtime is right below ithreads in terms of priority. One of the big motivations for gang scheduling and part of the reason why SMP guests often perform poorly is that apps / VMs don't scale well if they're descheduled from the cpu while holding a lock. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Critical Sections for userland.
On 10/2/07, Alfred Perlstein [EMAIL PROTECTED] wrote: * Daniel Eischen [EMAIL PROTECTED] [071002 19:46] wrote: On Tue, 2 Oct 2007, Alfred Perlstein wrote: Hi guys, we need critical sections for userland here. This is basically to avoid a process being switched out while holding a user level spinlock. Setting the scheduling class to real-time and using SCHED_FIFO and adjusting the thread priority around the lock doesn't work? Too heavy weight, we want to basically have this sort of code in userland: /* assume single threaded process for now */ static int is_critical; atomic_mutex_lock(); /* implies ++is_critical */ ...do stuff... atomic_mutex_unlock(); /* implies --is_critical */ We don't want two or more syscalls per lock operation. :) I assume these processes are running as root? There is nothing to prevent the process from never dropping the lock. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Usage of kern_* functions in kernel
For core files and checkpoints that isn't possible. -Kip On 4/27/07, John Baldwin [EMAIL PROTECTED] wrote: On Friday 27 April 2007 02:43:16 am Marc Lörner wrote: On Thursday 26 April 2007 19:49, John Baldwin wrote: On Thursday 26 April 2007 08:08:19 am Marc Lörner wrote: Hello, I googled but found nothing about the usage of the kern_* functions (kern_open, kern_close, kern_pwritev, kern_preadv) that are located in vfs_syscalls.c When I use kern_open to open a file within the kernel, I get an error. When I use the normal vn_open function instead, all works well. So my question is which functions are recommended by you kernel-hackers for use within kernelspace? And here a second question: Is it possible to open/use the console driver in kernelspace within the functions mentioned above? If not, can you give me some pointers on where I can find this information! kern_XXX are generally used by system calls such as alternative ABIs, etc. so, you would recommend using the vn_* functions instead? In general userland should open files rather than the kernel. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: Any recent news on Xen support for FreeBSD?
Rink has made some progress. I'm cc'ing him. -Kip On 4/2/07, Jaye Mathisen [EMAIL PROTECTED] wrote: The fsmware page is significantly dated, and I just am not sure what's going on. I was just curious if there was a better or updated status available. Thanks for your time. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: iSCSI boot mussings
On 3/16/07, Achim Patzner [EMAIL PROTECTED] wrote: On 16.03.2007, at 16:59, John Nielsen wrote: A truly standalone iSCSI client will most likely want to use a TOE card, which to the OS looks like any other SCSI adapter. (I'm unsure which if any such cards are currently supported in FreeBSD, but that's a tangential question.) Maybe someone feels like playing with these: http://www.myri.com/ Myri-10G/10gbe_solutions.html There are at least a half dozen if not a dozen HBA iSCSI initiators. The only gating factor is price. A pxebooted ramdisk image with an iSCSI software initiator in it is probably the best way to go for most people. I don't think that there is a FreeBSD driver for any of the current hardware iSCSI HBAs. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Floating-point in kernel space
On 3/10/07, Maslan [EMAIL PROTECTED] wrote: It would be helpful to know why you need this support as well I just wanted to know the idea behind not having FP in kernel-space. Saving and restoring FPU registers adds overhead to thread context switching and there has never been a legitimate need for it. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: user-space locks
umtx On 3/9/07, Peter Holmes [EMAIL PROTECTED] wrote: Does FreeBSD have anything similar to Futexes for Linux. Thanks, Peter Looking for earth-friendly autos? Browse Top Cars by Green Rating at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: user-space locks
And? With futexes you limit yourself to whatever library provides pthread wrappers around them. He asked for the FreeBSD equivalent and the answer is umtx. Can you provide us with some concrete examples where libkse is preferable? -Kip On 3/9/07, Julian Elischer [EMAIL PROTECTED] wrote: Kip Macy wrote: umtx [EMAIL PROTECTED]:man -k umtx umtx: nothing appropriate [EMAIL PROTECTED]: also if you use umtx I think you limit yourself to libthr. On 3/9/07, Peter Holmes [EMAIL PROTECTED] wrote: Does FreeBSD have anything similar to Futexes for Linux. Thanks, Peter Looking for earth-friendly autos? Browse Top Cars by Green Rating at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Fwd: user-space locks
Do you think that the umtx KPI may have reached the appropriate level of maturity for writing up a man page? The KSE equivalent has had a substantive man page for quite some time. I would be more than happy to do any of the necessary technical copy-editing for the English. At this point I think you may be the only person well acquainted with the KPI. Thanks. -Kip Kip Macy wrote: umtx [EMAIL PROTECTED]:man -k umtx umtx: nothing appropriate [EMAIL PROTECTED]: also if you use umtx I think you limit yourself to libthr. On 3/9/07, Peter Holmes [EMAIL PROTECTED] wrote: Does FreeBSD have anything similar to Futexes for Linux. Thanks, Peter Looking for earth-friendly autos? Browse Top Cars by Green Rating at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic at boot on any 6.x OS
It looks like it may be loading an out of sync kernel module. Cleaning out /boot/modules might help. -Kip On 2/26/07, Joe Auty [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, My system does boot off of disc 1 of the FreeBSD 6.2 CD. However, even when copying the /boot directory from the CD to my machine, it still produces the same kernel panic, even when starting in safe mode. I've run a memtest, and it checked out fine. There must be something in my user space or world that it barfs on. I guess I will try a clean install and rebuild at some point... If you have any other ideas, I'm all ears! Here is my error message again (with verbose logging enabled, although that has no effect on this output): WARNING: Device driver Fatal trap 12: page fault while in kernel mode fault virtual address = 0x40 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06d4614 stack pointer = 0x28:0xf015491c frame pointer = 0x28:0xf015491c code segment = base 0x0, limit 0xff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interupt enabled, resume, IOPL = 0 current process = 898 (kldload) trap number = 12 panic: page fault uptime: 36s cannot dump. No dump device defined automatic reboot in 15 seconds Thanks again for your time! - --- Joe Auty NetMusician: web publishing software for musicians http://www.netmusician.org [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD4DBQFF42FSCgdfeCwsL5ERArNQAJ9pEyu3ZT3BXe4YhEsgRsid6fB+SwCXeGjO fO0GeeBUPKKYq4N5rRHDTw== =PgI8 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic at boot on any 6.x OS
It looks as if you've hit a device driver that is trying to print out a null string. The message you've given doesn't provide any more information than that. If you install a snapshot kernel it will probably have ddb compiled in which will allow you to at least get a backtrace. I'm sorry you're having trouble. -Kip On 2/24/07, Joe Auty [EMAIL PROTECTED] wrote: Hello, (sorry, don't know whether kernel problems should go to questions or hackers, or both).. This has been a long-standing problem of mine, but I always ignored it hoping it would go away on its own with a future 6.x release, but it remains... No matter whether I boot into safe mode or regular mode, with all kernel extensions disabled in /boot/loader.conf, I get the following panic late at boot of a fresh RELENG_6_2 kernel (with only a few services left to bring up). The 6.x kernels I've tried all build and installed cleanly without any errors... WARNING: Device driver Fatal trap 12: page fault while in kernel mode fault virtual address = 0x40 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06d4614 stack pointer = 0x28:0xf015491c frame pointer = 0x28:0xf015491c code segment = base 0x0, limit 0xff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interupt enabled, resume, IOPL = 0 current process = 898 (kldload) trap number = 12 panic: page fault uptime: 36s cannot dump. No dump device defined automatic reboot in 15 seconds This problem does not occur within any 5.x OS for me. I would certainly like to resolve this issue now, but this sort of debugging is over my head beyond running fsck (which I've tried). Any ideas here? Thanks in advance for your help! --- Joe Auty NetMusician: web publishing software for musicians http://www.netmusician.org [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: Xen Status?
The fix is trivial from just inspecting the loader change. Someone just has to have the wherewithal to make it and test it. -Kip On 2/23/07, KillFill [EMAIL PROTECTED] wrote: Maybe a port could be made from the NetBSD fixes :-) -- https://www.dineromail.com/cl/registracion/ri.asp?r=563042124848 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xen Status?
Well thats true and easy to find. My question on this FreeBSD list was related to FreeBSD thou. Can anyone on hackers shed some light on this? /Chris FreeBSD HEAD worked on Xen in the 3.0.2 time frame. If someone is able to be self-sufficient in maintaining Xen support in FreeBSD I'll review and put it into CVS. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ralink driver and FreeBSD 6.2?
A couple of things. - The newer rt2661.c driver has not been MFC'd to 6.2. That is most likely why your card is not working. - 'ifconfig' when run as root will load the module for a network driver provided it is a) in the path and b) name if_interface name.ko -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sin()/cos()/tan() for kernel code? '_ 'a
Trigonometry is seldom done with fixed point, which is the only way to do it in the kernel (using the FPU is a no-no). I would write a perl script to generate a lookup table for those functions - paste it into a header and use that. HTH. -Kip On 2/11/07, Eugene M. Kim [EMAIL PROTECTED] wrote: Hello all, I am writing a mouse device driver for my Wacom tablet (Intuos 2 9x12). The tablet comes with a mouse and I managed to get valid coordinate data from the device. However, unlike usual mice, the coordinate system is tied not to the orientation of the mouse itself, but to the tablet, which acts much like a mouse pad. So, for example, if I rotate the mouse 30 degrees to the left and move it left and right, the mouse cursor would move not horizontally, but to 2- or 8-o'clock. Fortunately the mouse also provides orientation data along with coordinate data, so the correct cursor movement could be calculated from it. The problem: The calculation needs trigonometry, but there seems to be no math library support in the kernel (I ran grep -w cos on the -CURRENT source tree, which turned nothing up). Does anyone have an idea on how to do this? Cheers, Eugene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: pkg_upgrade (was Re: pkg_add does not backtrack, does it?)
portupgrade -aPP On Wed, 7 Feb 2007, Joan Picanyol i Puig wrote: * Mike Meyer [EMAIL PROTECTED] [20070207 01:05]: If you let us know what your goals are, we might be able to help you get there. I know what I'd like: a utility in the base system for binary upgrading of packages. More flexible logic in how the '-r' option is handled would be nice (being able to fetch all packages from All/ even if you are on RELENG). Doesn't freebsd-update fetch install pkg_upgrade -a look nice for keeping up to date? The obvious hairy details must be harder than it seems, I'm sure others have considered it (and would have done it) before. qvb -- pica ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: semaphore.h does'nt include fcntl.h ?
Do you have SysV IPC support in your kernel? -Kip On Sun, 14 Jan 2007, girish r wrote: Hello folks, I am trying to use sem_open(3) but gcc complains that O_CREAT and O_EXCL is undeclared. According to the man page only semaphore.h needs to be included. But including fcntl.h solves the problem. sem_t *lock = sem_open(example_lock, O_CREAT | O_EXCL, 0600, 1); Another thing, a program with the above function call compiles but when I execute it, it spits out Bad system call (core dump). Specifically, I am trying to run this program given here: http://www.informit.com/articles/article.asp?p=679545seqNum=3rl=1;. Thanks for your time. --girish Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: WITNESS RELENG_6
The bug you're hitting there is a bad pointer reference in devfs_populate_loop - you shouldn't be taking a page fault there. I hope that someone who knows more about devfs will take a look. -Kip On 1/3/07, Eugene Grosbein [EMAIL PROTECTED] wrote: Hi! I try to find bugs in 6.2-PRERELEASE by using it (q) :-) The question is: are kernel options WITNESS/WITNESS_KDB expected to be in usable kernel? I don't worry about performance overhead here. The problem is, I've found this is nearly impossible to run my home system with RELENG_6 build from yesterday's sources, X.org 6.9.0, mplayer etc. without panicing and crashdump generation after an hour or so. Just switch from X to vty and logon gave me another LOR and crashdump. One of these you can see here: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107455 Perhaps, I should not use these options for everyday STABLE use? Eugene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: Tools for FreeBSD development
Qemu / vmware is probably the best way to go at the moment. On 12/2/06, Vishal Patil [EMAIL PROTECTED] wrote: I have recently moved over from Linux to FreeBSD and would like to if there is something similar to UML (User Mode Linux) for doing kernel development for FreeBSD. Reading different mailing lists, wikis etc it seems that qemu seems to be the best option. Is this tool used by most of the FreeBSD developers? Thanks. - Vishal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: i386 page fault clobbers error code in trap frame
si_addr doesn't contain the faulting pc, it contains the address that So either the comment is wrong, or that is a technically incorrect kludge. However, given that a number of the other fields are not filled out at all, the real objective should be to keep applications working. --- sys/i386/i386/trap.c.orig Sun Jul 30 18:27:21 2006 +++ sys/i386/i386/trap.cSun Jul 30 18:27:56 2006 @@ -777,9 +777,6 @@ return (-1); } - /* kludge to pass faulting virtual address to sendsig */ - frame-tf_err = eva; - return((rv == KERN_PROTECTION_FAILURE) ? SIGBUS : SIGSEGV); } ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VM question related to faults
From kern_umtx.c:
static int
_do_lock(struct thread *td, struct umtx *umtx, long id, int timo)
{
struct umtx_q *uq;
intptr_t owner;
intptr_t old;
int error = 0;
uq = td-td_umtxq;
/*
* Care must be exercised when dealing with umtx structure. It
* can fault on any access.
*/
for (;;) {
/*
* Try the uncontested case. This should be done in userland.
*/
owner = casuptr((intptr_t *)umtx-u_owner,
UMTX_UNOWNED, id);
/* The acquire succeeded. */
if (owner == UMTX_UNOWNED)
return (0);
/* The address was invalid. */
if (owner == -1)
return (EFAULT);
/* If no one owns it but it is contested try to acquire it. */
if (owner == UMTX_CONTESTED) {
owner = casuptr((intptr_t *)umtx-u_owner,
UMTX_CONTESTED, id | UMTX_CONTESTED);
if (owner == UMTX_CONTESTED)
return (0);
/* The address was invalid. */
if (owner == -1)
return (EFAULT);
On 7/30/06, Divacky Roman [EMAIL PROTECTED] wrote:
On Sun, Jul 30, 2006 at 12:57:32PM +0200, Divacky Roman wrote:
hi,
while working on SoC linuxolator project I am in a need of this:
I need to do some operation on memory like mem1 = mem1 + mem2 etc.
where the mem1/mem2 access can trigger fault. (memory not mapped or something)
to make it clear.. I am trying to access user-space memory from kernel.
This needs to be atomic (its an implementation of linux futexes)
I need to check from kernel if some memory is accessible and then perform an
operation on this memory. All atomically.
hence I need two things - function which checks wheter the memory is accessible
and something which makes it atomic (some mutex/something which prevents other
process to enter VM to unmap/etc. the memory in question)
hope its a bit more clear now
roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any 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: i386 page fault clobbers error code in trap frame
Looking at siginfo it isn't clear that there is a right way to
provide SIGSEGV, eva, and the error code.
_fault._trapno should contain the machine's error code and si_signo
should contain SIGSEGV, and si_addr contains the faulting pc. Maybe
one could abuse si_code to contain eva. Sorry for asking a question
that has already been answered but where is eva being put currently?
typedef struct __siginfo {
int si_signo; /* signal number */
int si_errno; /* errno association */
/*
* Cause of signal, one of the SI_ macros or signal-specific
* values, i.e. one of the FPE_... values for SIGFPE. This
* value is equivalent to the second argument to an old-style
* FreeBSD signal handler.
*/
int si_code;/* signal code */
__pid_t si_pid; /* sending process */
__uid_t si_uid; /* sender's ruid */
int si_status; /* exit value */
void*si_addr; /* faulting instruction */
union sigval si_value; /* signal value */
union {
struct {
int _trapno;/* machine specific trap code */
} _fault;
/* */
On 7/29/06, Tijl Coosemans [EMAIL PROTECTED] wrote:
I'm refering to the following two lines in sys/i386/i386/trap.c
/* kludge to pass faulting virtual address to sendsig */
frame-tf_err = eva;
Isn't there some other way to do this? Wouldn't the address still be
available in %cr2 inside sendsig? Or could there have been other page
faults by then?
The reason I'm asking this is that Wine wants to know the error code in
case of a page fault (the No eXec bit (AMD) and the read/write bit
specifically).
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: WINE vs. FreeBSD
Thanks for your input. The relative merits of the different threading libraries is currently under discussion. Could you also try it with libthr (it may not work at all), I'd like to hear what happens. Thanks. -Kip On 7/22/06, Michael Nottebrock [EMAIL PROTECTED] wrote: Dear -hackers and -emulation readers, I would like to call your attention to a few long-standing problems that have so far prevented WINE from living up to its capabilities on FreeBSD. I am afraid that I still don't fully grasp the scope of the problem, nor do I have a clear idea of what the solution might be, but what I've gathered so far is this: WINE does have certain requirements regarding memory allocation. In particular it (or Windows, rather) really wants a few memory ranges for itself: (from wine-0.9.17/loader/preloader.c): * 0x - 0x0011 the DOS area * 0x8000 - 0x8100 the shared heap * ???- ??? the PE binary load address (usually starting at 0x0040) The first two are particularly important for WINE running in win98 (or earlier) emulation mode, which is currently completely broken on FreeBSD, since those two memory ranges tend to be unavailable. The preloader bit from which this is quoted is WINE's own shared object loader that reserves memory that is important to Wine, and then loads the main binary and its ELF interpreter, and obviously does not work right on FreeBSD. I'm not sure whether it can be made to or not, perhaps somebody familiar with both our VM and runtime linker could take a look. Some more references: http://www.winehq.org/pipermail/wine-devel/2004-December/031750.html http://bugs.winehq.org/show_bug.cgi?id=5732 The other big issue with WINE on FreeBSD seems to be our threading support. WINE quite reliably manages to confuse libpthread, see http://www.freebsd.org/cgi/query-pr.cgi?pr=threads/100701. On SMP machines, I've even been able to trigger kernel panics with WINE (in win2k+ emulation mode) by merely hitting the close button on a windows application (and WINE subsequently shutting down): http://lists.freebsd.org/pipermail/freebsd-stable/2006-June/026219.html. WINE's threads interface can be found in loader/pthread.c and loader/kthread.c - again, it would be great, if someone to whom that sort of code means more than just random gibberish could take a look. Cheers, -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: WINE vs. FreeBSD
Thanks. That is a useful data point but David Xu has done a lot of work on libthr that has probably not been MFC'd back to 5.x. When I get the chance I'll try building KDE on my desktop which runs a derivative of -CURRENT. It may well be a general kernel bug, as I recall seeing the same error running FreeBSD on Xen with several threaded apps. -Kip On 7/22/06, Michael Nottebrock [EMAIL PROTECTED] wrote: On Saturday, 22. July 2006 21:20, Kip Macy wrote: Thanks for your input. The relative merits of the different threading libraries is currently under discussion. Could you also try it with libthr (it may not work at all), I'd like to hear what happens. Thanks. WINE crashes in roughly the same spot. This is however with a libthr on FreeBSD 5.5-RELEASE-p2, which is nothing short of disastrous (with a global lib mapping from libpthread to libthr, about 1/3 of all the programs in my default KDE session start at all - the rest hangs in state sbwait). Cheers, -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel Vanderpool (VT) on FreeBSD or FreeBSD Xen
I asked the person who wrote vtxassist (only SVM supports paged real mode) - he thinks that it broke when support for big real mode was added. He did not seem particularly inclined to fix it. It may be that Xen's VT-x support is considered less interesting to his organization now that VMware is free (as in beer). -Kip On 7/11/06, Mohacsi Janos [EMAIL PROTECTED] wrote: Dear All, Does anybody succeed to boot FreeBSD on an Intel Vanderpool capable machine? My colleague tried it and the result is a BTX halt as can be seen on the screenshots on page linked. He successfully run unmodified Linux, Windows 2003 under Xen virtual machines, but FreeBSD failed in the boot phase. http://skye.ki.iif.hu/~mohacsi/freebsd/xen-vt-freebsd.png http://skye.ki.iif.hu/~mohacsi/freebsd/xen-vt-freebsd2.png By the way what is the state of Xen port of FreeBSD? I already asked these questions on FreeBSD-stable but no answers... Thanks, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: gdb able to debug both fbsd and linux binaries
They have quite different ptrace interfaces, the binaries will have different elf brands, etc. Making a single GDB work on both would require a great deal of FreeBSD specific surgery on GDB. -Kip On 7/9/06, Divacky Roman [EMAIL PROTECTED] wrote: hi, is it able to somehow make gdb be able to debug fbsd and linux binaries at the same time? I mean.. alter somehow the way its built in buildworld or something thnx roman -- www.liberalnistrana.cz ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: NVIDIA FreeBSD kernel feature requests
Producing a driver for a GPU card, especially one that possibly converts from GL-foo to foo appropriate to program and feed an ASIC on a video card, is quite different matter entirely. I'm all for open source drivers, and would also encourage NVIDIA to continue to reconsider their closed source driver approach where it makes sense (especially for the network interfaces). However, I think that we shouldn't conflate these two cases rhetorically, as there are orders of magnitude complexity (and intellectual property) differences. Furthermore, requesting needed changes to the kernel interfaces is completely orthogonal to their documentation policies. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contiguous memory allocation problem
FreeBSD's strategy for doing page coloring makes contiguous memory allocation much past boot quite difficult. This will change when generalized superpage support is brought in (I hope in the near future). -Kip On 6/30/06, Hans Petter Selasky [EMAIL PROTECTED] wrote: Hi, I sometimes see that the USB driver is unable to allocate contiguous memory for itself. For example I noticed that FreeBSD was unable to allocate 350kbytes of contiguous memory after that I had run konqueror, the KDE web browser and various other memory consuming applications for a while. I am thinking about pre-allocating some memory for USB, but isn't that the job of bus-dma, which the USB system uses for memory allocation? The machine in question is running FreeBSD 7-current from April. Any comments? Thanks, --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: NVIDIA FreeBSD kernel feature requests
WOW THATS GREAT DOUG! \0/ - it didn't work for me. -Kip On 6/30/06, Doug Ambrisko [EMAIL PROTECTED] wrote: Kip Macy writes: | IIRC lack of per instance cdevs also limits Freebsd to one vmware instance. Really? Don't tell my vmware multiple instances! I used to run 10 on one FreeBSD host. Doug A. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA FreeBSD kernel feature requests
IIRC lack of per instance cdevs also limits Freebsd to one vmware instance. -Kip On 6/29/06, Oleksandr Tymoshenko [EMAIL PROTECTED] wrote: Christian Zander wrote: Hi all, # Task:implement mechanism to allow character drivers to maintain per-open instance data (e.g. like the Linux kernel's 'struct file *'). Motivation: allows per thread NVIDIA notification delivery; also reduces CPU overhead for notification delivery from the NVIDIA kernel module to the X driver and to OpenGL. Priority:should translate to improved X/OpenGL performance. Status: has not been started. I've stumbled across this issue a while ago. Actually it can be partially solved using EVENTHANDLER_REGISTER of dev_clone event with keeping state structure in si_drv1 or si_drv2 fields. I'm not sure it's the best solution but it works for me though it smells like hack, and looks like hack :) Anyway, having legitimate per-open instance data structures of cdevs is a great assistance in porting linux drivers to FreeBSD. Just my $0.02. -- Sincerely, Oleksandr Tymoshenko PBXpress Communications, Inc. http://www.pbxpress.com Tel./Fax.: +1 866 SIP PBX1 Ext. 656 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: Jail-Aware Scheduling
I personally prefer the notion of layering the normal scheduler on top of a simple fair-share scheduler. This would not add any overhead for the non-jailed case. Complicating the process scheduler poses maintenance, scalability, and general performance problems. -Kip On 6/11/06, Peter Jeremy [EMAIL PROTECTED] wrote: On Sun, 2006-Jun-11 14:50:30 +0200, Pieter de Goeje wrote: I suppose by limiting the jail CPU usage you mean that jails contending over CPU each get their assigned share. But when the system is idle one jail can get all the CPU it wants. IBM MVS had an interesting alternative approach, which I believe was part of the scheduler: You could place an upper limit on the CPU allocated to a process. From a user perspective, an application would respond in (say) 2 seconds whether the system was completely idle or at normal load. This stopped users complaining that the system was slow as the system got loaded. In the case of jailed systems, it could also prevent (or minimize) traffic analysis of the system by a jailed process. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: Someone with knowledge in VM/fork (and Copy on Write) needed
Take a look at vm_forkproc in vm_glue.c -Kip On 6/8/06, Alexander Leidinger [EMAIL PROTECTED] wrote: Hi, Roman (and I) need someone who is able to explain fork() and VM stuff. The problem is that the linux clone() syscall is supposed to do COW of the stack in some cases (if the child_stack argument is NULL it has to COW the thread stack, making a copy immediately is maybe ok too as a workaround). I don't know enough about the VM, so I ask here. We looked at the code of fork1(), but I can't find a description of what it is supposed to do and how flags are interpreted. Based upon the first comment in fork1() it may be able to do it itself. But this comment may also be completely unrelated to the solution we search. bikeshed color=doxygenIt would make sense to have a little bit of documentation in the vicinity of this function./bikeshed So can someone explain how the stack is copied when calling fork()/fork1() or whatever_function_foo()? Bye, Alexander. -- Selling GoodYear Eagle F1 235/40ZR18, 2x 4mm + 2x 5mm, ~150 EUR you have to pick it up between Germany/Saarland and Luxembourg/Capellen http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: Re: NFS server not responding prevents boot
Um that is what intr is for - and it won't cause silent data loss. -Kip On 5/19/06, Sergey Babkin [EMAIL PROTECTED] wrote: From: Steven Hartland [EMAIL PROTECTED] Anyway the big question is how can I change all our NFS mounts so that failed mounts dont prevent the machines booting to the point where they can be fixed remotely i.e. have started sshd. Doh!! spent ages googling for the answer then found it in 2mins of looking through the man pages. The option for anyone interested is bg for -b from the command line to mount: [quote=man mount_nfs] -b If an initial attempt to contact the server fails, fork off a I usually use soft,bg. The soft option makes the operations on this filesystem fail if the server is not available instead of hanging (unkillable!) forever and waiting for the server to come up. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: Zero Copy, FreeBSD and Linus Torvalds opinion
The implementation is 7 years old, not used by default, and was intended for a specific application. There really isn't much to say. -Kip On 4/30/06, Iantcho Vassilev [EMAIL PROTECTED] wrote: Hello guys, in bsdnews.com i found this link http://kerneltrap.org/node/6506 and particulary this: I claim that Mach people (and apparently FreeBSD) are incompetent idiots. Playing games with VM is bad. memory copies are _also_ bad, but quite frankly, memory copies often have _less_ downside than VM games, and bigger caches will only continue to drive that point home. What do you think about it? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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: VMWARE GSX Port?
-CURRENT runs on 3.0 as a domU. There is partial dom0 support. The changes have not gone back into the mainline because xenbus is extremely difficult to integrate cleanly. You can check on the state of the xen3 branch in perforce. -Kip On 3/2/06, Ashok Shrestha [EMAIL PROTECTED] wrote: According to the Xen website, it's been ported to FreeBSD [http://wiki.xensource.com/xenwiki/OSCompatibility]. Anybody know where port is? -Ashok Shrestha On 2/28/06, Seán C. Farley [EMAIL PROTECTED] wrote: On Tue, 28 Feb 2006, Mike Silbersack wrote: On Sat, 25 Feb 2006, Scott Long wrote: Ashok Shrestha wrote: VMWARE GSX was released recently for free. [http://www.vmware.com/news/releases/server_beta.html] Is anyone working on a port for this? I've started on it, but I haven't made much progress yet. Anyone who's interested in working on it should make sure to start with the VMWare 3 port (which works at present), and Orlando's beta 4.5 port: http://www.break.net/orlando/freebsd.html Also, check out Wietse Venema's changes[1] done on top of Orlando's work. Seán 1. http://lists.freebsd.org/pipermail/freebsd-emulation/2006-February/001843.html -- [EMAIL PROTECTED] -- Ashok Shrestha ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any 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]
update on running FreeBSD on xen
The curious can track its status (known bugs, feature plans, release plans, etc.) at: http://www.fsmware.com/xenofreebsd/7.0/STATUS It is in perforce under //depot/projects/xen3 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FS impl.
On Fri, 6 May 2005, David Parfitt wrote: Hi - I have been trying to write my own UFS-like filesystem implementation for fun. I had read somewhere that UFS was developed in user space (correct me if I'm wrong on that one) and then moved over to kernel-space. I was wondering if there are any existing facilities in the kernel source tree that would allow me to develop an fs in user space easily or with a little tweaking? As of right now, I have to develop, compile, panic, reboot, debug etc. which is frustrating and time consuming. I can't speak for user-space utilities, but using xen as a development environment would dramatically shorten the panic and reboot cycle. In addition, you don't require a 2nd machine to debug with GDB. Just a thought. If booting Linux makes you itch, NetBSD support for acting as the control plane is supposed to be stable. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: running freebsd in qemu using the -nographic option ?
So basically what I want to do now is mount the freeBSD image in a loopback and modify the boot.conf file directly. Anyone knows how to do this under linux (2.6 if relevant) ? BSD seems to have a weird way of organizing the disk. Which file system shoud I support ? I would just do it on FreeBSD - man mdconfig. Last I looked (years ago) the UFS support on linux was not actively maintained and I would be very surprised if they have UFS2 support. I've had to create my own root images for doing work on xen so I know it works just fine. If you insist on doing it on Linux, the command is losetup. to bind: losetup /dev/loop0 root image to unbind: losetup -d /dev/loop0 -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Xen support
Repost. Outlook posts a different e-mail address from the one I subscribed with. In all fairness I'd like to say that Nate put me in touch with someone to commit the work. At about the same time I discovered a rather annoying bug (since fixed), and I haven't followed back up. For those who would like to try it out I just submitted a sparse tree patch against the development branch (xeno-unstable.bk), that I believe will be committed shortly. It and a kernel can be found at: http://www.fsmware.com/xenofreebsd/5.3/050317/ You'll find some very basic instructions for booting a FreeBSD guest on xen one level up. To avoid premature enthusiasm I'd like to point out that FreeBSD is currently only supported as an unprivileged guest. DOM0 support is not that much work, it simply isn't a priority at the moment. -Kip -Original Message- From: Eric Masson [mailto:[EMAIL PROTECTED] Sent: Saturday, March 19, 2005 6:53 AM To: Mailing List FreeBSD Hackers Subject: Xen support Hello, Everybody here probably knows about Xen, the virtualization layer from Cambridge University (Uk) : http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ Is there any hope to see Kip Macy's work on Xen Support merged in the main tree anytime soon ? http://sourceforge.net/mailarchive/forum.php?thread_id=6793311forum_id=35600 Regards Éric Masson -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xen support
Ok, not really annoying, Manuel Bouyer is working on domain0 support for NetBSD, so I won't have to install some linux on the box ;) So I've heard. I haven't tried it out yet. As my girlfriend would like me to keep the bare minimum number of machines here, Xen is the way to run Net/Free/DFly and maybe some dreadful Debian on a single amd64 machine. LOL. There isn't any DFly support currently. Starting from the FreeBSD port, it wouldn't be hard to add. Regarding this kind of setup, do you know if Xen could support amd64 in domain0 and mix amd64/ia32 kernels/userlands in other domains ? There currently is only compatibility-mode support for applications not guests. I'm not under the impression that x86_64 support is that stable yet. Otherwise I would've started on x86_64 FreeBSD support. Please try it out and let me know off-list how well it works. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: process checkpoint restore facility now in DragonFly BSD
I've promised Nate to port the functionality to FreeBSD. I'm busy doing some things with the FreeBSD port to Xen at the moment. Checkpointing a process is intrinsically messy for reasons beyond the obvious statefulness of TCP connections. Process state, particularly with regard to devices, is often not cleanly associated with the process in the kernel. What happens if a file that the process had open has gone away? Other issues abound - checkpointing a process pipeline can be made to work, but some work would need to be done on pipes. The list goes on. -Kip On Wed, 12 Jan 2005, Siddharth Aggarwal wrote: Hi all, I am responding to a post back in Oct 2003 when the checkpointing feature was announced for DragonFly. I have been doing some research on this, and have seen some projects that use Xen VMM to achieve checkpoints of guest OSes. So I was looking for inputs from people as to what everyone feels about checkpointing, whether it should be done at the physical machine level or VM level. Pros and Cons of each approach, if any further development was done on DragonFly for checkpoint since then and if it was stopped, why? Are there serious limitations to checkpointing a physical machine? Sorry for such a vague posting, but I thought this would be a good platform to get some feedback. Thanks, Sid. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: process checkpoint restore facility now in DragonFly BSD
Taking this off list. -Kip On Wed, 12 Jan 2005, Siddharth Aggarwal wrote: Thanks for your reply. I understand the complexity of checkpointing a process and I do agree that capturing the complete state of a system is really difficult. So my question is that if a subset of that functinality was to be implemented (e.g. not guaranteeing certain things to processes when they restart, and I believe that you have already implemented this for DragonFly), why is it more difficult to do it for a physical machine versus in a VMM like Xen? Or do you have any arguments in the reverse direction i.e. better/easier/efficient/reliable in a physical machine than a VMM? Or do you now believe since this feature was implemented over a year ago, that a VMM is the way to go? On Wed, 12 Jan 2005, Kip Macy wrote: I've promised Nate to port the functionality to FreeBSD. I'm busy doing some things with the FreeBSD port to Xen at the moment. Checkpointing a process is intrinsically messy for reasons beyond the obvious statefulness of TCP connections. Process state, particularly with regard to devices, is often not cleanly associated with the process in the kernel. What happens if a file that the process had open has gone away? Other issues abound - checkpointing a process pipeline can be made to work, but some work would need to be done on pipes. The list goes on. -Kip On Wed, 12 Jan 2005, Siddharth Aggarwal wrote: Hi all, I am responding to a post back in Oct 2003 when the checkpointing feature was announced for DragonFly. I have been doing some research on this, and have seen some projects that use Xen VMM to achieve checkpoints of guest OSes. So I was looking for inputs from people as to what everyone feels about checkpointing, whether it should be done at the physical machine level or VM level. Pros and Cons of each approach, if any further development was done on DragonFly for checkpoint since then and if it was stopped, why? Are there serious limitations to checkpointing a physical machine? Sorry for such a vague posting, but I thought this would be a good platform to get some feedback. Thanks, Sid. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My project wish-list for the next 12 months
Hardware-based iSCSI HBAs solve this by having their own memory and TCP stack separate from the OS. Software-only iSCSI initiators such as linux-iscsi usually just hope it doesn't happen, and that's why I don't usually recommend software-only iSCSI initiators to anyone. How is that any better than having the SW iscsi initiator pre-allocate a pool of memory for its use at startup? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
The heuristics vary from platform to platform - what does objdump -d show? -Kip Well, I was hoping someone would have already seen this before, but I guess I will need to do some more checking if I'm going to get a better idea of what is going on. I'll put it on my list of things to look at when I have some spare time... -- If I have not seen as far as others, it is because I have been standing in the footprints of giants. -- from Usenet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: noread(), nopoll().... functions
0 -Kip On Mon, 15 Mar 2004, Claudio Martella wrote: Hi, i'm writing a driver, and noticed the noread() nopoll() etc general-use functions for struct cdevsw are no longer present in 5.x. What can i use in 5.x? TIA -- If I have not seen as far as others, it is because I have been standing in the footprints of giants. -- from Usenet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPU update
Barring any BIOS issues a standard ia32 kernel will boot and run happily on an AMD64 processor. -Kip On Wed, 3 Mar 2004, Mark wrote: - Original Message - From: John Baldwin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Mark [EMAIL PROTECTED] Sent: Thursday, March 04, 2004 12:14 AM Subject: Re: CPU update On Wednesday 03 March 2004 06:02 pm, Mark wrote: Dear Sirs: I compiled my FreeBSD 4.7R for an AMD XP-2000. If I upgrade to an AMD 64 3200, will my OS still run? The AMD 64 is 32-bit downwards compatible. Yes. FreeBSD 5.x also supports amd64 natively. Thank you for your answer. Am I reading your also right, that you say, Yes, 4.7R will run on the AMD 64 too; but only 5.x will support its native 64 bit mode support? Thanks, - Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- If I have not seen as far as others, it is because I have been standing in the footprints of giants. -- from Usenet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: use after free bugs
I wonder if the same approach relating to memory allocation and free checking via static analysis could be applied to locking and unlocking of locks? I.e.: Yes. See Dawson's papers. That is one of the examples given. Use after free is one of the stock checkers. I don't think that there is a stock checker for locks, it might be harder to infer lock/unlock then malloc/free. In which case one would have to write an application specific lock check. In addition, in the case of nested locks, the FSA used wouldn't suffice and one would have to call out to C code. The first two are easy - I'd have to look at the MetaL manual to figure out how difficult the third one is. - We don't release locks more than once. - We don't forget to unlock. - We hold a lock before accessing certain fields (defined by annotation) of a structure. -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [CHECKER] bugs in FreeBSD
Dawson is the man. http://www.stanford.edu/~engler/ If I have not seen as far as others, it is because I have been standing in the footprints of giants. -- from Usenet On Fri, 16 Jan 2004, Xin LI wrote: Hello, The tool is amazing :) I am very interested in how does it work, is there any paper published on this topic? Thanks in advance! Xin LI, Beijing University of Technology - Original Message - From: Paul Twohey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 17, 2004 8:01 AM Subject: [CHECKER] bugs in FreeBSD Hi, I'm with the Stanford Metacompilation research group. We have a suite of checkers that find bugs at compile time and we've had quite a bit of success checking the Linux kernel code for errors. Since our checkers can emit false alarms we filter the reports before we give them to the kernel developers. While some false alarms slip past us to the developers, our limited knowledge of the kernel allows us to recognize most of them. We are currently trying to extend our checker to automatically find functions which allocate resources and to make sure those resources are properly disposed of. Enclosed is a list of potential bugs in FreeBSD where a value is returned from a function (like malloc) that should be owned by the caller and the caller does not properly dispose of the value with the appropriate disposal routine (like free). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
There is also a problem in that the dirty work, even if done in a way that demonstrates that the person has skills, is not always recognised as important. The recognition has to come from within that part of the developer community that has commit bits, because you need someone with a commit bit to actually commit the stuff. If noone with a commit bit recorgnises the dirty work as important, it's not going to be committed and the person who has done the dirty work is not recognised as someone who is worthy of a commit bit because none of his work has been committed. I think this perfectly underscores, if not restates, Terry's point. He doesn't believe sufficient value is placed on the dirty work. The following will sound as if it were intended to be ironic, but it isn't. Those working in the DragonFly tree, all appreciate Hiten's hard work as a bottle-washer. We've benefited from the fact that members of the FreeBSD community, through racist remarks and endless flames, and a key member of core, through the indefinite postponement of a commit-bit, have alienated him. Thus providing us with a, perhaps small, but nonetheless, valuable resource. -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
This isn't a game Kris. I'm sorry if it hurts your feelings. Core always supports its own. Take a look at the history of SMP locking, the sudden change of ownership when the foundation came into money, the ensuing letter to core, and then the complete inaction. Those allegations against the core member were withdrawn, and I think it is despicable of you to use slurs of racism to attempt to promote your project. Hiten shouldn't be used as a pawn. Hiten is not a pawn. He is my friend. He has been endlessly hurt by numerous *private* e-mails to him from people on the FreeBSD lists. Please re-read my original e-mail I did not claim anything on the part of core. I'm not slurring the community as a whole. Please note that DragonFly is not my project any more than FreeBSD is, I happened to do some work in it. No-one has a problem with DragonFly having forked over technical differences. Don't polarise it into active hate between the two projects, you'll only end up damaging both. Thank you for the advice. If you'll notice I'm not on any of the lists any more. As soon is thread is permitted to die you will likely never hear from me again. Please don't expect me to be silent on the e-mails that I do receive, taking some sort of moral high-ground. -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
I, and I think other members of FreeBSD, would appreciate it if the members of DragonflyBSD would adhere to this peace-keeping rule as well. Thank you for providing sound advice Poul in a public forum. -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
Puzzling.. to say the least.. I'm sorry if I hurt your feelings. Please allow this thread to die, and me to move on to other things. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
I for one am very glad you're not a member of the FreeBSD community. And given that you've found a place with DragonFly, there's little chance that you become part of FreeBSD community in the future. For As stated previously, I'm not, nor have I ever been, a member of DragonFly BSD, FreeBSD, NetBSD, OpenBSD, or Linux. I've just done work in the first two and the last. So don't slur those who choose to define themselves as members with all the various evils that you appear to want to attribute to me. that I'm also very glad. So, all in all, I'm very glad DragonFly exists. Now even more than before. Because besides the technical divergence it also seems to have the effect of purifying the FreeBSD community from those who are dumb enough to make a fool of themselves, FreeBSD is not yet pure, but people like you and phk are helping to ensure that every day it becomes more pure. And once again, I thank you both for your efforts. and indirectly the project, race and species they're associated with or otherwise belong to. Unfortunately, that's still 2 out of 3 for me, but then again life wouldn't be so much fun for me if it wasn't for guys like you Kip. I can handle the embarrassment, so do stick around... Ouch. That truly is all encompassing. It is unfortunate that there isn't a competitive demand for people who are talented at making snide remarks. You and a couple of other notables would be very well off. It is also unfortunate that people like you and phk are the most vocal members of the FreeBSD community. There are so many good, kind, and talented people out there. -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: modified files for: process checkpoint restore facility now in DragonFly BSD
You seem to have mistaken [EMAIL PROTECTED] for [EMAIL PROTECTED] Thank you Poul for taking the time to correct me. Although checkpointing was a specifically requested feature for FreeBSD, it was, given the circumstances, an unforgivable error for me to announce it on a FreeBSD list. The module was implemented in a fork of the code base and hence is clearly irrelevant. Particularly when contrasted with fascinating discussions about bikesheds, bringing up a mundane facility for serializing and deserializing process state truly only adds to the noise on the list. Please don't make this mistake again. Once again my sincerest apologies. I'm flattered that someone who has made such fundamental contributions to the state of the art in FreeBSD as phkmalloc and the beerware license would condescend to correct me. I was so ashamed of myself for being so oblivious as to think that FreeBSD might still bear some relevance to DragonFly that I unsubscribed from all of the FreeBSD mailing lists, thus ensuring that I never make the same mistake again. I've CC'ed the list so that all might read my apology and know of your kindness in gently informing me off-list. I'm certain that your keen insights and low-key charisma, as demonstrated by this thoughtful e-mail, will help to ensure the continued growth of FreeBSD as a dynamic thriving community. Thanks. -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
process checkpoint restore facility now in DragonFly BSD
At BSDCon '03 it was mentioned that a process checkpoint / restore facility would be a useful addition to FreeBSD. This post is to announce that Matt and I have added such a facility to DragonFly BSD. It is noteworthy for -hackers as anyone who is interested could still port it with relative ease. Basically you use it by kldload'ing the checkpt.ko module, which should now be built automatically. You then ^E the program you want to checkpoint, and use the 'checkpt' utility in /usr/bin to resume it from the checkpoint file. The program is *NOT* killed by this signal, it continues to run after the checkpoint file(s) have been generated. Alternatively, you can send the program any signal that will cause it to coredump and exit. You will then be able to restore from the core dump! In conjunction with a shared file system this can be used for process migration. The checkpoint program is currently designed to work only with simple programs... it will restore the signal, descriptors references to regular files, the VM state (anonymous memory), as well as any nominal file mappings, but it cannot restore sockets, pipes, or device descriptors. So, while you can checkpoint a pipe sequence, you can't really restore it. Pipes, ttys, and common devices (zero, null, bpf) will not be that hard to add. Stream sockets are an open question. Please note that there are *SEVERE* security issues with this module. The module is not loaded into the kernel by default and, when loaded, can only be used by users in the wheel group. You can change the group requirements with a sysctl (see the manual page for checkpt). The security issues relate to the restoration of signals and file descriptors (in particular, the restoration system call will convert file handles into file descriptors which could potentially allow any file in the system to be accessed). Matt has put in some basic security checks but they are not meant to be all encompassing! It is going into the tree now because Matt and I have done enough work on it that anyone else interested in working on it can theoretically dig in. Significant debugging is still in place. We've left it as a module to facilitate debugging. It should be useable for scientific applications now. It should already work considerably better then the linux equivalent what with the regular file descriptor save/restore capability. Any developer who wishes to work on the checkpointing module and related code is welcome to! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
modified files for: process checkpoint restore facility now in DragonFly BSD
The impacted files are in the directories sys/checkpt and usr.bin/checkpt as well as sys/kern/imgact_elf.c and sys/kern/kern_fp.c. -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic during nfs operations in 4.8S on Dell 2650
Can you get a backtrace? Not knowing anything at this point, bumping up the number of mbuf clusters *might* help. -Kip FYI: I'm not representing NetApp in any official capacity on this, I just happen to have a vested interest in both OnTap and FreeBSD. On Thu, 7 Aug 2003, Mark Powell wrote: On Thu, 7 Aug 2003, Mark Powell wrote: We've recently got a couple of Dell Poweredge 2650's with 2x2.8GHz Xeons, 4GB RAM, PERC 3/Di (aac) RAID controller. They are mounting a 700GB fs over NFS from a NetAPP. They are connected to a Cisco 3550-12T gigabit over copper switch. I tried them first on the intel em cards and they panicked and also the internal bge adapters with the same result. Thought everything was fine until I was rsyncing the POP3 mail stores from the old machines onto these. Rsync runs for about an hour or so and get's large. In the 300M-600M region the system will always panic. This happens on both systems, so doesn't seem a hardware fault. This is a 4.8S kernel and world rebuilt as of today. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 5936 Fax: +44 161 295 5888 www.pgp.com for PGP key ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Assembly Syscall Question
Maybe, but they also support a lot of MMU-less architectures, so it may have made things simpler for them to not depend on MMU. I wonder if NUMA had any bearing on that as well... No. The initial design of their VM greatly preceded NUMA and uCLinux. It actually makes the system less portable in that it can require interspersing of machine dependent code in the machine independent parts when the machines page table layout differs from the default. The introduction to the UVM thesis has some good points in this regard. -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Assembly Syscall Question
UVM was the VM system that replaced the old Mach style VM in NetBSD and (I believe) OpenBSD. FreeBSD has already cleaned up a lot of the problems that UVM addresses. However, there are still some things that could be done to make map passing easier, which I believe would make zero-copy support cleaner if not faster. This is the UVM home page: http://ccrc.wustl.edu/pub/chuck/tech/uvm/ -Kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
How do I get profiling to work?
When I do a config -p configuration file then a make depend; make kernel - I get linking kernel mcount.o: In function `mcount': mcount.o(.text+0xa): undefined reference to `_gmonparam' mcount.o(.text+0x10): undefined reference to `_gmonparam' mcount.o(.text+0x40): undefined reference to `user' mcount.o(.text+0x52): undefined reference to `btrap' mcount.o(.text+0x5b): undefined reference to `eintr' mcount.o(.text+0x64): undefined reference to `bintr' mcount.o(.text+0x6b): undefined reference to `bintr' mcount.o(.text+0x75): undefined reference to `btrap' prof_machdep.o: In function `__mcount': prof_machdep.o(.text+0x2): undefined reference to `_gmonparam' prof_machdep.o: In function `.mcount': prof_machdep.o(.text+0x12): undefined reference to `_gmonparam' *** Error code 1 What extra voodoo is neccessary to ensure that these symbols are defined? Thanks. -kip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcp raw socket programming recvfrom()
Usually if your looking at raw packets you want to use BPF. -Kip On Wed, 9 Jul 2003, Alin-Adrian Anton wrote: Hey folks, I wrote my piece of code to play with, and it uses raw sockets to send TCP packets. It sends packets okay, everything tested with a sniffer, everything is really really fine, but it seems I cannot recvfrom anything. I mean, it just keeps waiting and doesn't see the reply the server is actually sending (can be seen with a sniffer). I read that the freebsd kernel does not duplicate any incoming TCP/UDP packets to any of the opened raw sockets. Is that true? So the only solution is to use the interface in promiscuous mode and sniff like a sniffer for the expected packet? Is there any other way? PS: ICMP gets received well with recvfrom (tested). On Linux, it does work for tcp/udp too with recvfrom. I was also wondering if anyone could help me understand why this behaviour in freebsd? (or *BSD) Thanks! Best Regards, Alin. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: remote gdb through terminal server?
The filers here are all debugged through terminal servers using gdb on the client and a gdb stub on the server. So if it doesn't work it is likely due to your setup or a bug in FreeBSD's gdb stub. -Kip On Wed, 11 Jun 2003, Brooks Davis wrote: Does anyone know if it's possiable to run remote GDB through a terminal server? Connections to the terminal server are via SSH to portslave. I've got some boxes I upgraded fom 4.6-STABLE to 4.8-STABLE which now reliably crash under heavy FS load that I'm trying to debug and my easiest acess is via the terminal server. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS ACLS's ?
Citi has an OpenBSD NFSv4 client implementation. Is anyone working on porting that to FreeBSD? From a cursory glance it appears to rely heavily on the existing NFS infrastructure, how far have FreeBSD and OpenBSD developed away from the 4.4 implementation? http://www.citi.umich.edu/projects/nfsv4/openbsd/ -Kip On Mon, 30 Dec 2002, Robert Watson wrote: On Fri, 27 Dec 2002, joe mcguckin wrote: Are there any strange interactions between NFS and filesystems that are not UFS? E.g. UFS2? Does NFS support new features that these fs's may implement? NFS can represent many but not all of the services found in UFS1 and UFS2. Among things it doesn't support are the retrieval and manipulation of BSD file user flags, system flags, extended attributes, and access control lists (ACLs). However, NFSv3 does correctly handle enforcement with these features because clients rely on the server to evaluate protections on file system objects using an ACCESS RPC. NFS2 evaluates protections on the client (if I recall correctly) so may not behave properly. There are RPC extensions to NFSv3 to retrieve and manipulate ACLs on Solaris, IRIX, et al, but we don't currently implement those extensions. Likewise, NFSv4 supports ACL management, but we don't yet implement NFSv4. It shouldn't be too hard to dig up information on the NFSv3 ACL RPC extensions and implement them on FreeBSD 5, since the semantics of our ACLs are highly compatible with Solaris and IRIX. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
breakage on zero copy send
__ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: what does this mean?
ANother case of the obscure beyond belief message: sio1: configured irq 3 not in bitmap of probed irqs 0 I would assume it means that 0x is the bitmap of probed irqs and that irq3 0x10 configured for sio1 is not in that bitmap. isa/sio.c: /* * Turn off all device interrupts and check that they go off properly. * Leave MCR_IENABLE alone. For ports without a master port, it gates * the OUT2 output of the UART to * the ICU input. Closing the gate would give a floating ICU input * (unless there is another device driving it) and spurious interrupts. * (On the system that this was first tested on, the input floats high * and gives a (masked) interrupt as soon as the gate is closed.) */ sio_setreg(com, com_ier, 0); sio_setreg(com, com_cfcr, CFCR_8BITS); /* dummy to avoid bus echo */ failures[7] = sio_getreg(com, com_ier); DELAY(1000);/* XXX */ irqmap[3] = isa_irq_pending(); failures[9] = (sio_getreg(com, com_iir) IIR_IMASK) - IIR_NOPEND; enable_intr(); irqs = irqmap[1] ~irqmap[0]; if (bus_get_resource(idev, SYS_RES_IRQ, 0, xirq, NULL) == 0 ((1 xirq) irqs) == 0) printf( sio%d: configured irq %ld not in bitmap of probed irqs %#x\n, device_get_unit(dev), xirq, irqs); what on earth is this trying to tell me? WHAT bitmap? julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Copying from Virtual Address Space to Physical Address
While we're on the topic of vmapbuf: I have a kernel module that maps two 64k chunks of user memory into the kernel using the same set of steps that cam_periph_mapmem uses. However, I inevitably get the following panic after running the code for a bit: Aug 30 14:55:26 testhost /kernel: panic: worklist_remove: not on list Aug 30 14:55:26 testhost /kernel: Aug 30 14:55:26 testhost /kernel: syncing disks... 8 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Aug 30 14:55:26 testhost /kernel: giving up on 1 buffers This is a panic in ffs_softdep.c, it implies to me that either the FFS code isn't recognizing that not all buffers belong to it or getpbuf isn't doing all the needed accounting. I notice that I am calling getpbuf(NULL), just as cam_periph_mapmem does. But above its definition in the comment is: * NOTE: pfreecnt can be NULL, but this 'feature' will be removed * relatively soon when the rest of the subsystems get smart about it. XXX Also worthy of note is that my kernel module has a lot of printfs which obviously translate to a lot of synchronous writes by syslog, presumably putting memory pressure on the file system. When guessing whether Kirk is at fault or I am fault, it is usually a safe bet that I am at fault ;-). Any insights? -Kip On Fri, 30 Aug 2002, Julian Elischer wrote: On Fri, 30 Aug 2002, Balaji, Pavan wrote: Thanx. It's nearly done. I just need to know two more small things. physio() requires a dev_t as a parameter. What do I give in over here? I can't give NULL, cause it does use it for some stuff in the function definition. I wasn't suggesting that you use physio() but that you use it and it's friend as a prototype for yourself when you write a function to do what you want. The dev_t is associated with the device this is doing IO from so it's not necessarily relelvant to you. you haven't told us enough about what you want to do to allow us to really understand your problem. Also, the only other parameters to physio() are the uio and the ioflag (which is not used at all). So, where is the kernel virtual address mapping? Do I have to do something this this dev_t thing to open a virtual device which maps to the kernel virtual address. If yes, how do I do this? Thanx. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: problems with pthreads
You need to remove the -ansi flag to the compilation to remove the warnings, and add a -pthread to the link stage so that libc_r will be used instead of libc. As an aside: this only belongs on -questions. However, considering I got _zero_ response after posting to one then the other when one of my boxes failed to boot after cvsupping -STABLE and doing a make world I can understand the crossposting. I think responding to trolls is more fun for many people. -Kip On Sun, 25 Aug 2002, GERARDO ENRIQUE PAREDES MANCIA wrote: when trying to portupgrade XFree86-clients from 4.2.??? to the newest version i get this: snip LD_LIBRARY_PATH=../../exports/lib cc -O -pipe -march=pentiumpro -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -I../.. -I../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -c appres.c In file included from appres.c:34: /usr/include/stdlib.h:110: warning: ANSI C does not support `long long' /usr/include/stdlib.h:114: warning: ANSI C does not support `long long' rm -f appres LD_LIBRARY_PATH=../../exports/lib cc -o appres -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -L../../exports/lib appres.o -lXt -lSM -lICE -lXext -lX11 -L/usr/X11R6/lib -Wl,-rpath,/usr/X11R6/lib ../../exports/lib/libXt.so: undefined reference to `pthread_cond_signal' /usr/X11R6/lib/libXThrStub.so.6: undefined reference to `_Xthr_zero_stub_' ../../exports/lib/libX11.so: undefined reference to `pthread_cond_broadcast' /usr/X11R6/lib/libXThrStub.so.6: undefined reference to `_Xthr_self_stub_' ../../exports/lib/libXt.so: undefined reference to `pthread_cond_init' ../../exports/lib/libXt.so: undefined reference to `pthread_mutex_unlock' ../../exports/lib/libXt.so: undefined reference to `pthread_self' ../../exports/lib/libXt.so: undefined reference to `pthread_mutex_destroy' ../../exports/lib/libXt.so: undefined reference to `pthread_mutex_lock' ../../exports/lib/libXt.so: undefined reference to `pthread_cond_wait' ../../exports/lib/libXt.so: undefined reference to `pthread_cond_destroy' ../../exports/lib/libXt.so: undefined reference to `pthread_mutex_init' *** Error code 1 i get the same errors when trying to compile wxWindows apps with: g++ -o proggy proggy.cpp `wx-config --libs` `wx-config --cxxflags` however i got my wxwindows apps to compile (with some warnings) adding -lc_r after the above line. i just recently build the world, i track RELENG_4 on a weekly basis, is this problem related to it? if don't, please provide me with any insight how to fix it. Thanks Gerardo To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dual booting current/stable on x86?
x86 bootloaders terrify me, so I have not tried grub. Does grub understand reiserfs? Yes. If you had ever worked with the source to LILO it would terrify you too. -Kip To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD on a MaxAttach?
Having had to make Lilo boot Linux on these boards I have some familiarity with
them. They don't have a standard BIOS, so they don't support the standard
routines that the newer bootloader expects (e.g. memory sizing). If you have
more questions feel free to follow up off list - I doubt the particulars of
these boards or CDS' custom/hacked version of FreeBSD 3.0 are of much interest
to those on the list. If need be I can contact the person who designed the
board - I know it is a bit of a kludge but he was working on a very limited time
frame. Also you'll find that the MAC address is stored on the boot ROM. Maxtor
has moved from FreeBSD to the Windows SAK so the newer boxes are likely to
have full BIOS support (they could not keep any of the CDS developers to
maintain the FreeBSD code base).
On Thu, 20 Jun 2002, Bruce A. Mah wrote:
Sorry to interrupt various flamewars with some actual technical
discussion... :-)
At ${REALJOB}, we've got a couple of Maxtor MaxAttach boxes we're trying
to play with. These are dedicated NFS/SMB servers. Physically they are
1U boxes with four 70GB IDE disks on them (wd0, wd1, wd2, wd3). They
have Pentium (P55C) processors, 128MB of RAM, an on-board fxp device, no
slots, and no removable media devices, all this on what appears to be a
semi-custom motherboard. We managed to find a serial console with the
help of a multimeter and an oscilloscope. The OS appears to be a
stripped-down FreeBSD 3.X...they have some kind of concatenated disk
driver that seems similar to ccd(4).
For various reasons, we're trying to figure out how to get a stock
FreeBSD 4-STABLE on them. We tossed in a scratch disk with 4.5-STABLE
as the primary master disk; the machine wouldn't even give a loader
prompt. We also tried booting with the existing wd0 and wd1, and our
disk on the secondary master; we could boot, but got a kernel panic
during an attempted boot to single-user mode...I suspect in the
concatenated disk driver trying to do some consistency checking.
I should mention that with all four of the original disks installed,
it functions properly, if slowly, as an NFS server. We're trying not
to wipe out the existing boot disk until we have at least a warm, furry
feeling that this is going to work. We haven't gotten that yet.
In theory we could put a populated obj/ tree on the existing disks and
use this to do a installkernel/installworld, but this commits us to a
course of action really early without an easy way to back out if
something goes wrong (see last paragraph).
Has anyone played around with one of these boxes?
Thanks in advance!
Bruce.
PS. It's crossed my mind that the staff time involved in making this
work could quickly exceed the cost of buying equivalent (maybe even
better) normal hardware. :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
