Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Tue, Jul 10, 2012 at 12:18 AM, Doug Barton do...@freebsd.org wrote: But I think you are wrong about this one aspect of your proposed change. To discover that dig is suddenly not in the base FreeBSD system any more some day would be just about the worst violation of the Principle of Least Astonishment for me in many years. All flippancy aside, I understand what you're saying here. The problem is that we can't keep BIND in the base. Given that, we need to look at how best to handle the transition. This is essentially what I was trying to get at :-) The proposed solution of `dig` and `host` returning These tools can be installed through the bind-utils port, or you can use `drill` I think would be sufficient. Having them simply disappear would be terrible, but stubs would make this possibly the least painful thing. ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Sat, Jul 7, 2012 at 4:38 PM, Doug Barton do...@freebsd.org wrote: On 07/07/2012 16:33, Garrett Wollman wrote: On Sat, 07 Jul 2012 16:17:53 -0700, Doug Barton do...@freebsd.org said: BIND in the base today comes with a full-featured local resolver configuration, which I'm confident that Dag-Erling can do for unbound (and which I would be glad to assist with if needed). Other than that, what integration are you concerned about? The utilities (specifically host(1) and dig(1)) are the only user-visible interfaces I care about. I don't see any need for there to be an authoritative name server in the base system. So long as the resolver works properly and does DNSsec validation I addressed the utils in a previous message, but once more ... ldns (a dependency of unbound) comes with drill, which is a dig-alike tool. I'd like to see us produce a host-alike based on ldns as well, which should be a pretty simple junior hacker task for a motivated group. If those don't do it for you, ports/dns/bind-tools already exists. It would be silly not to keep bind-tools in base. `host` and `dig` are very standard tools most people expect to be available in base, just as they are in the base/core/whatever of other operating systems. I'm all for writing other tools based on ldns, but now you're talking about doing things that create extra work for me, the end user, for something that gives me very little gain (if any). I either have to install bind-tools or rewrite scripts. And what do I get? Nothing I really care about. Think about the benefit to the end user before making such decisions. Especially if you're talking about taking away something that is already there and taken for granted. ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Sun, Jul 8, 2012 at 2:39 PM, Doug Barton do...@freebsd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/08/2012 10:10, Jason Hellenthal wrote: From first impression it seems that drill(1) has a syntax that leaves something to be desired like the eased use of host or dig. So once again, if you need the exact capabilities of ISC host and dig, install them from the port. As bind-tools and BIND (the resolver) as separate, why not just leave bind-tools in base? They'll work happily with unbound. ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton do...@freebsd.org wrote: On 07/08/2012 22:43, Avleen Vig wrote: It would be silly not to keep bind-tools in base. Sounds easy, but not so much in practice. Keeping any of the code doesn't solve the problem of the release cycles not syncing up. And for the vast majority of users needs the tools we will import will be more than adequate. The question I keep asking myself is: Is this best for the users? I can't convince myself that it is, at the moment. While I completely agree with you reasons, and I do think that in an ideal way they'd be good, I'm just not sure they are the best thing to do for users. Linux has `nscd` which is a nice caching resolver, but most distributions still carry bind-tools in the default install. Enough people expect the tools to be there, that getting rid of them for almost any reason seems like a bad idea for low benefit. I could care less about the resolver daemon itself, I agree with what you're saying and I don't think most end users will care about that. But getting rid of dig and host in base would be bad. ___ 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: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Sun, Jul 8, 2012 at 11:26 PM, Doug Barton do...@freebsd.org wrote: On 07/08/2012 23:16, Avleen Vig wrote: On Sun, Jul 8, 2012 at 10:51 PM, Doug Barton do...@freebsd.org wrote: On 07/08/2012 22:43, Avleen Vig wrote: It would be silly not to keep bind-tools in base. Sounds easy, but not so much in practice. Keeping any of the code doesn't solve the problem of the release cycles not syncing up. And for the vast majority of users needs the tools we will import will be more than adequate. The question I keep asking myself is: Is this best for the users? Carrying BIND code in the base that is past EOL is not good for the users, period. Everything else we're discussing is an implementation detail. I think the everything else we're discussing is an implementation detail is the part we'll have a problem with. Although Garrett's reply to my email makes sense too. Linux has `nscd` which is a nice caching resolver, but most distributions still carry bind-tools in the default install. A) You're wrong about most. and B) The Linux distros have a default set of packages. There is no base like there is in FreeBSD. (Thus, your analogy is flawed.) That's not *really* true, there is a base like FreeBSD, but what we consider core userland tools like `ls`, come in a package (coreutils). That said, I still believe that our idea of what should, and should not be, in the base system is seriously flawed, and needs to be completely redone. But that's never going to happen, so I'm trying to work with what we've got. Agreed. The idea of a minimally functional system itself might be flawed. Do you consider having `dig` and `host` essential in a minimally functioning system? I do. It's pretty f'king hard to resolve problems with installing the bind-utils port, if you don't know how to test your DNS :-) The issue is also one of barrier-to-entry. By removing `dig` and `host`, I think we're making things unnecessarily more difficult for people who don't *know* FreeBSD. `dig` and `host` a universally standard tools for doing DNS lookups. Taking them away in base to replace them with something else just seems like something that won't really *help* users. Yes, I'm going to be a stickler and say that having EOL code in base isn't the end of the world. It's not ideal, but really.. what is it breaking? If there's a security vulnerability, sure, I understand that it might suck without support from ISC to patch dig/host/nslookup, but when was the last time that happened? ___ 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: Replacing BIND with unbound
On Jul 9, 2012 7:57 PM, Peter Jeremy pe...@rulingia.com wrote: On 2012-Jul-10 00:40:07 +0200, Dag-Erling Smørgrav d...@des.no wrote: They are sufficiently similar that writing a wrapper that supports a significant subset of dig's command-line option and uses drill as a backend shouldn't take more than an afternoon for a reasonably experienced programmer. I would further suggest that where a dig(1) option isn't emulated, the fallback error message should refer the user to drill(1). As for nslookup... it's been deprecated for a decade. But old fogies might still use it. Can I suggest that something along the lines of the the following be installed as /usr/bin/nslookup: #!/bin/sh echo nslookup is no longer supported. Please see drill(1) or host(1) 2 exit 1 This is a much better solution for users. ___ 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
Creating an LVM-backed FreeBSD DomU in a Linux Dom0
After searching high and low and not finding exactly what I wanted (although Adrian Chadd's documents came close), I decided to document a lengthy but worthwhile procedure: How to install a FreeBSD DomU guest in a Linux Dom0 Xen host, from scratch, with LVM-backed storage (rather than file based), and without the need to rely on random kernels and ISO[1] http://bit.ly/dVhfFe Hopefully people find it useful :-) I haven't yet broached configuring inside the Xen host. Again there is scattered documentation available. I'll try to bring it together next. [1] I gave serious thought to uploading my own stuff along with the other similar things available already, but in the end I thought it better if people try out how to do it, given that the amount of work will be almost the same, or even slightly less building it yourself. Plus there are the usual security and availability concerns.. :) -- Avleen Vig Systems Administrator Personal: www.silverwraith.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Creating an LVM-backed FreeBSD DomU in a Linux Dom0
On Tue, Dec 28, 2010 at 07:35:47PM +, Robert Watson wrote: After searching high and low and not finding exactly what I wanted (although Adrian Chadd's documents came close), I decided to document a lengthy but worthwhile procedure: How to install a FreeBSD DomU guest in a Linux Dom0 Xen host, from scratch, with LVM-backed storage (rather than file based), and without the need to rely on random kernels and ISO[1] http://bit.ly/dVhfFe Hopefully people find it useful :-) FYI, we now have a xen(4) man page, which will ship in 8.2. It's not tutorial material like your document, but is useful reference material. I'd like it very much if we could get something more along the lines of what you've created into the FreeBSD Handbook. I'd be happy to work on that. I've been meaning to get some things done on documentation for a while now. ___ 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: [RFT]: InFlight Mode Patch
On Mon, Jul 17, 2006 at 04:14:14PM +0930, Benjamin Close wrote: Which implements a boot menu item, sysctl tunable (hw.inflight_mode) and prevents all wireless bluetooth drivers from attaching (probe succeeds still). Attaching isn't the problem. The FAA and other international air authorities specifically disallow any transmitting of receiving. The only way you'll get this is by disabling the hardware itself. ___ 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
On Mon, Jul 03, 2006 at 08:42:42AM +0530, Joseph Koshy wrote: In the less benign one that convenient binary driver that you loaded into the kernel would contain a silent security vulnerability. Google for Sony DRM rootkit. I think the difference here is that NVIDIA are a little more trusted than Sony ever was :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A New FreeBSD Server
On Sat, Jun 24, 2006 at 03:32:26PM -0400, Mike Meyer wrote: Why not RAID your swap? The extra reliability might not be worth very much, but the extra performance couldn't hurt - unless you don't plan on swapping at all. This is enough of a win that the swap subsystem will interleave swap usage across multiple drives, a facility that predates RAID. If you just split your swap across multiple drives, you get RAID0 behavior from swap. Really? I thought it was possible to interleave multiple swap devices. I'm probably wrong, but I thought I remembered seeing 'interleaved' somewhere. Maybe my definition of interleaved is differented from someone elses :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Snapshot's causing access problems
Is anyone else experiencing this? I'm finding that during times when a snapshot is being created for a partition, all access of that partition hangs until the snapshot is completed. On a large partition (180Gb, 66% used), this takes over 10 minutes for me. I've found that any time the partition (which is NFS mounted) is being accessed when the snapshot creation starts, the creation seems to take an even longer amount of time and sometimes isn't complete after 30 mins when I reboot the box. The problem is also really bad when the background fsck is starting and makes a snapshot first, which takes a lot of production time out a server which just crashed that I'm trying to restore. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com Wickedness is a myth invented by good people to account for the curious attractiveness of others. - Oscar Wilde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Asymmetric ethernet throughput?
On Tue, May 30, 2006 at 04:42:12PM -0400, Mike Meyer wrote: Well, it makes the throughput closer to symmetric when I'm pushing traffic both ways - but at around 7MB/sec. If I only run traffic in one direction, I get the previous behavior. I might like to suggest that the problem is your RealTek NIC. Those NICs so utterly suck (I have 2, before anyone thinks I'm bashing without cause :). I'm speaking from an implementation point of view, read the various reports on the hoops drivers have to just through to send data. They're fine for light home use (and well priced for that). Never expect consistancy or line speed from them though. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
6.1 crash data (was: Re: no core file handler recognizes format)
On Mon, May 15, 2006 at 10:58:02AM -0700, Avleen Vig wrote:
On Sat, May 13, 2006 at 11:40:33AM +0400, Stanislav Sedov wrote:
Rebuild your kernel with INVARIANTS enabled and debug info. It will
provide more information in case the crash happens again.
Ok, I finally got a core file with the crash :-)
Where's what some of kgdb tells me.
All I can tell, is that the bug happened somewhere around trying to set
a TOS value for an outbound network packet?
Help please?
[EMAIL PROTECTED] ~ # kgdb -c /var/crash/vmcore.0 /usr/obj/usr/src/sys/GOOSEBERR
Y/kernel.debug
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Unde
fined 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
fault virtual address = 0x58
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc05efa9a
stack pointer = 0x28:0xd6cb7ae0
frame pointer = 0x28:0xd6cb7b10
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 = 20115 (python)
trap number = 12
panic: page fault
Uptime: 10d6h22m19s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335 319
303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc0553492 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2 0xc05537ac in panic (fmt=0xc071873f %s)
at /usr/src/sys/kern/kern_shutdown.c:558
#3 0xc06fc00c in trap_fatal (frame=0xd6cb7aa0, eva=0)
at /usr/src/sys/i386/i386/trap.c:836
#4 0xc06fbd17 in trap_pfault (frame=0xd6cb7aa0, usermode=0, eva=88)
at /usr/src/sys/i386/i386/trap.c:744
#5 0xc06fb94d in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 0, tf_esi = -691307388,
tf_ebp = -691307760, tf_isp = -691307828, tf_ebx = 0, tf_edx = -691307120,
tf_ecx = 0, tf_eax = 8, tf_trapno = 12, tf_err = 2, tf_eip = -1067517286, tf_cs
= 32, tf_eflags = 66183, tf_esp = -691307388, tf_ss = -691307784})
at /usr/src/sys/i386/i386/trap.c:434
#6 0xc06e994a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc05efa9a in ip_ctloutput (so=0x8, sopt=0xd6cb7c84)
at /usr/src/sys/netinet/ip_output.c:1210
at /usr/src/sys/netinet/ip_output.c:1210
#8 0xc0601ad1 in tcp_ctloutput (so=0xc57aede8, sopt=0xd6cb7c84)
at /usr/src/sys/netinet/tcp_usrreq.c:1038
#9 0xc05971a7 in sosetopt (so=0xc57aede8, sopt=0xd6cb7c84)
at /usr/src/sys/kern/uipc_socket.c:1560
#10 0xc059cec9 in kern_setsockopt (td=0xc4b03900, s=8, level=8, name=8,
val=0xbfbfab68, valseg=UIO_USERSPACE, valsize=0)
at /usr/src/sys/kern/uipc_syscalls.c:1351
#11 0xc059cdee in setsockopt (td=0x8, uap=0xd6cb7d90)
at /usr/src/sys/kern/uipc_syscalls.c:1307
#12 0xc06fc322 in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = -1077957792, tf_esi =
-1077957784, tf_ebp = -1077957768, tf_isp = -691307164, tf_ebx = 70802,
tf_edx = 170620760, tf_ecx = -1077958488, tf_eax = 105, tf_trapno = 22, tf_err
= 2, tf_eip = 673659967, tf_cs = 51, tf_eflags = 662, tf_esp = -1077957844,
tf_ss = 59})
at /usr/src/sys/i386/i386/trap.c:981
#13 0xc06e999f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#14 0x0033 in ?? ()
(kgdb) up 7
#7 0xc05efa9a in ip_ctloutput (so=0x8, sopt=0xd6cb7c84)
at /usr/src/sys/netinet/ip_output.c:1210
1210inp-inp_ip_tos = optval;
(kgdb) p optval
$1 = 8
(kgdb) p inp
$2 = (struct inpcb *) 0x0
(kgdb) p inp-inp_ip_tos
There is no member named inp_ip_tos.
(kgdb) p inp-inp_depend4.inp4_ip_tos
Cannot access memory at address 0x58
Here I went up one more, to #8:
(kgdb) up 1
#8 0xc0601ad1 in tcp_ctloutput (so=0xc57aede8, sopt=0xd6cb7c84)
at /usr/src/sys/netinet/tcp_usrreq.c:1038
1038error = ip_ctloutput(so, sopt);
(kgdb) p *so
$14 = {so_count = 1, so_type = 1, so_options = 4, so_linger = 0,
so_state = 8448, so_qstate = 0, so_pcb = 0x0, so_proto = 0xc076e588,
so_head = 0x0, so_incomp = {tqh_first = 0x0, tqh_last = 0x0}, so_comp = {
tqh_first = 0x0, tqh_last = 0x0}, so_list = {tqe_next = 0x0,
tqe_prev = 0xc3baa5b4}, so_qlen = 0, so_incqlen = 0, so_qlimit = 0,
so_timeo = 0, so_error = 54, so_sigio = 0x0
Re: no core file handler recognizes format
On Sat, May 13, 2006 at 11:40:33AM +0400, Stanislav Sedov wrote: Rebuild your kernel with INVARIANTS enabled and debug info. It will provide more information in case the crash happens again. With INVARIANTS compiled in, it doesn't leave me a core file when it crashes :-( Kernel config and list of modules posted here may be useful to some extent too. # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.429.2.3.2.1 2005/10/28 19:22:41 jhb Exp $ machine i386 cpu I686_CPU ident GOOSEBERRY # 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) debug symbols makeoptions MODULES_OVERRIDE=linux #optionsSCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] #optionsCOMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 #optionsSCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. options INVARIANTS options INVARIANT_SUPPORT device apic# I/O APIC # 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 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 #device ahd # AHA39320/29320 and onboard AIC79xx devices #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device
Re: FreeBSD 6.1 Released
On Thu, May 11, 2006 at 11:42:26PM -0400, Mike Jakubik wrote: The *entire* errata page was from 6.0; it was a mistake. This wasn't some put on the rose-colored classes and gloss over major issues thing. It was a long release cycle and something was forgotten. C'est la vie. It's always a good idea to check the most up-to-date version of the errata page on the web anyway, so it's *not* too late to update it. How convenient. These problems needed to be addressed in the release notes, not some on line version. If they're THAT big of a deal, learn some C, and fix the problems yourself, instead of sending e-mails that sound rude and ungrateful. And if you can't do that, how about helping scott put together release notes which you seemed to think were so awful? All I hear from you is complaining and a serious lack of anything constructive. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
no core file handler recognizes format
My 6.0 box[1], and now my 6.1 box[1] have been crashing almost daily, due to page faults. Last night I was lucky enough to see it happen on screen, where it reported a Page not present error. When I try to look at the code file in GDB, I get this error: warning: /usr/home/avleen/vmcore.0: no core file handler recognizes format, using default Can't fetch registers from this type of core file Can't fetch registers from this type of core file #0 0x in ?? () I did see a message from a few months ago which stated the userworld could be out of step with the kernel becaus the core file format changed at some point, but I've been building the kernel and world together for 6.0 and 6.1. Any suggestions befoer I downgrade to 5.4? -- Avleen Vig Systems Administrator Personal: www.silverwraith.com Wickedness is a myth invented by good people to account for the curious attractiveness of others. - Oscar Wilde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no core file handler recognizes format
On Sat, May 13, 2006 at 02:39:19AM +0400, Stanislav Sedov wrote:
You should use kgdb rather the gdb. GDB doesn't recognizes kernel
dumps format by default.
Ah thank you!
Here's the information I found.
Any help that anyone can provide will go into a nice little crash
debugging for beginners document which I've started working on :-)
Ok kgdb tells me:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x58
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc06005aa
stack pointer = 0x28:0xd6c13ad0
frame pointer = 0x28:0xd6c13b00
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 = 25911 (python)
trap number = 12
panic: page fault
Uptime: 14h49m8s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335 319
303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
The few lines before trap() was called look like this:
#5 0xc071a38d in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 0, tf_esi = 0, tf_ebp =
-691979520, tf_isp = -691979588, tf_ebx = -691979136, tf_edx = -691978864,
tf_ecx = 0, tf_eax = 8, tf_trapno = 12, tf_err = 2, tf_eip = -1067448918, tf_cs
= 32, tf_eflags = 66183, tf_esp = -691979136, tf_ss = -691979544})
at /usr/src/sys/i386/i386/trap.c:434
#6 0xc070814a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc06005aa in ip_ctloutput (so=0x8, sopt=0xd6c13c80)
at /usr/src/sys/netinet/ip_output.c:1210
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
On Thu, Apr 20, 2006 at 10:32:33PM -0500, Eric Anderson wrote: Other than that, do we have general consensus that these do what they claim? Any outstanding issues that haven't been addressed? One request: Please remove the two seperate rc.conf lines, and replace with just one: rc_fancy= YES | NO | COL[O|OU]R So that it works line the sendmail_enable option (YES/NO/NONE) Then include any other tunables in rc_fancy_flags ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel Quality?
On Thu, Apr 06, 2006 at 09:30:28AM -0700, Sam Leffler wrote: OTOH we've done nothing with user application code and based on the work I've seen done by netbsd there's plenty of stuff to be fixed there. So if you want to help out get an account and start feeding back fixes for the user code. How does one get an account ?? :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Microsoft Offfice on FreeBSD
On Sat, Jan 07, 2006 at 04:28:04AM -0500, Tom Wickline wrote: Hello, I thought you guys would get a kick out of seeing Word 2003 running on FreeBSD.. Here is the link: http://wiki.winehq.org/Office-BSD?action=show Thanks for putting me off my lunch. :P -- Avleen Vig Systems Administrator Personal: www.silverwraith.com Wickedness is a myth invented by good people to account for the curious attractiveness of others. - Oscar Wilde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote: 2. SMP kernels for install. Right now we only install a UP kernel, for performance reasons. We should be able to package both a UP and SMP kernel into the release bits, and have sysinstall install both. It should also select the correct one for the target system and make that the default on boot. If people are concerned about performance, I benchmarked a 6-beta kernel SMP versus UP on a socket 939 Opteron. If those results are accurate, there's no real reason not to just use an SMP kernel on default install? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forcing a packet through an interface (OT?)
On Mon, Jul 11, 2005 at 04:53:25PM -0300, Mario Lobo wrote: Forgive me if this is off-topic. How could I force a packet to go out through an interface, despite the default route? You have a couple of options. Look at CARP in 5.4, that might do what you want best. man 4 carp Also google for: ipfw policy routing that is slightly different, but if you are going tests to see when a link goes up and down, and can change your firewall rules based on that, that would work I think. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Long uptime 5.2.1 server
On Sat, Jun 18, 2005 at 02:35:20PM +0200, Dimitry Andric wrote: We've got a FreeBSD 5.2.1-RELEASE-p1 server that's been up for 460 days now, with pretty heavy use the whole time (70GB+ per day http traffic, 140 hits/sec, etc). Funny that some people insist on complaining about 5.x instability. :P There were always two things I would recommend waiting for before moving to 5.x: 1. Performance. I remember reading the after 5.0's release, much debugging code was still in the OS and kernel which would reduce performance. 2. Stability. After 5.0 came out, most production environments were advised not to upgrade or put 5.x out, as we know there were probably many obscure bugs still present and trying to be worked out. (2) was put to rest when -STABLE was branched, but I never heard that (1) was dealt with. I assume it was but it would be nice to be sure :-) -- Avleen Vig Systems Administrator Personal: www.silverwraith.com Screams are expressions of pure joy fulfillment when extracted in the proper manner. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE kernel build with icc broken
On Sun, Mar 27, 2005 at 01:30:59PM +0200, Alexander Leidinger wrote: It seems to me that building kernel with icc is currently broken, at least in 5-STABLE. Could somebody investigate this? I don't have a problem to compile it with a recent -current and a recent icc (-stable not tested), but the resulting kernel imediatly panics (page fault in _mtx_...()). Without intending to start any compiler holy wars, what benefits does ICC provide over GCC for the end user? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenBSD's netcat in base or ports?
On Tue, Jan 25, 2005 at 09:24:57PM +0800, Kang Liu wrote: Delphij, I think the base should be as *clean* as possible, it might be better if we put nc into ports. :P I agree. base should be minimal, everythign optional (eg 'perl' :P) should be in ports. There people can choose the versions (eg 5.6 or 5.8), where to install them, etc etc. ___ 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
On Mon, Jan 17, 2005 at 06:31:06PM -0800, Peter Kieser wrote: I have no problem with bringing up the discussion of process checkpointing on FreeBSD, what I _DO_ have a problem with is all this cruft about DF on the list all the time. We keep getting the, DragonFly does it this way or DragonFly has this and we don't on the freebsd-hackers mailing list, and I'm pretty sure I'm not the only one annoyed about it. Again, I have no problem with bringing up the process checkpointing, I have a problem with people saying DragonFly has this _all_ the time; if I wanted to hear about DF's development path I would be subscribed to their mailing lists. I don't see this on -hackers all the time. What I DO see is the occassional comment on how Net, Open and DF BSD's are doing things. Amongst those there are comments also about how Linux is doing things. And IMP, they should all be welcome here. I think you need to step back and take a look at how little DF is mentioned on -hackers, and also compare it to how much other OS's are. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: network trunkin
On Sun, Jan 09, 2005 at 02:48:18AM -0800, Matt wrote: Does anyone know if FreeBSD supports trunking? By that I mean spreading network traffic over multiple interfaces to achieve a higher aggregate I believe you can, with VLANs. Not sure about otherwise. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com Screams are expressions of pure joy fulfillment when extracted in the proper manner. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: network trunkin
I though there was a netgraph channel bonding node, but I can't remember it's name :( ng_fec(4) Is that a 5.x-ism? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcsh fix
On Thu, Nov 11, 2004 at 06:49:04PM -0600, Kevin Lyons wrote: I think the problem can still be fixed. Simply put in /bin/tcsh and let /bin/csh be what it actually is, which is to say /bin/csh. I realize that will add all of 300kB to the system. And there would also have to be an entry for tcsh in /etc/shells. Should I send a patch? Developers have a right to expect a certain basic level of functionality on a system. When he calls fopen() he should get fopen, when he calls /bin/bash he should get /bin/bash not zsh nor sh nor ksh. I have to agree with Kevin's sentiments on principle. 'csh' should run pure csh, not anything else. 'sh' should be pure sh, not what Linux does and bastardize it as /bin/bash If someon wants a more powerful shell, they can install it themselves. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcsh fix
On Fri, Nov 12, 2004 at 04:11:22AM +0100, Erik Trulsson wrote: Personally I am of the opinion that csh (all versions) should be removed completely from the base system and relegated entirely to the ports system. Other than historical reasons there is not much point in having it in the base system. I strongly disagree. csh and sh should be 'pure' versions. That is to say, no matter what shell is actually being called as sh or csh, it should provide a 100% compatible version, no differences, no upgrades. This is to provide compatibility whn working with multiple versions of Unix. I write many scripts in sh on Solaris, and find they just don't work on Linux because /bin/sh on Linux is really /bin/bash and is not bacwards compatible. I HATE this. We shouldn't do this, and should do anything like this. (Originally csh was created to get a shell with better interactive features the original Bourne shell and tcsh is much better for interactive use than 'classic' csh - indeed a modern /bin/sh is better than 'classic' csh. For writing scripts the Bourne-derivatives is much better than csh and it has long been strongly recommended that one should not write scripts for csh. One cannot even assume that all systems have csh installed - Posix doesn't require it but it does require /bin/sh to be present.) and /bin/sh should be classic /bin/sh not some version which is going to break my shit when I port it over! I'm so glad this is the case with FreeBSD :-) 'csh' does run pure csh, and nothing else. The latest version of csh which happens to be renamed to tcsh to be exact. That this latest version is not 100% compatible with earlier versions might be unfortunate but very few software packages never break backwards compatibility. How about when working with multiple versions of the same shell on different OS's? surely you can see the problem there. 'sh' should be pure sh, not what Linux does and bastardize it as /bin/bash There is no such thing as pure sh. It you believe otherwise please tell us what you think such a shell would look like and exactly what features should be in it. (Hint: Current standards require /bin/sh to have several features that were not available on early Unix versions.) Then we should follow current standards. Not pretend one shell is another! If someon wants a more powerful shell, they can install it themselves. Keep in mind that FreeBSD's /bin/sh is a more powerful shell than was available in, say, v7 Unix. Yes but AFAIK it's compatible in every way I've tried with say, Sun's /bin/sh, and I've tried some pretty complex shell scripts. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcsh fix
On Thu, Nov 11, 2004 at 07:30:14PM -0800, Bruce M Simpson wrote: Also keep in mind that ash is not POSIX sh (at least not as completely as one might like). This tends to bite me when using GNU autotools, which are hardcoded to prefer bash by default. True, but the problem there is people coding things to bash-specific routines, and then not bothering to test they work on anything but their own little boxes. Argh. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS
On Thu, Sep 16, 2004 at 04:50:15PM -0700, Frank Mayhar wrote: I think that the one thing we can say is that there's pretty much zero chance that we can predict what the future will bring, number of particles in the observable universe notwithstanding. Personally, I think that an apparently infinite address space is a _good_ thing. At least we won't run out soon, right? :-) IPv4, anyone? :-) You can *never* have enough numbers! -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On Fri, Sep 17, 2004 at 12:59:36AM +0100, [EMAIL PROTECTED] wrote: Inside the kernel? i can define a syscall accepting 30 args and it could send in panic freebsd kernel. I think it's a problem and a patch 'must' occur. You could also define a syscall with no arguments and have it call panic(9). So what? The difference is, that calling panic(9) is not a bug, it's a designed mechanism to panic a kernel. The behaviour reported is NOT designed behaviour (at least, no-one has said it is). Therefore, if the man wants to write a patch to fix unintended behaviour, what's wrong with that? -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Finding MTU
On Sun, Aug 29, 2004 at 07:55:27PM -0700, Dennis George wrote:
Hi all,
Can anybody tell me how to find the MTU (Maximum Transmitting Unit) in
freeBSD programatically...
Define programatically?
With syscalls, or in a way that is easily repeatable?
If you just mean the latter, this will do it:
ifconfig -a | awk '/mtu/ { print $1, $NF }'
Otherwise, try man networking and look for the word 'mtu', that might
be a good start.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Next Generation kernel configuration?
On Wed, Jul 21, 2004 at 02:52:07PM +0200, Devon H. O'Dell wrote: I wholly disagree. I think using an excuse ``people will let everything else do the work for them and nobody will ever learn'' to discourage the development of automation tools is very poor. Try applying that argument to any utility that you use. You'd have to write your own bloody operating system because ``learning's in your best interest''. I'm sure this will become another bikeshed, so I suggest whoever came up with the idea to put up or shut up. People are interested in solutions, not suggestions. You confuse automation, with simplification. Automation tools are good for frequently re-run tasks. How often do you recompile your kernel? exactly. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Next Generation kernel configuration?
On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote: Just musing on an idea here: I've been thinking for a while now about trying to write a tool to make kernel configuration easier, sort of a make config (as in ports) for the kernel, similar to what's available on some of the Linux distros. I've read over the other posts in this thread, but I cannot say I think this is a good idea. In fact, I think it's a very bad idea, but with very good intentions. Here's why.. I'm a strong proponent of user education. The FreeBSD handbook is one of the best education tools for someone who wants to use FreeBSD, right from beginner to more advanced levels. A config tool, while useful for beginners, would quickly result is those beginners not learning about building a kernel themselves, copying GENERIC to `hostname -s | tr [:lower:] [:upper:]`, editing it, learning what is in LINT, remembering to look through there, etc. This process teaches users a lot about how a BSD kernel is configured, what options are availible, and where to look for more options. The end result would be more people building kernels themselves, but not knowing what is actually happening, or what more is possible. It would mean less educated users, and I don't think that is somewhere any organization needs to go (look at what happened to the average Microsoft user's IQ level, after people stopped using DOS and started having machines do the work for them). Like I said, I think your intentions are good, but I have concerns about the suggested solution. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Article on Sun's DTrace
On Thu, Jul 08, 2004 at 03:46:24AM -0400, Daniel Ellard wrote: I don't doubt that DTrace took a long time to do. However, in most projects the design phase consumes a lot of time, and it is often the case that unforeseen problems or changes in the feature set cost the developers a lot of time. So while it might have taken six years to write DTrace the first time, I suspect it would take a fraction of that time to re-implement. (It certainly might be longer than a few months and I'm not going to quibble. We won't know the precise number until someone does the port.) They said 6 staff-years. This means if they have 6 people working on it full time, it took 1 year to complete. If they had 60 people full time, it took just over 5 weeks (technically, i doubt that would work practically). From speaking to a friend at sun, I do know it took a long time and a lot of effort, and was *not* a simple thing to implement. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Adding DMA support for a device
I have a DVD drive which is recognised by FreeBSD: acd0: DVD-R DVD-RW IDE1004 at ata1-slave PIO4 The drive supports DMA, and Windows sets it to use UDMA mode 5 (I think), but BSD does not. I am assume because the device is not listed as supported correct driver? I had a look in ata-dma.c but that file seems to be for controllers rather than devices. Can anyone point me in the right direction for this? -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: where to get info to write basic usb driver for own device?
On Sun, Jul 04, 2004 at 12:53:39PM +, [EMAIL PROTECTED] wrote: So what I guess what I am asking is how hard would this be? (I have a reasonable knowledge of C and Java and have been using FreeBSD for a couple of years but have never written a device driver (for any OS)) Do I actually need to write a driver or can I use something already existing? Where would I get information on how to do this? So far I've been looking at the existing drivers; ugen, ufm etc., the programmers handbook and am starting to look at libusb...? Sorry for the long message. Any pointers etc. would be greatly appreciated. I am actually in a similar situation. I know some C, and want to write a device driver for a USB device (web cam), but I have no idea where to start. I've searched for a beginners guide to writing device drivers but failed miserably :-( -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Standard sbc and pcm support in GENERIC kernel?
On Thu, Mar 04, 2004 at 06:26:47PM -0500, Dan Langille wrote: If they'd read pcm(4) they'd know how to get sound support up and running without recompiling their kernel. Is there something wrong with requiring that a new user bother to read the documentation? They would first have to know to read man pcm(4). All the have to do is look at the handbook. And if they can't find the link on the *front page* of freebsd.org, under the clearly labelled catagory of Support, then there is very little we can or should do to help them. After a point, enough is enough. If the user isn't prepared to educate themselves, your attempts will ultimately fail. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Standard sbc and pcm support in GENERIC kernel?
On Fri, Mar 05, 2004 at 09:58:52PM -0500, Dan Langille wrote: All the have to do is look at the handbook. And if they can't find the link on the *front page* of freebsd.org, under the clearly labelled catagory of Support, then there is very little we can or should do to help them. After a point, enough is enough. If the user isn't prepared to educate themselves, your attempts will ultimately fail. *That* explanation is vast difference to saying they have to read man pcm(4). The difference is sigficicant. Maybe if I say this here, having it in the archives will help *SOMEONE* at *SOME* point in the future :-) 95% of the questions I see asked about FreeBSD can be answered by reading the Handbook (http://freebsd.org/handbook/) Everyone newbie with a problem should first go there. Hell I'm not even a newbie (haven't been for almost 7 years) but I still go there. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Sun, Jan 11, 2004 at 09:24:38PM +0100, Nicolas Rachinsky wrote: Now, who wants to give this a try? OK, I tried now the following: I made copies of the 4.9 RELEASE Floppies, split the half of the kernel and mfsroot to another floppy and added two appropriate splitfiles. Afterwards booting from these four disks worked fine. OK, someone help me out here :) I was going to try this with a range of floppies (4.8, 4.9, 5.1, 5.2, etc), but I can't figure out what to do with splitfs.c gcc -o splitfs /usr/src/lib/libstand/splitfs.c /usr/lib/crt1.o: In function `_start': /usr/lib/crt1.o(.text+0x85): undefined reference to `main' /tmp/cc1Xbt2V.o: In function `splitfs_open': /tmp/cc1Xbt2V.o(.text+0x239): undefined reference to `fgetstr' /tmp/cc1Xbt2V.o: In function `splitfs_seek': /tmp/cc1Xbt2V.o(.text+0x695): undefined reference to `panic' /tmp/cc1Xbt2V.o(.text+0x801): undefined reference to `panic' /tmp/cc1Xbt2V.o(.data+0x10): undefined reference to `null_write' /tmp/cc1Xbt2V.o(.data+0x1c): undefined reference to `null_readdir' I'm guessing that's not the right thing to do. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 10:57:56PM +0100, Martin Nilsson wrote: This discussion is just like when the i386 support was removed from the GENERIC kernel, a lot of noise about old systems that wouldn't be able to run (or benefit) from FreeBSD 5 anyway. No, this is nothing like that. And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. I fail to see the difference in required labour between creating two floppies or a CD-R/RW disc. Most new machines ship with CD-RW drives today, the only boxes that can't boot from a CD are early Pentium1 class and frankly why run 5.x or 6.x on those? Incorrect. I and others have already given several examples of how modern machines cannot boot from CD for all the various reasons given. If the freebsd hosting mirrors don't mind us NFS mounting their servers to get the boot image, etherboot would be by far the simplest solution to maintain in the long run - then we can go with Scott's approach of getting rid of the current floppies, and adding in the other suggested approach of downloading the boot img from a remote server and running it. (I believe etherboot can be used like this, please someone correct me if i'm wrong). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 02:08:08PM -0800, Julian Elischer wrote: PXE boot against an automated backup/restore service would be much more useful for this. Assuming they have PXE and a supported card.. One point that hasn't been made here against PXE (well, not against it, but not in favour it): What if you dont' have another server to PXE boot from? What if it's the only PC in your house? PXE booting might be fine for a multi-server network, but when it's the only machine you have at home and you don't have a CD burner, you'd be screwed :) If the etherboot code can be made to use FTP, that would be good. Otherwise, can we have the mirror servers allow tftp? That would fix this quite easily. I might be willing to find hosting for a boot image provided it is small, as scott suggested it might be (3mb?) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 12:35:01AM -0700, Scott Long wrote: So, this is something to consider before 5.3. After that, we are stuck with the consequences of whatever we choose (or don't choose) for the entire 5.x lifespan. I do not cherish the thought of fighting floppies for another 2-3 years. I'm happy to work with someone who steps forward and is committed to maintaining the floppies as they are today. Otherwise, we need to seriously consider the alternative. Scott, While it is indeed true that most machines since 1997 will support this CD format, please take in to account: There are lots of machines with no CD drives: Slimline machines a la dell/compaq/hp/gateway Many corporate workstations Laptops Machines older than 1997 (this is mostly anything early PII chips and older, of which there are still a lot). Freebsd does work great on old hardware :) I'm sure there are others I can't think of at almost midnight.. :) I understand it is difficult to maintain the floppies. I wish I understood them better :-) Is it not possible to have ftp install floppies, which do nothing more than simple FTP installations? -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 03:43:55AM -0700, Scott Long wrote: Well, regardless of how you label it, these floppies still require lots of care and feeding in order to work. We currently have no way to support multiple floppies in a convenient way. This can be fixed in a variety of ways that range from fragile hacks to wonderful designs, but it still requires someone to put forth the effort. My offer for a 'floppy maintainer' is quite sincere; I hope that someone takes an interest and steps up to the challenge. The other big problem with removing floppies, is that not everyone has a cd burner. I wouldn't even say the majority of FreeBSD users have CD burners. I think someone mentioned this. I would love to be the 'floppy maintainer', but I know very little about the actual process and sadly don't have the time either :( -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 09:39:34AM -0500, Leo Bicknell wrote: It would require a whole new floppy booter setup, but I can see other OS projects using something like this as well, so perhaps some cross work with NetBSD or OpenBSD, or even the Linux camp could make an open source load an image floppy, that since it just loaded an ISO could load about anything. If I understand you right.. A floppy boot, which loads the absolutely basic stuff (network drivers, and some easy way to config the network) and then goes and grabs the installer would otherwise be on the current floppies and boots it? This sounds like a good solution - they we wouldn't have to worry about: If people have cd burners or not The size of the installer (for most practical purposes as long as the installer itself doesn't hit 600Mb :P) Compatibility with CD drives ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 01:22:38PM +0100, Martin Nilsson wrote: Are you aware that the FreeBSD CD:s (both 4.9 5.2) are not bootable on a CD-ROM connected via USB? Both try to boot but hangs somewhere in the loader. This is on our P4 Supermicro serverboards. As usual Win2K, 2K3 RedHat just works. An external USB2.0 connected Asus CD-RW drive (52x/24x/52x) with power supply costs about $70 so this is really nothing expensive or fancy today. Please do not assume that because it costs $70 it is universally availible. There are a lot of people who cannot afford this: the unemployed school children retired persons (sometimes) people with families to support :) Unfortuantely I feel this does need to be taken in to account here. While I totally empathise with Scott's problem and the lack of time to do things the way we have been, we need to appreciate that telling everyone to burn a CD to install FreeBSD (thus incur costs if you don't have a CD burner, and wouldn't need one if not to install FreeBSD) is not far from the You must pay us to buy this on CD approach (openbsd) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 05:56:22PM +0200, Narvi wrote: And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. Which would obviously mean that there would be lots of volunteers for the position of floppy maintainer? How you made the jump from I don't want to buy a CD burner to install FreeBSD to I will be a floppy maintainer I'm not sure. :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 02:04:34PM +1030, Daniel O'Connor wrote: *How* does it support all of those sources? CD/DVD drives need drivers (ATA optimisticly, but quite possibly SCSI), FTP/NFS need network card support, NFS needs nfsclient.ko ie this is the exact problem it has now :) You could save a little space with your idea because you wouldn't need sysinstall which is admittedly quite large, but it wouldn't address the fundamental issue. If you want floppy installs you need a way of putting arbitary drivers onto floppy disks easily so users can grab what they need and use it instead of having to second guess what sort of hardware they are likely to be using. IMHO of course 8-) Now you've got me thinking. A simple website which lets you choose what drivers you want (anyone seen the .muttrc config page? :) That should be really easy to do with a little perl CGI. I might take a crack at this in the next week or so. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 03:28:11PM +1030, Daniel O'Connor wrote: On Friday 09 January 2004 15:00, Avleen Vig wrote: onto floppy disks easily so users can grab what they need and use it instead of having to second guess what sort of hardware they are likely to be using. IMHO of course 8-) Now you've got me thinking. A simple website which lets you choose what drivers you want (anyone seen the .muttrc config page? :) That should be really easy to do with a little perl CGI. I might take a crack at this in the next week or so. Yep, I suspect mtools is the easiest way to do this.. Something that was suggested in #FreeBSDHelp on EFnet just now: sysinstall already has the ability to dynamically load modules. If this is the case, I don't see where the problem is. Make the kernel on the floppy disk have few/no drivers built in, and have then all loaded from a third disk. Have the third disk generated dynamically from say, a website? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Mon, Jan 05, 2004 at 01:52:50PM -0700, Brett Glass wrote: FreeBSD also keeps falling farther and farther behind Linux in the area of advocacy (and, hence, corporate adoption). Again, this is a governance issue. Many of the developers actually have an antipathy toward advocacy, since they dislike answering newbie FAQs and don't want too many people to adopt the OS for fear that it'll overcrowd their sandbox. So, some of the criticism is actually valid. Advocacy is NOT a race or a popularity contest. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Device polling, with SMP?
Has anyone here used DEVICE_POLLING on an SMP box? I have one server which does recieve ~130kpps at times on an interface, but I cannot enable DEVICE_POLLING because hte system locks up under load from interrupts. In this case I'm not sure which is better, disabling one of the CPU's, or trying to make DECIVE_POLLING work with SMP. I read Luigi's paper at info.iet.unipi.it/~luigi/polling/ which at the end implies that DEVICE_POLLING on an SMP box might not make sense - but right now for me it would make sense as both CPU's are locked: One tries to handle interrupts The other tries to manage the application I could try forcing DEVICE_POLLING to compile as is suggested in that URL but I wanted to see if anyone had tried this before. The interface is an FXP. Thanks :) -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Device polling, with SMP?
On Thu, Nov 20, 2003 at 12:58:58PM -0500, Don Bowman wrote: I read Luigi's paper at info.iet.unipi.it/~luigi/polling/ which at the end implies that DEVICE_POLLING on an SMP box might not make sense - but right now for me it would make sense as both CPU's are locked: One tries to handle interrupts The other tries to manage the application I could try forcing DEVICE_POLLING to compile as is suggested in that URL but I wanted to see if anyone had tried this before. The interface is an FXP. We use it on em. I just commented out the #error line that says you can't do it. device polling in idle doesn't work, and the user/system time calculation isn't correct, but it works well otherwise. This is pretty much what I wanted to confirm thanks! In which way is the system/user time incorrect? Always, or only under high load? what about it is incorrect? My skills are limited but I might take a stab at fixing that. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] 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
On Tue, Oct 21, 2003 at 09:30:38AM -0700, Kris Kennaway wrote: 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. Why the wheel group? Until now, the only special privilege this group has is that users are allowed to su to root, if they knew the password. It looks like now you've removed the root password barrier and allow anyone in the wheel group to manipulate processes to obtain root without a password :-) If you don't want them getting root, don't put them in wheel? ;-) ducks -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hyperthreading slowdown
On Sat, Oct 04, 2003 at 05:54:45PM -0400, Richard Coleman wrote: hyperthreading kernel, make -j 1 --- 1:09 hyperthreading kernel, make -j 2 --- 0:42 singlethreading kernel, make -j 1 --- 0:45 singlethreading kernel, make -j 2 --- 0:41 [snip] Yes, that's because (as discussed in the archives) the kernel treats it like an extra, completely decoupled physical CPU and schedules processes on it without further consideration. This is presumably the cause of the slowdown, because it's only efficient to use the virtual CPU under certain workload patterns. HTT is not magic performance beans. Sigh. No one is claiming HTT is magic performance beans. The 50% slowdown I'm talking about is between -j1 and -j2 BOTH ARE WHICH ARE USING HTT. It's just an interesting observation. That's all. Yeah, that's precisely what Kris said :-) When you have one processes hitting either one of two CPU's, that one CPU is going to get used to the fullest. When you are splitting the processes over two CPU's extra time needs to be taken for the extra scheduling and other extra work. The increase here is significant, but not unexpected :-) Now, if you had two seperate processes fighting for CPU time, you'd see a performance increase: Try running 'make -j 1' twice, on two different kernel configs files who's contents are the same. First try it without hyperthreading and then try it with hyperthreading. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for detailed documentation: Install to existingfilesystem
On Sun, Aug 24, 2003 at 03:36:41PM -0500, Charles Howse wrote: Hi, I've posted this request to 'questions' with no response, so now I'll ask 'hackers'. I'm a hobbyist, and for my personal education, I would like to learn how to install FBSD from an existing filesystem, rather than from FTP or CD. My intention is to copy the files to a directory on the second HDD of my present FBSD system, and point sysinstall to that partition/directory during the install. This may not answer the questions you posed, but it may be a good start for you. You have two options i can think of, if you want to mimic a traditional /stand/sysinstall installation process. 1) install an FTP server, and choose an FTP install. 2) export the hard drive over NFS, and use that. Or, a better way which I would recommend: download the source code, and put if on the second drive. We'll assume /usr/src and /usr/obj are mounted on the *second* hard drive. Run something like this: cd /usr/src make buildworld a flag* * the 'a flag' is a flag I don't recall off the top of my head, but * it lets you change which drive / other mounted location, the new * build is installed to. Maybe someone else can help here? make buildkernel then when you want to install to a third hard drive, mount it as the location give in 'a flag' to make on the previous step, then run: make make installkernel make installworld mergemaster that should isntall the compiled sources to the new drive pretty quickly. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent mplayer port spinning?
On Sat, Jul 26, 2003 at 10:23:07AM +0300, Danny Braniss wrote: the problem exits in 4.8-stable too. Are you using any extra CFLAGS? IIRC, using either -ffast-math or -funroll-loops causing things to break. I can't remeber which, or if it's always true, but try disabling any optimizations you might have used one at a time and try again. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.8 panic ffs_clusteralloc: map mismatch
I have been experiencing several ffs_clusteralloc: map mismatch kernel panics (always while heavy r/w activity on ad0). PC in question has SuperMicro P3TDL3 motherboard, 2 ide + 1 scsi HDD and 4 nics (full dmesg kernel config attached). Andrew, I spend about two to three years fighting with a system trying to figure out what was wrong, and why these errors were caused. I got the very same crashes you're seeing now. I'm sure others are too, and I think this reply would be useful for the archives. My Solution: I eventually realised that my problem was with one of three things: 1) bit flips in main memory 2) bit flips in cache 3) bad hard drive I replaced all of the memory after a few months. The problems stopped for a few weeks but quickly returned. So I don't think it was main memory, unless the new set or the sockets were damaged. I couldn't replace the cache because I couldn't find any more. The system was an old P1 (originally 75Mhz). This could have been the problem. I did once try turning off L2 cache in the BIOS, and I think the crashes *might* have continued. So it's possible the problems were here. Finally I didn't replace the hard drive, but I did find that moving load off the original drive to a second drive helpped reduce the number of crashes, although they still continued to happen. HTH. -- Avleen Vig Say no to cheese-eating surrender-monkeys Systems AdminFast, Good, Cheap. Pick any two. www.silverwraith.com Move BSD. For great justice! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: replacing sendmail with qmail
On Thu, Jun 26, 2003 at 03:18:04PM -0400, Lanny Baron wrote: It ends up as a religious war. There is no perfection in this world. Perhaps the next world. We use Qmail. But we use it because of vpopmail and our free email service at cybertouch.org. We used to use Sendmaail. It was great but at the time we could not find a solution to not having system accounts. Check out the Virtual Exim package at http://silverwraith.com/vexim It does the same at vpopmail but for Exim - sorry, not sendmail yet, but if you can make Sendmail lookup data in a MySQL database, this will work for you. I know it's very close to, if not exceeding the functionality / usability of vpopmail, because I used to use Qmail+vpopmail. Then I migrated the Exim and started the vexim project. It's still small with only one other developer, but very stable. Testers and more developers always welcome! I use it for all my production mail right now. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
make world + kernel with gcc 3.2?
Well, I installed 4.7-RELEASE a few months ago, and soon after installed GCC3.2. Since then, everything has worked fine, but I want to upgrade to -STABLE or at least 4.8-RELEASE when it comes out. I don't expect HUGE problems with making world, but am I asking for trouble if I make a new kernel with GCC3.2? I've tried searching archives but can only find old, vague references. Hopefully someone here has experience. -- Avleen Vig Say no to cheese-eating surrender-monkeys Systems AdminFast, Good, Cheap. Pick any two. www.silverwraith.com Move BSD. For great justice! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Panic: ffs_clusteralloc: map mismatch (fwd)
I sent this to freebsd-questions a few minutes ago.. if anyone here can
help too I'd really be indebted :-)
-- Forwarded message --
From: Avleen Vig [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Mon, 4 Nov 2002 09:56:36 + (GMT)
Subject: Panic: ffs_clusteralloc: map mismatch
Maybe a question for freebsd-hackers.. not sure..
FreeBSD 4.4, P166, 128Mb, 3 HD's: ad0, ad1, ad4, as ata0-master,
ata1-master and ata2-master. ata2-master is a Promise ata 100 controller
(tx2 I think).
For several months my server has been panicing, and I'm starting to think
it's a bad harddrive. I don't believe it's bad code (although I guess it
could be). I really need help in finding the drive responsible so that I
can replace it, but my debugging skills are limited to what I've learnt
from the OnLamp kernel debugging lesson :-)
I'd really appreciate it if someone could look over the crash dump output
below and let me know how I might be able to find out what write was
attempted when the server paniced. I have the last 4 crash dumps saved so
I can go back and look for matches in consistancy too. Also running a
debugging kernel but the code was last CVSUp'd about 8 months ago.
If it is a bad drive, I plan to replace it with 4.7-RELEASE.
#0 dumpsys () at ../../kern/kern_shutdown.c:473
#1 0xc0142f17 in boot (howto=256) at ../../kern/kern_shutdown.c:313
#2 0xc01432fd in panic (fmt=0xc0210e20 ffs_clusteralloc: map mismatch)
at ../../kern/kern_shutdown.c:581
#3 0xc019ddd1 in ffs_clusteralloc (ip=0xc198c800, cg=1, bpref=0, len=13)
at ../../ufs/ffs/ffs_alloc.c:1190
#4 0xc019d1b2 in ffs_hashalloc (ip=0xc198c800, cg=0, pref=8, size=13,
allocator=0xc019dba8 ffs_clusteralloc) at
../../ufs/ffs/ffs_alloc.c:778
#5 0xc019cbd7 in ffs_reallocblks (ap=0xc9de2dc4) at
../../ufs/ffs/ffs_alloc.c:442
#6 0xc016d096 in cluster_write (bp=0xc3ccd5d8, filesize=106496,
seqcount=14)
at vnode_if.h:1077
#7 0xc01a899e in ffs_write (ap=0xc9de2e68) at
../../ufs/ufs/ufs_readwrite.c:535
#8 0xc0177b46 in vn_write (fp=0xc15ba880, uio=0xc9de2ed8,
cred=0xc1ac7700, flags=0,
p=0xc9856d00) at vnode_if.h:363
#9 0xc01518e5 in dofilewrite (p=0xc9856d00, fp=0xc15ba880, fd=3,
buf=0x8161000,
nbyte=8192, offset=-1, flags=0) at ../../sys/file.h:162
#10 0xc015179e in write (p=0xc9856d00, uap=0xc9de2f80) at
../../kern/sys_generic.c:329
#11 0xc01f07e1 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 135663616, tf_esi = 672134208, tf_ebp = -1077945820, tf_isp
= -908185644,
tf_ebx = 672060612, tf_edx = 672134208, tf_ecx = 0, tf_eax = 4,
tf_trapno = 0,
tf_err = 2, tf_eip = 672014432, tf_cs = 31, tf_eflags = 659, tf_esp
= -1077945864,
tf_ss = 47}) at ../../i386/i386/trap.c:1155
#12 0xc01e41c5 in Xint0x80_syscall ()
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
