freebsd-update's install_verify routine excessive stating
Hackers,
Recently I decided it would be time to upgrade an older laptop that
was still running 6.2-RELEASE to a more recent release 7.1-RELEASE (re-
install not possible, laptop has no cd-rom drive, and does not boot
from a USB one).
Everything went well, including the kernel update. It was not until
after I rebooted and ran:
./freebsd-update.sh -f freebsd-update.conf install
That I started noticing something rather weird. It had been running
for a good 30 minutes before I started wondering what was going on.
top gave me nothing of value, other than that all of the time was
spent running sh, and that it was spending all of its time in system,
not user where I would have expected it. Thinking went wrong I stopped
the process and started it again.
After a ktrace and kdump I found the culprit in install_verify in the
freebsd-update utility, it would read one line, and then run stat on
one of the many files that was listed in /usr/upgrade/files/.
install_verify () {
# Generate a list of hashes
cat $@ |
cut -f 2,7 -d '|' |
grep -E '^f' |
cut -f 2 -d '|' |
sort -u filelist
# Make sure all the hashes exist
while read HASH; do
if ! [ -f files/${HASH}.gz ]; then
echo -n Update files missing --
echo this should never happen.
echo Re-run '$0 fetch'.
return 1
fi
done filelist
# Clean up
rm filelist
}
running find /usr/upgrade/files/ | wc -l showed over 64000 files. So
what was happening here is that freebsd-update.sh is doing due
diligence in checking that all the files exist, however it uses the
built in test utility to do so. While in normal situations this may
not be that big of a deal since the changeset is likely to be small,
running stat on 64000 individual files in a loop is rather slow.
In my case I have just removed the offending code and hoped all went
well, however this is off course not an acceptable solution. I have
not yet come up with an acceptable way to fix the offending code,
hence my post to hackers. I am also not sure as to how I would file a
pr bug report for this situation, any guidance would be greatly
appreciated.
This email has become much longer than I had originally intended. I
just wanted to get this out to see what you all had to say about this.
Cheers,
Bert JW Regeer
Re: Small change to 'ps'
On Jan 7, 2009, at 10:27 , Sheldon Givens wrote: On Wed, Jan 7, 2009 at 7:48 AM, Ulrich Spoerlein uspoerl...@gmail.comwrote: On Wed, 07.01.2009 at 08:54:41 -0600, Sean C. Farley wrote: On Wed, 7 Jan 2009, Ulrich Spoerlein wrote: On Tue, 06.01.2009 at 11:52:39 -0800, Sheldon Givens wrote: Hello everyone, It occurs to me that FreeBSD ps lacks the ability to disable header. This seems like a really obvious feature, and I may have simply missed it's existence (despite my relentlessly searching the man page) but here is a small patch that sets the flag 'n' to disable header output. You've missed it, probably because it is non-obvious: % ps -p 1 -o pid,cpu PID CPU 1 0 % ps -p 1 -o pid= -o cpu= 1 0 % Another way: ps | tail +2 I'm not sure about the portability of tail +N, I seem to remember that AIX doesn't support it. Therefore I'd rather use % ps | sed 1d which is way more portable. The three solutions above all work on my OpenSolaris machine (other than cpu=, since the field is named pcpu). I don't currently have access to HP-UX or AIX to test which do and do not work. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. Hello everybody, Ulrich: I appreciate your solution, but it ends up being a pretty ridiculous command when you start desiring 6 or 7 fields. Yes, which is why the sed/tail will do exactly what you want. UNIX was built on the fact that small tools together will work together to do something larger, no need to move all of the functionality into one tool, that creates maintenance nightmares and just complicates otherwise simple code. Sean: Ulrich is right in saying that tail +val is unreliable when coding for portability. And I guess I just feel like running a second command to do what should be possible to do with the first command (and is, on many platforms. ps --no-headers on linux for example) is a problem and presents opportunity for continued refinement of the utility. What other platforms besides Linux distributions? Just because they exist by the hundreds does not mean they are different platforms. xiste...@keyhole.network.lan:~$ ps -AflZ --no-headers ps: illegal option -- no-headers usage: ps [ -aAdefHlcjLPyZ ] [ -o format ] [ -t termlist ] [ -u userlist ] [ -U userlist ] [ -G grouplist ] [ -p proclist ] [ -g pgrplist ] [ -s sidlist ] [ -z zonelist ] [-h lgrplist] 'format' is one or more of: user ruser group rgroup uid ruid gid rgid pid ppid pgid sid taskid ctid pri opri pcpu pmem vsz rss osz nice class time etime stime zone zoneid f s c lwp nlwp psr tty addr wchan fname comm args projid project pset lgrp xiste...@keyhole.network.lan:~$ uname -a SunOS Keyhole.network.lan 5.11 snv_101b i86pc i386 i86pc Solaris I also read the entire man page for ps that is included and could not find a single way to not include a header by using a simple flag, in the man page they list the -o format as the only way to remove the header. HP-UX man page does not include an option either, besides the aforementioned -o format option: http://docs.hp.com/en/B2355-90690/ps.1.html Same goes for IBM's AIX system: http://publib16.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds4/ps.htm Just because Linux has it does not mean it is an improvement that should be imported. I think it is rather dumb idea really. What if in the future we add a new field to the output of ps to give more information (on Solaris for example, the -Z function lists what Zone the command is running in (global, or non-global)), this changes the amounts of fields that are listed. Now lets say some shell script that was written a few years ago requires a certain option to be located in field 7, and now that is moved over to field 8 it could cause all kinds of issues, instead if the command is written out with -o pid=, it is static and it won't change even if a new field is introduced to ps, thereby decreasing future issues, and increasing portability since you can select only the fields you require, making it more portable (if using standardised fields) because now the field will always be in the same place, no matter the platform. Sheldon Linuxisms that are bad should not be imported into FreeBSD. There is a valid and documented way to suppress the header information using ps, use it. If you are using this in a script of some sort, writing it out once will save you a lot of headache and trouble later. Bert JW Regeer
Re: 3 connections as one
On Jun 25, 2008, at 00:07 , Andres Chavez wrote: Hi, a friend is challenge me to make use of 3 different connections (one adsl, one cable, and one Evdo) as one single connection to internet, i believe for make faster downloads or something such, its that can be possible ?, if so, can anybody help me with this?, this sounds interesting for know tricks on the FreeBSD operating system, he need to use this box as the network manager and firewall as well, but the connection thing its killing me i dont know how. -- You could use PF's round-robin balancing to pick an outgoing connection: See: http://www.openbsd.org/faq/pf/pools.html#outgoing It contains examples and should help you get everything set up and working as you are asking for. One thing it won't do is make downloads faster, since it is not trunking, but if you have three downloads going, they might all use different paths, thus allowing you to utilise all connections, and thus have an over all faster connection. Bert JW Regeer
Re: libz.so no found
On May 22, 2008, at 10:19 , KAYVEN RIESE wrote: On Wed, 21 May 2008, Jeremy Chadwick wrote: On Wed, May 21, 2008 at 10:13:43PM -0700, KAYVEN RIESE wrote: kv_bsd#cd /usr/ports/distfiles kv_bsd#mv /usr/home/kayve/Nessus-3.2.0-fbsd7.tbz . kv_bsd#pkg_add Nessus-3.2.0-fbsd7.tbz You are running on FreeBSD 6.3 and you are trying to add a package that clearly has fbsd7 in the name. Off course it is not going to work. pkg_add: package VisualOS-1.0.5_3 has no origin recorded /libexec/ld-elf.so.1: Shared object libz.so.4 not found, required by nessusd First and foremost, you hijacked an existing thread by replying to it with regards to a completely different issue. Please don't do this, it confuses mail clients which follow thread references. Please don't hit reply on unrelated messages and start a new/unrelated discussion. i don't know wtf you are talking about these are all my threads. You clicked reply, or something along those lines on a previous message sent to the mailling list, thereby copying over some crucial information into the header of said email: In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] For mail clients that do threading, and show the conversation more as one would expect on a message board, your emails now look as if they belong underneath the topic named Hifn 7955 doesn't work with FreeBSD 7.0-RELEASE, which is annoying to most of us who would want your messages to show up in a new thread context. Next time, please just email hackers@ directly, and do not hi-jack the thread. Also, it is generally considered rude to suggest that you don't know what someone is talking about using the wtf. We point the hi-jacking out so that the mistake does not re-occur. Please refrain from such rudeness when people are attempting to help you. Secondly, the missing library error shown above would happen on machines running FreeBSD 6.x or earlier. /lib/libz.so.4 exists on RELENG_7. i am still on freeBSD 6.3 is this a serious problem? If you want to use the package you are using, yes. Since that package is clearly for FreeBSD 7. Another possibility is that something completely destroyed ld.so's shared library cache path. Of course, you'd be seeing all sorts of programs reporting missing libraries, and not just nexxus. so running freeBSD 6.3 is a fatal problem, or just extraneously irrelevant? Fatal, sure, especially if you want to use that package. If the startup script for nessus calls ldconfig or uses $LD_LIBRARY_PATH, that could explain the missing library. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http:// www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *--* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
zpool scrub tank high file system activity caused crash
information from the dump file. Give me commands and I shall be your terminal :P keyhole# zpool list NAMESIZEUSED AVAILCAP HEALTH ALTROOT tank374G180G194G48% ONLINE - keyhole# zpool status pool: tank state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM tankONLINE 0 0 0 ad2 ONLINE 0 0 0 ad3 ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 errors: No known data errors keyhole# zfs list NAME USED AVAIL REFER MOUNTPOINT tank 180G 188G18K /tank tank/archive 33.3G 188G 33.3G /usr/archive tank/media 146G 188G 146G /usr/media Bert JW Regeer
Re: zpool scrub tank high file system activity caused crash
On Mar 24, 2008, at 16:23 , Bert JW Regeer wrote: Hey guys, I am running FreeBSD 7.0-RELEASE with GENERIC on a AMD XP Athlon 3500+ with 1267 MB of ram, and a GigBit NIC. I am testing out ZFS just for the hell of it, I know, 32 bit is not suggested and runs badly, but it does what it needs to do. I was copying large amounts of data for backup purposes from my MacBook Pro to the machine over FTP. At the time I was looking around the man page for zpool, and figured I'd run a zpool scrub just to see how badly it affects performance. It affects it in that it takes down the machine with a dump. [...] Please let me know if you need any additional information from the dump file. Give me commands and I shall be your terminal :P keyhole# zpool list NAMESIZEUSED AVAILCAP HEALTH ALTROOT tank374G180G194G48% ONLINE - keyhole# zpool status pool: tank state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM tankONLINE 0 0 0 ad2 ONLINE 0 0 0 ad3 ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 errors: No known data errors keyhole# zfs list NAME USED AVAIL REFER MOUNTPOINT tank 180G 188G18K /tank tank/archive 33.3G 188G 33.3G /usr/archive tank/media 146G 188G 146G /usr/media Bert JW Regeer It crashed again, this time while vsftpd was running, which is the FTPD I am using to drop the files on the server. I am going to be going back to gconcat and friends for now. I will keep the dumps around if anyone needs me to run any commands on it, and find out more information! keyhole# kgdb kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/ libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x220 fault code = supervisor read, page not present instruction pointer = 0x20:0xc097b5f9 stack pointer = 0x28:0xe769e6c4 frame pointer = 0x28:0xe769e71c 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 = 1281 (vsftpd) trap number = 12 panic: page fault cpuid = 0 Uptime: 39m11s Physical memory: 1267 MB Dumping 348 MB: 333 317 301 285 269 253 237 221 205 189 173 157 141 125 109 93 77 61 45 29 13 #0 doadump () at pcpu.h:195 195 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:409 #2 0xc0754719 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a4905c in trap_fatal (frame=0xe769e684, eva=33554464) at /usr/ src/sys/i386/i386/trap.c:899 #4 0xc0a492e0 in trap_pfault (frame=0xe769e684, usermode=0, eva=33554464) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a49c8c in trap (frame=0xe769e684) at /usr/src/sys/i386/i386/ trap.c:490 #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc097b5f9 in vm_page_splay (pindex=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/vm_page.c:590 #8 0xc097bb96 in vm_page_remove (m=0xc1ce2e30) at /usr/src/sys/vm/ vm_page.c:722 #9 0xc097bdb1 in vm_page_free_toq (m=0xc1ce2e30) at /usr/src/sys/vm/ vm_page.c:1291 #10 0xc097bf86 in vm_page_free (m=0xc1ce2e30) at /usr/src/sys/vm/ vm_page.c:498 #11 0xc0978860 in vm_object_page_remove (object=0xc0bed860, start=53402, end=53434, clean_only=0) at /usr/src/sys/vm/vm_object.c: 1848 #12 0xc0973072 in vm_map_delete (map=Variable map is not available. ) at /usr/src/sys/vm/vm_map.c:2307 #13 0xc0973191 in vm_map_remove (map=0xc147108c, start=3438907392, end=3439038464) at /usr/src/sys/vm/vm_map.c:2423 #14 0xc09707d0 in kmem_free (map=0xc147108c, addr=3438907392, size=131072) at /usr/src/sys/vm/vm_kern.c:210 #15 0xc0967579 in page_free (mem=0xccf99000, size=131072, flags=34 '') at /usr/src/sys/vm/uma_core.c:1042 #16 0xc096a8b7 in uma_large_free (slab=0xc5988980) at /usr/src/sys/vm/ uma_core.c:2727 #17 0xc074542b in free (addr=0xccf99000, mtp=0xc0da0440) at /usr/src/ sys/kern/kern_malloc.c:444 #18 0xc0d2d597 in ?? () #19 0xccf99000 in ?? () #20
Re: zpool scrub tank high file system activity caused crash
On Mar 24, 2008, at 19:46 , Wesley Shields wrote: On Mon, Mar 24, 2008 at 04:23:19PM -0700, Bert JW Regeer wrote: Hey guys, I am running FreeBSD 7.0-RELEASE with GENERIC on a AMD XP Athlon 3500+ with 1267 MB of ram, and a GigBit NIC. I am testing out ZFS just for the hell of it, I know, 32 bit is not suggested and runs badly, but it does what it needs to do. I was copying large amounts of data for backup purposes from my MacBook Pro to the machine over FTP. At the time I was looking around the man page for zpool, and figured I'd run a zpool scrub just to see how badly it affects performance. It affects it in that it takes down the machine with a dump. keyhole# kgdb kernel.debug /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/ libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. Unread portion of the kernel message buffer: panic: vm_page_insert: offset already allocated cpuid = 0 Uptime: 10h58m58s Physical memory: 1267 MB Dumping 335 MB: 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 Out of curiosity, have you done any tuning on this machine? Specifically some of the stuff mentioned on the wiki? -- WXS I had not. I changed the size the kernel was allowed to be to at least 512 M as that is recommended, and I got the same panic as the first email I sent out (this time as seen in dmesg -a), I also ran out of space on /var so it did not save the vmcore :(. I am going to wait till I get my 64 bit system up and running before messing with ZFS again. I don't think the amount of ram I have in that machine would be enough with some of the other stuff it will have to do as well, if I let the kernel eat up to a GB. Bert JW Regeer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenBSD sdiff Question
On Mar 15, 2008, at 23:29 , David O'Brien wrote: On Sat, Mar 15, 2008 at 03:21:01PM -0700, Bert JW Regeer wrote: Even if BSD has no tradition to keep a separate program version, it is still very handy to be able to give this data to other developers if something is failing. $ ident failing-binary is the output that means something. A version string will not. Programs that don't have a -v or --version switch are frustrating to Anyone used to working on BSD will not expect a -v switch. It isn't part of BSD tradition. The simple fact there is no obivous version to print just shows that in a OS that is developed and built as a whole, having a version on the util is meaningless. Dropping -v would be a bad thing, and make the tools not compatible, thus breaking many scripts that do expect a -v. Come on, how many scripts do you write that do sdiff -v today? -- -- David ([EMAIL PROTECTED]) I see the reasoning behind dropping it now. It certainly make sense as you and Peter Jeremy describe it, I have just never thought of it that way. Cheers, Bert JW Regeer
Re: OpenBSD sdiff Question
On Mar 15, 2008, at 06:59 , Stanislav Sedov wrote: On Fri, Mar 14, 2008 at 07:14:04PM -0400 Steven Kreuzer mentioned: [...] For reference: $ sdiff -v sdiff (GNU diffutils) 2.8.7 Written by Thomas Lord. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. And my port from OpenBSD: $ ./sdiff -v sdiff (BSD diffutils) 602111 Written by Raymond Lai. This work has been released into the public domain. Do we really need to display program version on -v switch? BSD has no tradition to keep separate program version, it's just a part of an entire OS. I believe we might just abandone this switch. -- Stanislav Sedov ST4096-RIPE Even if BSD has no tradition to keep a separate program version, it is still very handy to be able to give this data to other developers if something is failing. Programs that don't have a -v or --version switch are frustrating to people who are trying to find a workaround for a bug that is in that program, or when looking at documentation online, when the documentation is for one version and not for a newer version. It is a lot like uname on Linux not displaying what distribution it is running, making it harder to quickly figure out where stuff is located. Dropping -v would be a bad thing, and make the tools not compatible, thus breaking many scripts that do expect a -v. Bert JW Regeer p.s. Sorry Stan about the double email. I replied to your privately first, and then noticed my mistake.
Re: memory not cleared on reboot (Was: cool feature of dmesg.boot file)
On Feb 22, 2008, at 02:25 , Jeremy Chadwick wrote: [...] Interesting tidbit: We have one production machine which when booted into single-user via serial console for a world install, retains all of the output from that single-user session even once rebooted and brought back into multi-user mode. This poses a substantial security risk, especially during the mergemaster phase (we can discuss why if anyone is curious). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | This is more scary: http://www.engadget.com/2008/02/21/cold-boot-disk-encryption-attack-is-shockingly-effective/ Which is the exact effect you are seeing. Cheerio, Bert JW Regeer
Re: encrypted executables
On Feb 20, 2008, at 20:18 , Joerg Sonnenberger wrote: On Wed, Feb 20, 2008 at 09:39:03PM -0500, ari edelkind wrote: Mind you, it's true that disabling core dumps with a resource limit doesn't keep one from creating a core image using gcore, but since gcore generally must either attach to a process using ptrace() or access mapped code segments in the original binary (depending on the implementation), it won't help in such a case, either. What prevents me from patching the kernel (!) to just ignore the resource limit? Nothing. Joerg Or for that matter ignoring the first ptrace() so that on the second ptrace call we make we can attach without a problem? On an open system like FreeBSD or Linux it is practically impossible to guarantee that the binary that is encrypted can't be tampered with in such a way, or have it's un-encrypted code dumped. Even on Windows this is hard, since the kernel is open for so many attack vectors, including but not limited to writing new kernel modules that hook certain kernel functions to do what I just mentioned. The openness of an Open Source system that allows an attacker to easily modify the OS the executables are running on is the biggest problem. There is no guaranteed code execution path, no guarantee that syscall's will do what you ask them to do. Bert JW Regeer
Re: /dev/dsp disappeared after power outage
On Feb 4, 2008, at 08:03 , John Baldwin wrote: On Saturday 02 February 2008 06:40:15 pm Aryeh M. Friedman wrote: I just had a power outage and when it came back /dev/dsp0.0 was missing from the devices. the kern module loaded fine and detected the card correctly (according to dmesg, sysctl and /dev/sndstat) but neither the above or /dev/pcm exists. After rebooting the problem remains. Any ideas how to fix it? Nothing to fix. This is how devfs device cloning works. -- John Baldwin Nothing to fix? The sound card that is correctly detected by the kernel module is not being created in /dev, ONLY after he had a power outage. It is not even coming back when he reboots the machine. I don't have any suggestions, I just don't believe Nothing to fix is the right answer. Bert JW Regeer
Re: /dev/dsp disappeared after power outage
On Feb 4, 2008, at 14:52 , Ulrich Spoerlein wrote: On Mon, 04.02.2008 at 13:00:40 -0700, Bert JW Regeer wrote: On Feb 4, 2008, at 08:03 , John Baldwin wrote: On Saturday 02 February 2008 06:40:15 pm Aryeh M. Friedman wrote: I just had a power outage and when it came back /dev/dsp0.0 was missing from the devices. the kern module loaded fine and detected the card correctly (according to dmesg, sysctl and /dev/sndstat) but neither the above or /dev/pcm exists. After rebooting the problem remains. Any ideas how to fix it? Nothing to fix. This is how devfs device cloning works. Nothing to fix? The sound card that is correctly detected by the kernel module is not being created in /dev, ONLY after he had a power outage. It is not even coming back when he reboots the machine. I don't have any suggestions, I just don't believe Nothing to fix is the right answer. Sigh, AFAIK dev cloning works by creating the device nodes when open()ed. Using 'ls /dev/dsp*' will not open() any devices, so nothing is created. He should use 'ls /dev/dsp0 /dev/dsp0.0' and then the devices should appear. Try it for yourself, do 'ls /dev/dsp*' then 'ls /dev/dsp.8' Not that anything usefull can be done with ls(1) to get sound :) Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. I just booted up my desktop machine at home, I don't have sound enabled by default, so I loaded the module that is required. Before the module was loaded: ls -lah /dev/dsp* ls: No match. After the module was loaded (I just load snd_driver). Nothing else was executed after the module was loaded. ls -lah /dev/dsp* crw-rw-rw- 1 root wheel0, 106 Jan 26 05:24 /dev/dsp0.0 crw-rw-rw- 1 root wheel0, 109 Jan 26 05:24 /dev/dsp0.1 crw-rw-rw- 1 root wheel0, 112 Jan 26 05:24 /dev/dsp0.2 crw-rw-rw- 1 root wheel0, 115 Jan 26 05:24 /dev/dsp0.3 crw-rw-rw- 1 root wheel0, 118 Jan 26 05:24 /dev/dsp0.4 crw-rw-rw- 1 root wheel0, 122 Jan 26 05:24 /dev/dsp0.5 crw-rw-rw- 1 root wheel0, 107 Jan 26 05:24 /dev/dspW0.0 crw-rw-rw- 1 root wheel0, 110 Jan 26 05:24 /dev/dspW0.1 crw-rw-rw- 1 root wheel0, 113 Jan 26 05:24 /dev/dspW0.2 crw-rw-rw- 1 root wheel0, 116 Jan 26 05:24 /dev/dspW0.3 crw-rw-rw- 1 root wheel0, 119 Jan 26 05:24 /dev/dspW0.4 crw-rw-rw- 1 root wheel0, 123 Jan 26 05:24 /dev/dspW0.5 crw-rw-rw- 1 root wheel0, 121 Jan 26 05:24 /dev/dspr0.4 So what gives? Bert JW Regeer
Re: 'periodic daily' memory usage
On Jan 27, 2008, at 05:55 , Dag-Erling Smørgrav wrote: 'periodic daily' runs my router out of swap every night, usually killing named as a result. From your email it sounds like you run bind in just a caching situation, have you looked at alternatives yet? For example dnscache from DJB, you give it a set amount of memory to use, and that is all it uses. [...] DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] Bert JW Regeer
Re: FreeBSD hacker 101
On Jan 24, 2008, at 22:58 , william wong wrote: That brings me to another ponder: why juniper and cisco are using FreeBSD and not Linux even Linux performs better in an UP environment? 2008/1/25, Dag-Erling Smørgrav [EMAIL PROTECTED]: william wong [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: william wong [EMAIL PROTECTED] writes: It seems that Juniper favors the even number FreeBSD's. Only because 5 was a dog. They probably stuck with 4 for a while, then switched to 6 once they had ascertained that it was significantly more stable than 5. I would be surprised if they skipped 7. Please pardon my ignorance of the jargons. Does that mean 5 is not stable or does not perform or what? FreeBSD 5 was not a very good series. It was released late and had issues with both stability and performance. FreeBSD 6 corrected the stability issues and some of the worst performance issues. FreeBSD 7 took care of the remaining performance issues; it may not be as fast as 4 was on UP, but it beats Linux on SMP. (there's no point in comparing SMP performance between 4 and 7 since 4 had a single-threaded kernel and practically no userland thread support) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] Please do not top post. The reason Juniper and Cisco are probably using FreeBSD is because of the license that FreeBSD is under (BSD-License) versus the Linux kernels GPL. Bert JW Regeer
Using freebsd-update to install a clean system
Hello,
I am working on a tool to automatically provision new servers, and
currently have it working properly using netboot, the way we currently
do it is to have our own /usr/src and /usr/obj that we keep up to date
with the latest patches and versions. The machines netboot an image,
that NFS mounts those, and fdisks/bsdlabels the local disk and mount
that as /target/{tmp,usr,var}, from there we set DESTDIR and run make
{installworld, installkernel, distrib-dirs, distribution}, write out
an fstab file, set up a simple rc.conf and let the machine reboot.
This process works great, however for stability reasons we are not
able to rebuild the source tree, each time an advisory comes out, and
would like a better way of automating this system. Now that freebsd-
update looks like it is going to be a first class citizen, we would
like to take advantage of it always being up to date, we would want to
run our own local update server, and then using freebsd-update install
an entire distribution, from scratch without first installing one from
compiled sources.
Is this possible? Is there some way I can tell freebsd-update to
target /target/ and install every part that we would need (kernel/
generic, world/base, world/manpages), without there already being a
system installed in that location?
While using -b partially works, it throws back all kinds of errors:
install: /target//boot/kernel/3dfx_linux.ko.symbols: No such file or
directory
install: /target//boot/kernel/aac.ko.symbols: No such file or directory
install: /target//boot/kernel/aac_linux.ko.symbols: No such file or
directory
install: /target//boot/kernel/accf_data.ko.symbols: No such file or
directory
install: /target//boot/kernel/accf_http.ko.symbols: No such file or
directory
Also, looking at the freebsd-update.sh script, sometimes it does not
have ${BASEDIR} in front of what it is doing, for example on line 2492:
kldxref -R /boot/ 2/dev/null
Would that not have to be:
kldxref -R ${BASEDIR}/boot/ 2/dev/null ?
Thank you,
Bert JW Regeer
Re: dlopen(), atexit() crash on FreeBSD (testcase included)
On Jan 1, 2008, at 19:41 , Tim Kientzle wrote: Also, I'm wondering how other OSes handle this. I don't see this code crash on Linux, contrary to its design as you say. I would be curious to see the results of running your sample program ... on Linux to see whether it calls the registered exit function at dlclose time or never. Linux pulls hidden atexit symbol into every binary that uses it ... Linux calls atexit entries at object unload time. Solaris implements a libc callback from ld.so.1 ... Solaris calls atexit callback when removing it too. Interesting. So the consensus here (at least for Linux and Solaris, anyone know about Mac OS?) seems to be that atexit() can be called from a dynamically loaded library and that functions registered this way will be called at library unload time. And sigh FreeBSD doesn't implement this behavior. Tim Kientzle Mac OS X (10.5.1) $ gcc -dynamiclib -o atexitmod.so atexitmod.c $ gcc -o datest datatest.c $ ./datest hello driver now exiting $ uname -a Darwin WideLoad.lan 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 $ gcc --version i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465) I guess Mac OS X calls atexit() somehow. I don't know the internals of Mac OS X, just wanted to post that the example given in this thread works as one would semi-expect, and thus possibly against the spec. Bert JW Regeer
Re: kqueue and libev
On Dec 15, 2007, at 08:47 , Kip Macy wrote: 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 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 How recently? I have been using kqueue with pipes in several programs for the last year or so. Bert JW Regeer
Re: Updated procstat(1)
On Nov 28, 2007, at 5:46 AM, Robert Watson wrote: On Wed, 28 Nov 2007, Skip Ford wrote: Skip Ford wrote: Robert Watson wrote: On Wed, 28 Nov 2007, Skip Ford wrote: - -a now means all processes, Thanks. :-) I'm a little surprised. You seemed pretty dedicated to a per-process tool. I was, but then I read your e-mail and became convinced that the first patch that would be submitted against procstat(1) would be a -a patch. :-) Yep, would've happened. Now the first patch submitted will be a - w interval patch... :-) I couldn't resist implementing a crude interval arg just for kicks. Here's the output of find(1) every second. This is so cool: Very neat :-). If you like this, you'll love DTrace, which allows you to do all sorts of things along these lines. I'll add a -w mode, but be aware that if you want to do the below, what you really want is DTrace :-), which allows you do do things like sample kernel stack traces on the clock timer, based on function invocations, etc, so you can do things like say sample all the paths to a particular kernel function. Now that John is updating DTrace again, I hope that we'll be seeing it in the 8-CURRENT source RSN. Robert N M Watson Computer Laboratory University of Cambridge Sorry, just a bit off topic Have the licensing issues been resolved with regards to DTrace? This is a feature I was looking forward to in 7.0-RELEASE but it had been delayed because of the licensing. Bert JW Regeer
MacBook Pro 2.4 Ghz Santa Rosa
Hey, As I had recently purchased a new MacBook Pro, I have one of the brand new shiny ones with the Santa Rosa chipset. I have been trying to run FreeBSD 7.0-BETA1.5 and 8.0-SURPRISE on it, and everything goes well except the following issues: 1. Sometimes it will hang for ever on the ACPI initialisation. Sometimes it will come out of it and continue booting, and other times it will require a hard power down. Really hit and miss. I first downloaded 7.0-BETA1.0, or 8.0-SURPRISE, and recompiled a new kernel on it with the latest source from -HEAD and that caused it to die with a failure to start the second core in my machine. FreeBSD 6.2 will sometimes boot and sometimes not boot, same as 7.0 hanging on ACPI. For FreeBSD 6.2 I am able to fix it by hitting the power button a few times. 2. The Marvell Gigbit NIC is not yet supported. I can provide output from pciconf -lv if need be, let me know. Have not yet tried the if_myk driver from Marvell themselves. 3. The Atheros chipset 5424 card is not yet supported either. Output Mac OS X has in it's dmesg for this wireless card: ath_attach: devid 0x24 Override HT40 CTL Powers. EEPROM Version is 14.4, Device Type 5 ath_descdma_setup: tx dd_desc_paddr = 0x76475000, length 0x46500 (288000) bytes ath_descdma_setup: beacon dd_desc_paddr = 0x65b6e000, length 0x90 (144) bytes mac 12.10 phy 8.1 radio 12.0 AirPort_Athr5424ab: Ethernet address 00:1c:b3:c0:82:cb I am looking forward to the day that I may run FreeBSD with xfce on this laptop, side by side with Mac OS X. Bert JW Regeer
Re: FreeBSD + D-Link DWL-G520M
On Aug 27, 2007, at 10:18 AM, Nemesis stars wrote: Hi. I was install FreBSD Next I download Windowds driver: ar5513.sys net5513.cat net5513.inf Next I make it # ndisegn ar5513.sys net5513.inf net5513.cat in result - I have that : ar5513.sys.ko net5513.cat.ko Then I make kernel with: options NDISAPI device ndis device wlan These files I copy in /boot/kernel/ And edit /boot/loader.conf ar5513_sys_load=YES net5513_cat_load=YES Then reboot ;-) BUT!!! if I do: ifconfig ndis0 ssid Wi-Fi.5-stars channel 11 media DS/11Mbps mediaopt hostap up stationname Wi-Fi.5-stars I have: NDIS0: setting BSSID failed: 45 ifconfig: SIOCS80211: Invalid argument I ask in support. They said what NDIS coudn't changed SSID because NDIS not support the Wirless-Card. ENG.txtRUS.txt___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers- [EMAIL PROTECTED] According to this thread: http://lists.freebsd.org/pipermail/freebsd- hardware/2007-May/004426.html Sam was working on the chipset that is in that card. Contact him and see if he can help you out getting it working natively. I don't believe you can set up hostap's with NDIS wrapper. Bert JW Regeer
Re: device rue causes kernel panic
On Jul 7, 2007, at 9:14 PM, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
M. Warner Losh [EMAIL PROTECTED] writes:
: In message: [EMAIL PROTECTED]
: Bert JW Regeer [EMAIL PROTECTED] writes:
: : I have a USB 10/100 FastEthernet device, that is identified as a
: : RealTek device. On 6.2-RELEASE it works without any issues, and
some
: : older versions of CURRENT it worked perfectly as well. I
csup'ed to
: : CURRENT today (2007-07-07 at 16:30 MST), rebuild my kernel and it
: : failed:
: : panic (fmt=0xc0a94933 Trying sleep, but thread marked as
sleeping prohibited)
: : _sleep (ident=0xc2322c00...) at /usr/src/sys/kern/kern_synch.c:201
: : usbd_transfer (xfer=0xc2322c00) at /usr/src/sys/dev/usb/usbdi.c:
333
: : usbd_sync_transfer (xfer=0xc2322c00) at /usr/src/sys/dev/usb/
usbdi.c:406
: : usbd_do_request_flags_pipe ... at /usr/src/sys/dev/usb/usbdi.c:
1098
: : usbd_do_request_flags ...at /usr/src/sys/dev/usb/usbdi.c:1068
: : usbd_do_request at /usr/src/sys/dev/usb/usbdi.c:1060
: : rue_read_mem at /usr/src/sys/dev/usb/if_rue.c:227
: : rue_csr_read_1 at /usr/src/sys/dev/usb/if_rue.c:276
: : rue_miibus_readreg at /usr/src/sys/dev/usb/if_rue.c:376
: ...
: : ruephy_service at miibus_if.h:26/* Likely wrong */
: : mii_tick at /usr/src/sys/dev/mii/mii.c:390
: : rue_tick at /usr/src/sys/dev/usb/if_rue.c:935
: : softclock at /usr/src/sys/kern/kern_timeout.c:281
: ...
:
: This driver needs to be re-written ala aue, axe, kue and udav to
use a
: taskqueue for the mii ticking. It appears to be the only usb driver
: in the tree to still do stuff directly in a callout. This context
: can't sleep...
You might try this patch.
Warner
Index: if_rue.c
===
RCS file: /cache/ncvs/src/sys/dev/usb/if_rue.c,v
retrieving revision 1.39
diff -u -r1.39 if_rue.c
--- if_rue.c20 Jun 2007 05:10:52 - 1.39
+++ if_rue.c8 Jul 2007 04:13:16 -
@@ -142,6 +142,7 @@
static void rue_rxeof(usbd_xfer_handle, usbd_private_handle,
usbd_status);
static void rue_txeof(usbd_xfer_handle, usbd_private_handle,
usbd_status);
static void rue_tick(void *);
+static void rue_tick_task(void *);
static void rue_rxstart(struct ifnet *);
static void rue_start(struct ifnet *);
static int rue_ioctl(struct ifnet *, u_long, caddr_t);
@@ -594,6 +595,8 @@
goto error;
}
+ usb_init_task(sc-rue_tick_task, rue_tick_task, sc);
+
err = usbd_device2interface_handle(uaa-device, RUE_IFACE_IDX,
iface);
if (err) {
device_printf(sc-rue_dev, getting interface handle failed\n);
@@ -704,6 +707,7 @@
sc-rue_dying = 1;
untimeout(rue_tick, sc, sc-rue_stat_ch);
+ usb_rem_task(sc-rue_udev, sc-rue_tick_task);
ether_ifdetach(ifp);
if_free(ifp);
@@ -916,6 +920,20 @@
static void
rue_tick(void *xsc)
{
+ struct rue_softc *sc = xsc;
+
+ if (sc == NULL)
+ return;
+ if (sc-rue_dying)
+ return;
+
+ /* Perform periodic stuff in process context */
+ usb_add_task(sc-rue_udev, sc-rue_tick_task, USB_TASKQ_DRIVER);
+}
+
+static void
+rue_tick_task(void *xsc)
+{
struct rue_softc*sc = xsc;
struct ifnet*ifp;
struct mii_data *mii;
Index: if_ruereg.h
===
RCS file: /cache/ncvs/src/sys/dev/usb/if_ruereg.h,v
retrieving revision 1.7
diff -u -r1.7 if_ruereg.h
--- if_ruereg.h 12 May 2007 05:53:53 - 1.7
+++ if_ruereg.h 8 Jul 2007 04:11:39 -
@@ -204,6 +204,7 @@
charrue_dying;
struct timeval rue_rx_notice;
struct usb_qdat rue_qdat;
+ struct usb_task rue_tick_task;
};
#if defined(__FreeBSD__)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-
[EMAIL PROTECTED]
This patch works, in that no more Kernel panics are created, however
the following did show up in dmesg//var/log/messages as I was using
dhclient rue0:
Jul 7 16:15:53 FreeBSD-VMWare root: Unknown USB device: vendor
0x0bda product 0x8150 bus uhub0
Jul 7 16:15:53 FreeBSD-VMWare kernel: rue0: USBKR100 USB 10/100
LAN, class 0/0, rev 1.10/1.00, addr 2 on uhub0
Jul 7 16:15:53 FreeBSD-VMWare kernel: miibus0: MII bus on rue0
Jul 7 16:15:53 FreeBSD-VMWare kernel: ruephy0: RealTek RTL8150
internal media interface PHY 0 on miibus0
Jul 7 16:15:53 FreeBSD-VMWare kernel: ruephy0: 10baseT, 10baseT-
FDX, 100baseTX, 100baseTX-FDX, auto
Jul 7 16:15:53 FreeBSD-VMWare kernel: rue0: using obsoleted
if_watchdog interface
Jul 7 16:15:53 FreeBSD-VMWare kernel: rue0: Ethernet address:
00:10:60:e0:ab:a8
Jul 7 16:15:53 FreeBSD-VMWare kernel: rue0: if_start running
deferred for Giant
Jul 7 16:15:53 FreeBSD-VMWare
Re: add closefrom() call
On Jul 6, 2007, at 9:57 AM, Julian Elischer wrote: Robert Watson wrote: On Fri, 6 Jul 2007, Julian Elischer wrote: Ed Schouten wrote: * LI Xin [EMAIL PROTECTED] wrote: Here is my implementation for FreeBSD. Some difference between my and DragonFly's implementation: - closefrom(-1) would be no-op on DragonFly, my version would close all open files (From my understanding of OpenSolaris's userland implementation, this is Solaris's behavior). - my version closefrom(very_big_fd) would result in EBADF. I am not very sure whether this is correct, but it does not hurt for applications that thinks closefrom() would return void. Wouldn't it be better to just implement it through fcntl() and implement closefrom() in libc? that's a possibility but I personally thing the huge difference in efficiency makes it worth putting it in the kernel. Quite a few programs I know of could really help their startup time with this as the first thing they do is close the first 2000 file descriptors. The Solaris implementation appears to implement two strategies: (1) If procfs is mounted, list the fd directory to get a list of open fds, then close those by number. (2) If procfs is not mounted, query the number of open fds using the resource limit interface, then sequentially close until the right number close. Hence my question as to whether there's actually a big benefit or not -- do we think closefrom() is a performance-critical function? It's one of those things where it's so simple to do it that it hardly seems worth arguing about the colour, or even whether colour is spelled color or colour. Robert N M Watson Computer Laboratory University of Cambridge So guys, where can I pick up my bike-shed? Bert JW Regeer
device rue causes kernel panic
Hello, I have a USB 10/100 FastEthernet device, that is identified as a RealTek device. On 6.2-RELEASE it works without any issues, and some older versions of CURRENT it worked perfectly as well. I csup'ed to CURRENT today (2007-07-07 at 16:30 MST), rebuild my kernel and it failed, so I grabbed the hard drive, made a copy into a VMWare image, recompiled the same CURRENT with debugging enabled, and retrieved the following backtrace from kgdb from a secondary VMWare running FreeBSD 6.2-RELEASE with kgdb: (kgdb) bt #0 kdb_enter (msg=0xc0a90fed panic) at /usr/src/sys/kern/ subr_kdb.c:310 #1 0xc074b9b4 in panic (fmt=0xc0a94933 Trying sleep, but thread marked as sleeping prohibited) at /usr/src/sys/kern/kern_shutdown.c:547 #2 0xc077a912 in sleepq_add (wchan=0xc2322c00, lock=0x0, wmesg=0xc0a85dc8 usbsyn, flags=0, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:289 #3 0xc0753d33 in _sleep (ident=0xc2322c00, lock=Variable lock is not available. ) at /usr/src/sys/kern/kern_synch.c:201 #4 0xc06cc498 in usbd_transfer (xfer=0xc2322c00) at /usr/src/sys/dev/ usb/usbdi.c:333 #5 0xc06cc5e6 in usbd_sync_transfer (xfer=0xc2322c00) at /usr/src/ sys/dev/usb/usbdi.c:406 #6 0xc06cc678 in usbd_do_request_flags_pipe (dev=0xc2275300, pipe=0xc2275100, req=0xcbd46bb8, data=0xcbd46bd3, flags=Variable flags is not available. ) at /usr/src/sys/dev/usb/usbdi.c:1098 #7 0xc06cc7cc in usbd_do_request_flags (dev=0xc2275300, req=0xcbd46bb8, data=0xcbd46bd3, flags=Variable flags is not available. ) at /usr/src/sys/dev/usb/usbdi.c:1068 #8 0xc06cc807 in usbd_do_request (dev=0xc2275300, req=0xcbd46bb8, data=0xcbd46bd3) at /usr/src/sys/dev/usb/usbdi.c:1060 #9 0xc06ae924 in rue_read_mem (sc=0xc2264d00, addr=Variable addr is not available. ) at /usr/src/sys/dev/usb/if_rue.c:227 #10 0xc06ae9cc in rue_csr_read_1 (sc=Variable sc is not available. ) at /usr/src/sys/dev/usb/if_rue.c:276 #11 0xc06aea47 in rue_miibus_readreg (dev=0xc2275080, phy=0, reg=311) at /usr/src/sys/dev/usb/if_rue.c:376 #12 0xc05f01eb in miibus_readreg (dev=0xc2274d00, phy=0, reg=311) at miibus_if.h:26 #13 0xc05f5b6e in ruephy_service (sc=0xc2278440, mii=0xc2278d00, cmd=1) at miibus_if.h:26 #14 0xc05efc14 in mii_tick (mii=0xc2278d00) at /usr/src/sys/dev/mii/ mii.c:390 #15 0xc06aef53 in rue_tick (xsc=0xc2264d00) at /usr/src/sys/dev/usb/ if_rue.c:935 #16 0xc075d229 in softclock (dummy=0x0) at /usr/src/sys/kern/ kern_timeout.c:281 #17 0xc0730905 in ithread_loop (arg=0xc21152b0) at /usr/src/sys/kern/ kern_intr.c:1036 #18 0xc072dd88 in fork_exit (callout=0xc0730750 ithread_loop, arg=0xc21152b0, frame=0xcbd46d38) at /usr/src/sys/kern/kern_fork.c:797 #19 0xc09e0820 in fork_trampoline () at /usr/src/sys/i386/i386/ exception.s:205 Steps to reproduce: 1. Plug in a rue device 2. plug in a cable so that it's status is active 3. ifconfig rue0 up 4. Wait for the kernel to panic about a second or so later If there is anything else you guys need me to do, please let me know and I will see what I can do. Bert JW Regeer p.s. I am not on the [EMAIL PROTECTED] mailling list, please CC all replies to me.
Re: i386 with PAE or AMD64 on PowerEdge with 4G RAM
On Jun 21, 2007, at 6:24 PM, Julian H. Stacey wrote: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote: Jeremy Chadwick [EMAIL PROTECTED] writes: Like I said, I don't run 64-bit OSes because I prefer compatibility. Believe me, the instant you run into some quirky problem with either the kernel or any of its subsystems, or a third-party program (from ports or otherwise), the first thing you'll be told is it works for me on i386, have you tried i386? Absolute nonsense. FreeBSD is just as solid on amd64 as on i386, and A while back I reverted my AMD Athlon(tm) 64 Processor 3000+ (2010.06-MHz 686-class CPU) from 64 to 32 bit, 'cos of bad ports. ls /var/db/pkg | wc -l # 536 Not that I use them all, they just accumulate. FreeBSD is as solid as damp cement on many old laptops ( http://berklix.org/~jhs/hardware/laptops/ ) ie doesn't install beyond 4.11. No time for ports pain as well as base install failures. Eh? I would like to contest this statement. I own several old Thinkpads, an Toshiba Portege and NONE of them have had any problems what so ever. My Toshiba is running -CURRENT without any issues what so ever. Damp cement? WTH? -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http:// berklix.com HTML mail unseen. Ihr Rauch=mein allergischer Kopfschmerz. Dump cigs 4 snuff. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers- [EMAIL PROTECTED]
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
On May 14, 2007, at 10:03 PM, Garrett Cooper wrote: Bert JW Regeer wrote: On May 12, 2007, at 5:14 AM, Philippe Laquet wrote: Stanislav Sedov a écrit : On Fri, 11 May 2007 02:10:05 +0200 Ivan Voras [EMAIL PROTECTED] mentioned: - I think it's time to give up on using BDB+directory tree full of text files for storing the installed packages database, and I propose all of this be replaced by a single SQLite database. SQLite is public domain (can be slurped into base system), embeddable, stores all data in a single file, lightweight, fast, and can be used to do fancy things such as reporting. What is the reason to use SQL-based database? You'll perform direct queries to database? The packaging system is for ordinal users, not sql geeks, so they should not have to use sql for managing packages. So a simple set of hashes will suffer or needs. I agree with Julian that we should have a backup of packaging database in plain text format, and utility to rebuild it. This way we can always restore the database if something goes wrong. Furhtermore, that should not make a great impact on performance, since we don't have to rebuild it every day. I agree with Stan ;) fast and improved package utilities uses mainly some indexed berkeley DB combined with flat files, aren't they? I, and may be many other FreeBSD users use light systems for efficiency and easier management, if we use some database system it will require Disk Space, resources for the DB to run, dependencies and so on... And we also may be exposed to a that DB is better war ;) SQLite is compiled inside a program, and as such does not require any resources other than one file handle and some CPU time when querying. The file is stored on disk, and requires no separate process to be running to query. Maybe I misunderstood what you were trying to say. SQLite will require less resources than flat text files, since SQLite is a one time open then process, instead of what is currently happening, having to open and close hundreds of files depending on how many ports are installed. With this regard, SQLite is like BDB. Where SQLite uses standards compliant SQL statements to get data. Correct. From what I was reading shared memory read access and locking are two available features of BDB databases. The only thing is that I do agree that there should be a dumping and importing mechanism of some kind for semi-formatted text files, for backup, debugging, and modification purposes. That's just my personal idea on the topic though :). -- Stanislav Sedov ST4096-RIPE I am able to understand many of the gripes with using a databases, and have to import yet another code base into the FreeBSD base, however as one of the young ones, and knowing sed/awk/grep and SQL, I prefer SQL over having to process hundreds of text files using text processing tools. It saddens me each time I run one of the pkg_* tools that needs to parse the flat file structure since it takes so long. I have friends running Ubuntu and their apt-get returns results much faster. In a world where hard drives are becoming more reliable, and are automatically relocating sectors that go bad, do we really have to worry about database corruption as much? I feel that many of the fears that are being put forward will do harm to a text based storage system as well. If one block drops out, it can cause tools to not be able to parse the files. Create a backup copy of the database after each successful transaction? There are ways to battle data corruption. True. I was thinking of backup, and recreation from scratch, considering that the database wouldn't be more than a few megs. In place replacement just seems like a hairy situation sometimes.. Using BDB is not an real option either. I can not even count the amount of times that the BDB database that portupgrade created has become corrupt because I accidently ran two portupgrades at the same time, or even remembered that I did not want to upgrade something and hit Ctrl+C. I'm sorry but nothing's completely solid in that respect, AFAIK. In terms of the first problem you mentioned, Wade is working on the locking http://wiki.freebsd.org/WadeWesolowsky. In terms of transactions, maybe we should take a look at Subversion for inspiration: http://svn.haxx.se/dev/ archive-2005-03/0301.shtml. I'm a firm believer that it's easier to incorporate code than it is to remove it. I am unable to see any references to transaction support for BDB databases, maybe I am missing something. Subversion in that thread is suggesting SQL for a totally different reason. fsfs is what most people are using as a subversion backend to help avoid BDB corruption. From the many people I have talked to that used to use Subversion with BDB have had major issues, whereas fsfs has not had any issues at all. Just what I have experienced myself as a Subversion
Re: Experiences with 7.0-CURRENT and vmware.
On May 10, 2007, at 5:54 AM, Darren Reed wrote: [...] But if if_em is probing, it suggests a VMware change rather than a FreeBSD change, which you may be able to revert by telling it to expose a Lance-style device as opposed to an Intel device. There's no way to choose the type of card vmware emulates. I always set my VMWare to expose an intel e1000 card, which gets probed correctly by almost all systems, even Windows with the Intel drivers installed. In your .vmx file you should find a line like this: ethernet0.virtualDev=e1000 If VMWare is to give an em device, if you remove that line it should default back to lnc driver. That being said, I have had no performance problems with the em driver on FreeBSD 6.0 in VMWare, and have not had the timeout problems you mentioned. Darren Bert JW Regeer
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
On May 12, 2007, at 5:14 AM, Philippe Laquet wrote: Stanislav Sedov a écrit : On Fri, 11 May 2007 02:10:05 +0200 Ivan Voras [EMAIL PROTECTED] mentioned: - I think it's time to give up on using BDB+directory tree full of text files for storing the installed packages database, and I propose all of this be replaced by a single SQLite database. SQLite is public domain (can be slurped into base system), embeddable, stores all data in a single file, lightweight, fast, and can be used to do fancy things such as reporting. What is the reason to use SQL-based database? You'll perform direct queries to database? The packaging system is for ordinal users, not sql geeks, so they should not have to use sql for managing packages. So a simple set of hashes will suffer or needs. I agree with Julian that we should have a backup of packaging database in plain text format, and utility to rebuild it. This way we can always restore the database if something goes wrong. Furhtermore, that should not make a great impact on performance, since we don't have to rebuild it every day. I agree with Stan ;) fast and improved package utilities uses mainly some indexed berkeley DB combined with flat files, aren't they? I, and may be many other FreeBSD users use light systems for efficiency and eaiser management, if we use some database system it will require Disk Space, ressources for the DB to run, dependencies and so on... And we also may be exposed to a that DB is better war ;) SQLite is compiled inside a program, and as such does not require any resources other than one file handle and some CPU time when querying. The file is stored on disk, and requires no separate process to be running to query. Maybe I misunderstood what you were trying to say. SQLite will require less resources than flat text files, since SQLite is a one time open then process, instead of what is currently happening, having to open and close hundreds of files depending on how many ports are installed. With this regard, SQLite is like BDB. Where SQLite uses standards compliant SQL statements to get data. -- Stanislav Sedov ST4096-RIPE I am able to understand many of the gripes with using a databases, and have to import yet another code base into the FreeBSD base, however as one of the young ones, and knowing sed/awk/grep and SQL, I prefer SQL over having to process hundreds of text files using text processing tools. It saddens me each time I run one of the pkg_* tools that needs to parse the flat file structure since it takes so long. I have friends running Ubuntu and their apt-get returns results much faster. In a world where hard drives are becoming more reliable, and are automatically relocating sectors that go bad, do we really have to worry about database corruption as much? I feel that many of the fears that are being put forward will do harm to a text based storage system as well. If one block drops out, it can cause tools to not be able to parse the files. Create a backup copy of the database after each successful transaction? There are ways to battle data corruption. Using BDB is not an real option either. I can not even count the amount of times that the BDB database that portupgrade created has become corrupt because I accidently ran two portupgrades at the same time, or even remembered that I did not want to upgrade something and hit Ctrl+C. The experience I got from running SVN with BDB as the back-end database to store my data, I say no thanks. In that case I would much rather stick with the flat text files than go with a database. Bert JW Regeer
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
On May 12, 2007, at 5:14 AM, Philippe Laquet wrote: Stanislav Sedov a écrit : On Fri, 11 May 2007 02:10:05 +0200 Ivan Voras [EMAIL PROTECTED] mentioned: - I think it's time to give up on using BDB+directory tree full of text files for storing the installed packages database, and I propose all of this be replaced by a single SQLite database. SQLite is public domain (can be slurped into base system), embeddable, stores all data in a single file, lightweight, fast, and can be used to do fancy things such as reporting. What is the reason to use SQL-based database? You'll perform direct queries to database? The packaging system is for ordinal users, not sql geeks, so they should not have to use sql for managing packages. So a simple set of hashes will suffer or needs. I agree with Julian that we should have a backup of packaging database in plain text format, and utility to rebuild it. This way we can always restore the database if something goes wrong. Furhtermore, that should not make a great impact on performance, since we don't have to rebuild it every day. I agree with Stan ;) fast and improved package utilities uses mainly some indexed berkeley DB combined with flat files, aren't they? I, and may be many other FreeBSD users use light systems for efficiency and eaiser management, if we use some database system it will require Disk Space, ressources for the DB to run, dependencies and so on... And we also may be exposed to a that DB is better war ;) SQLite is compiled inside a program, and as such does not require any resources other than one file handle and some CPU time when querying. The file is stored on disk, and requires no separate process to be running to query. Maybe I misunderstood what you were trying to say. SQLite will require less resources than flat text files, since SQLite is a one time open then process, instead of what is currently happening, having to open and close hundreds of files depending on how many ports are installed. With this regard, SQLite is like BDB. Where SQLite uses standards compliant SQL statements to get data. -- Stanislav Sedov ST4096-RIPE I am able to understand many of the gripes with using a databases, and have to import yet another code base into the FreeBSD base, however as one of the young ones, and knowing sed/awk/grep and SQL, I prefer SQL over having to process hundreds of text files using text processing tools. It saddens me each time I run one of the pkg_* tools that needs to parse the flat file structure since it takes so long. I have friends running Ubuntu and their apt-get returns results much faster. In a world where hard drives are becoming more reliable, and are automatically relocating sectors that go bad, do we really have to worry about database corruption as much? I feel that many of the fears that are being put forward will do harm to a text based storage system as well. If one block drops out, it can cause tools to not be able to parse the files. Create a backup copy of the database after each successful transaction? There are ways to battle data corruption. Using BDB is not an real option either. I can not even count the amount of times that the BDB database that portupgrade created has become corrupt because I accidently ran two portupgrades at the same time, or even remembered that I did not want to upgrade something and hit Ctrl+C. The experience I got from running SVN with BDB as the back-end database to store my data, I say no thanks. In that case I would much rather stick with the flat text files than go with a database. Bert JW Regeer
Re: Apache2 Virtual Hosts and FreeBSD fd limits.
On May 3, 2007, at 9:30 AM, Eduardo Meyer wrote:
# uname -a
5.5-STABLE FreeBSD 5.5-STABLE #6: Wed May 2 20:19:43 BRT 2007
# apachectl -v
Server version: Apache/2.0.59
Server built: May 2 2007 18:38:18
I have raised maxfiles, but my openfiles do increase and the
problem
with Apache persists.
Does it only affect Apache?
Certainly not. But my concert is Apache, and this is the only
application this server runs.
I have also compiled EXTRA_FLAGS=-DFD_SETSIZE=8192 (currently, it was
2048) and the results were just the same.
Steve
--
===
Eduardo Meyer
pessoal: [EMAIL PROTECTED]
profissional: [EMAIL PROTECTED]
Since this is my first post to the mailling list, top post or bottom
post which one is preferred?
If you have a problems with open file descriptors beccause of
VirtualHosts it is my guess that you are logging separately for each
vhost (both access, and error). The way I found to solve this was to
put it all in one file that is then split up into the separate files
using a perl script. It is called split-logfile and can be found
online, I believe it was in the Apache source tree. All you need to
change is instead of having seperate log files for each of them, you
have one log file (which outputs the information using the vhost name
as the first item on the line so that the perl script can sort it
through that), thus only one FD is used to log.
LogFormat %v %h %l %u %t \%r\ %s %b \%{Referer}i\ \%{User-
Agent}i\ cvh
CustomLog /usr/local/logs/everything.log cvh
So you can scale out to 5000 vhosts and not run into any limit
problems. For errors the splitting up is a bit more tricky, but you
should be able to get it done as well.
Good luck,
Bert JW Regeer
