Re: A quick VM question
:What are the backing objects of the stack and heap area of a process's :address space? When are they created? I saw the code vm_map_insert(), but :the object argument given is NULL. : :Thanks, : :-Zhihui The backing objects are OBJT_DEFAULT objects. They are typically created when the system first needs to retrieve the map entry's object or needs to clip the map entry (for example, when extending the stack or [s]brk()ing), so as to reduce the number of actual VM objects created and to share the same VM object (with different offsets) whenever possible. If you look in vm/vm_map.c that is what all those NULL tests and calls to vm_object_allocate(OBJT_DEFAULT, ...) do. An OBJT_DEFAULT object is effectively a swap-backed object, just one that does not yet have any swap associated with it. If/When the system decides it needs to swap it will convert OBJT_DEFAULT objects for the memory in question to OBJT_SWAP objects. The two are really almost the same type of VM object. The type distinction is simply used to optimize performance. The main VM object types are: OBJT_PHYS physically-backed, never swapped out. OBJT_DEFAULTswap-backed with no swap yet assigned OBJT_SWAP swap-backed OBJT_VNODE vnode (e.g. file) backed object -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New feutures...........
On Fri, 14 Dec 2001 23:03:49 +0800 "Rafter Man" <[EMAIL PROTECTED]> wrote: > 2. I hope that in the furture the FreeBSD developers will rewrite the system in C++. As the BeOS developers used to say: NO C++ in the kernel. Follow that simple rule and you'll be safe :-) -- Miguel Mendez - [EMAIL PROTECTED] EnergyHQ :: http://energyhq.homeip.net FreeBSD - The power to serve! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Enhancing the CS461x audio driver...
Hi there hackers, I have a Terratec card based on the CS461x chip that comes with an S/PDIF optical output which I'd like to use. This feature is available under Windows but not under FreeBSD. I've downloaded some docs from the Crystal Semiconductor site but need some help as of where to start from. My idea is to add an ioctcl call to enable/disable the digital output, but I have no previous experience with driver hacking. Is this feature already in the TODO list of the driver already or has someone else started working on this? Yours, -- Miguel Mendez - [EMAIL PROTECTED] EnergyHQ :: http://energyhq.homeip.net FreeBSD - The power to serve! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deadlock with softupdates ?
On Mon, Dec 17, 2001 at 01:41:28PM -0800, Matthew Dillon wrote: > If it is a vnode deadlock you have to find which process or > processes it is deadlocking against. > > Do a ps -axl -M vmcore.X -N kernel.X on the kernel core, > pick out all the processes blocked on inode or whatever, > then from gdb go to each process (proc N) and do a backtrace > (back). I've a similar problem with -current from recent (within the last week or two). genius# ps -axl -M vmcore.15 -N kernel.15 (attached file) The back traces for the processes locked in inode is also attached. Being green to debugging this kind of thing what should I do next? Joe UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 274 1 0 8 0 8400 wait D+ #C:- 0:00.01 (sh) 88 317 274 0 96 0 260640 select D+ #C:- 0:00.37 (mysqld) 0 328 1 0 5 0 10800 ttyin Ds+ #C:0:00.00 (getty) 0 329 1 0 5 0 10800 ttyin Ds+ #C:0:00.00 (getty) 0 330 1 0 5 0 10800 ttyin Ds+ #C:0:00.00 (getty) 0 331 1 0 5 0 10800 ttyin Ds+ #C:0:00.00 (getty) 0 332 1 0 5 0 10800 ttyin Ds+ #C:0:00.00 (getty) 0 334 1 0 5 0 10800 ttyin Ds+ #C:0:00.00 (getty) 0 333 1 0 5 0 10800 ttyin Ds+ #C:0:00.00 (getty) 0 335 1 0 5 0 10800 ttyin Ds+ #C:0:00.00 (getty) 100 4345 4344 0 96 0 227720 select Ds+ #C:0:05.88 (slrn) 100 1618 1617 0 -12 0 34520 inode Ds+ #C:0:01.90 (mutt) 0 0 0 0 -16 0 00 sched DLs ??0:00.11 (swapper) 0 1 0 0 8 0 6640 wait DLs ??0:00.01 (init) 0 2 0 0 -16 0 00 psleep DL??0:00.04 (pagedaemon 0 3 0 0 20 0 00 psleep DL??0:00.00 (vmdaemon) 0 4 0 0 20 0 00 pgzero DL??0:00.00 (pagezero) 0 5 0 0 -16 0 00 psleep DL??0:00.18 (bufdaemon) 0 6 0 0 20 0 00 syncer DL??0:06.43 (syncer) 010 0 16 -16 0 00 - RL?? 659:48.43 (idle) 011 0 0 -44 0 00 - WL??0:01.34 (swi1: net) 012 0 0 -48 0 00 - WL?? 37:12.86 (swi6: tty: 013 0 0 -32 0 00 - WL??0:00.00 (swi4: vm) 014 0 0 76 0 00 sleep DL??0:01.55 (random) 015 0 0 0 0 00 - WL??0:09.37 (swi5: task 016 0 0 -40 0 00 - WL??0:00.00 (swi2: camn 017 0 0 -36 0 00 - WL??0:00.00 (swi3: camb 018 0 0 -21 0 00 - WL??0:00.00 (irq13:) 019 0 0 -21 0 00 - WL??0:03.93 (irq9:) 020 0 0 -80 0 00 - WL??0:00.00 (irq11: pci 021 0 0 -64 0 00 - WL??0:19.25 (irq14: ata 022 0 0 -64 0 00 - WL??0:00.00 (irq15: ata 023 0 0 -64 0 00 - WL??0:01.20 (irq5: uhci 024 0 0 -60 0 00 - RL??0:00.23 (irq1: atkb 025 0 0 -60 0 00 - WL??0:00.05 (irq12: psm 026 0 0 -64 0 00 - WL??0:00.00 (irq6: fdc0 027 0 0 -48 0 00 - WL??0:00.00 (swi0: tty: 028 0 0 -60 0 00 - WL??0:00.00 (irq4: sio0 029 0 0 -60 0 00 - WL??0:00.00 (irq7: ppc0 030 0 0 -84 0 00 - WL??0:00.00 (irq0: clk) 031 0 0 -84 0 00 - WL??0:00.00 (irq8: rtc) 0 150 1 0 -12 0 10840 inode Ds??0:00.36 (syslogd) 0 156 1 0 -12 0 14320 inode Ds??0:00.81 (ntpd) 0 162 1 0 96 0 12080 select Ds??0:00.02 (inetd) 0 164 1 0 -12 0 11240 inode Ds??0:00.07 (cron) 0 167 1 0 96 0 10920 select Ds??0:00.01 (lpd) 0 169 1 0 96 0 23800 select Ds??0:00.05 (sshd) 0 171 0 0 8 0 00 usbevt DL??0:00.37 (usb0) 0 172 1 0 96 0 10400 select Ds??0:00.06 (usbd) 0 229 1 0 96 0 10360 select Ds??0:15.30 (moused) 0 259 1 0 96 0 22360 select Ds??0:00.94 (httpd) 65534 265 259 0 4 0 22600 accept D ??0:00.00 (httpd) 65534 266 259 0 4 0 22600 accept D ??0:00.00 (httpd) 65534 267 259 0 4 0 22600 accept D ??0:00.00 (httpd) 65534 268 259 0 4 0 22600 accept D ??0:00.00 (h
Re: Enhancing the CS461x audio driver...
> I have a Terratec card based on the CS461x chip that comes with an S/PDIF > optical output which I'd like to use. This feature is available under Windows > but not under FreeBSD. I've downloaded some docs from the Crystal > Semiconductor site but need some help as of where to start from. My idea is > to add an ioctcl call to enable/disable the digital output, but I have no > previous experience with driver hacking. Is this feature already in the TODO > list of the driver already or has someone else started working on this? if you have docs that actually specify how to control the spdif output, send them to me and i'll include it in a future driver version. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Found NFS data corruption bug... (was Re: NFS: How to make FreeBSD fall on its face in one easy step )
On Thu, Dec 13, 2001 at 04:39:58AM -0500, Brandon D. Valentine wrote: > On Wed, 12 Dec 2001, Matthew Dillon wrote: > > >All I can say is... holy shit! > > Dude, you kick ass. At work I've been dealing with Linux's crappy NFS > implementation for years, while FreeBSD has always been pretty damn good > by comparison. Linux finally got a decent amount of performance under > 2.4 (which finally does NFSv3 to hosts other than other Linux boxen), > but it still can't touch the FreeBSD NFS implementation. The more > robust you make it the easier it is for me to argue for deployment of > more FreeBSD systems in NFS server roles. The only advantage Linux has > got right now is XFS, which is admittedly a pretty large advantage on > multi terabyte filesystems where fsck is impossible. I'm guessing that the real requirment here is is "when the system is turned on after an unclean shutdown (eg, power failure), it should be able to export it's NFS filesystems quickly". I suspect that the background fsck[1] that's available in FreeBSD-current fits the bill just as well as JFS or XFS - and I'll also bet that it'll be available in a FreeBSD-release before I'd trust data to a port of JFS or XFS. [1] If you've missed it, the basic idea is: for $fs in $all_filesystems ; do if is_a_softupdate_filesystem($fs) ; then fsck $fs & else fsck $fs fi done except it happens in fsck itself, rather than a shell script. -- Mike Bristow, embonpointful, but not managerial, damnit. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deadlock with softupdates ?
We saw something very similar to this about a year using FFS and soft updates when we were building a NAS appliance. The details escape me and I no longer work the company so I cannot grep the source code but here's what I remember. The softupdate code periodically flushes the meta data. There is a flag in the soft update code that periodically sets a flag to starts the meta data flush timer. There was a condition in which this flag was not set properly causing FFS to freeze, in particular with NFS running. Hope this helps. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
tx driver
Hi all! I've encountered really awful behavior of my SMC card using tx driver in FreeBSD 4.3. On 100 Mbps network I get the throughput just about 200 kBps :-( Colleagues of mine running some PC based routers have very similar experiences with this driver (in both 4.3 and 4.4 Rel's) The same card running under the exactely same conditions in NetBSD is working pretty good (11 MBps) and in Windows 2000 (8 MBps). Also running other cards (like those with rl drivers) on the same network gives very reasonable results in FreeBSD (approx. 10.5 MBps) so I'm pretty convinced driver is to blame. Does anybody have some workaround for this? (If there is a need for me to send better diagnostics than it's no problem.) Best regards, Petr Holub Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 2 Institute of Compt. Science 10200 Praha, CZ Masaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-5-41512278 e-mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
firewire driver
Hi all!
I'm struggling my FireWire OHCI based card in my notebook.
I'm using driver from DVTS project (that's what I finally
want to have up and running). I'm running FreeBSD 4.4 Release.
dmesg of my machine is in the attachement (using boot -v).
I've already added proper id for my card in both files
required (0x8027).
The problem is when booting I get "could not map memory" error
in this part of code:
---
fwohci.c:
#define DEF_CACHE_LINE 0x10
cache_line = DEF_CACHE_LINE;
pci_write_config(dev, PCIR_CACHELNSZ, cache_line, 1);
/**/
fun = pci_read_config(dev, 0xf0, 4);
fun |= 7;
pci_write_config(dev, 0xf0, fun, 4);
/**/
rid = PCI_MAP_REG_START;
sc->fc.mem = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid,
0, ~0, 1, RF_ACTIVE);
if (!sc->fc.mem) {
device_printf(dev, "could not map memory\n");
error = ENXIO;
goto fail;
}
sc->base = rman_get_virtual(sc->fc.mem);
#endif /* __FreeBSD__ */
ifp->if_flags &= ~IFF_UP;
/* Stop all DMA operation db.immediately */
fwohci_stop_dma(sc, -1);
---
I tried to use
#define PCI_ENABLE_IO_MODES
in pci/pci.c but got no difference. I've noticed there is
a option PCI_ENABLE_IO_MODES in -CURRENT kernel, but I'm
not able to use it since this machine is a production one.
I think this option can help somehow - at least it seems so
from the description of this option in LINT. But I haven't
seen it in 4-STABLE.
What I'm suspicious about is this part of dmesg:
found-> vendor=0x104c, dev=0x8027, revid=0x00
class=0c-00-10, hdrtype=0x00, mfdev=1
subordinatebus=0secondarybus=0
cmdreg=0x0006, statreg=0x0210, cachelnsz=8 (dwords)
lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns)
intpin=a, irq=11
which seems to me like BIOS forgot to allocate some memory for
this card.
Just to mention: card itself is OK since it's working on the same machine
in Windows 2000 (e.g. in Adobe Premiere 6.0). But it's possible
Windows driver does the allocation on its own (btw: Windows drivers
are the default ones: 1394bus.sys and ohci1394.sys).
Does anybody have some idea how to move on?
With best regards,
Petr Holub
Petr Holub
CESNET z.s.p.o. Supercomputing Center Brno
Zikova 2 Institute of Compt. Science
10200 Praha, CZ Masaryk University
Czech Republic Botanicka 68a, 60200 Brno, CZ
e-mail: [EMAIL PROTECTED] phone: +420-5-41512278
e-mail: [EMAIL PROTECTED]
dmesg.KLOBOUCEK
Description: Binary data
NATD libalias bug or feature?
Hello freebsd-hackers,
FreeBSD 4.3 RELEASE.
I tried to use natd transparent proxing ability with encode_ip_hdr
type. I found strange behaviour in function TcpAliasOut()
(/usr/src/lib/libalias/alias.c). When packet modified by
ProxyModify() (/usr/src/lib/libalias/alias_proxy.c), code
doesn't recompute pointer to TCP header by calling
tc = (struct tcphdr *) ((char *) pip + (pip->ip_hl << 2));
/usr/src/lib/libalias/alias.c line 1024
---begins here
/* Save original destination address, if this is a proxy packet.
Also modify packet to include destination encoding. */
if (proxy_type != 0)
{
SetProxyPort(link, dest_port);
SetProxyAddress(link, dest_address);
ProxyModify(link, pip, maxpacketsize, proxy_type);
}
/* Get alias address and port */
alias_port = GetAliasPort(link);
alias_address = GetAliasAddress(link);
-ends here-
should be
---begins here
/* Save original destination address, if this is a proxy packet.
Also modify packet to include destination encoding. */
if (proxy_type != 0)
{
SetProxyPort(link, dest_port);
SetProxyAddress(link, dest_address);
ProxyModify(link, pip, maxpacketsize, proxy_type);
/* Modify pointer to TCP Header, because it can be shifted
by ProxyModify() */
tc = (struct tcphdr *) ((char *) pip + (pip->ip_hl << 2));
}
/* Get alias address and port */
alias_port = GetAliasPort(link);
alias_address = GetAliasAddress(link);
-ends here-
Is it a bug or feature? :)
--
Best regards,
Stepachev Andrey mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: deadlock with softupdates ?
On Tue, Dec 18, 2001 at 10:55:27AM +, Josef Karthauser wrote: > On Mon, Dec 17, 2001 at 01:41:28PM -0800, Matthew Dillon wrote: > > If it is a vnode deadlock you have to find which process or > > processes it is deadlocking against. > > > > Do a ps -axl -M vmcore.X -N kernel.X on the kernel core, > > pick out all the processes blocked on inode or whatever, > > then from gdb go to each process (proc N) and do a backtrace > > (back). > > I've a similar problem with -current from recent (within the last week > or two). > > genius# ps -axl -M vmcore.15 -N kernel.15 > (attached file) > > The back traces for the processes locked in inode is also attached. > > Being green to debugging this kind of thing what should I do next? Maybe it's the maxusers 0 code. I saw your recent commit to work around not using the new config. I've rebuilt my kernel from scratch, clean. If it happens again I'll let you know. Joe msg30250/pgp0.pgp Description: PGP signature
Re: Instead of JFS, why not a whole new FS?
> Any FS that shares code with an existing FS will not flush out
> the full list of problems associated with writing a new FS in
> the context of a FreeBSD system.
how about an implementation of plan9's kfs? it is fairly simple, with
dentries similar to unix inodes, eg.
typedef struct {
char name[NAMELEN];
short uid;
short gid;
ushort mode;
short wuid;
Qid qid;
long size;
long dblock[NDBLOCK]; /* 6 */
long iblock;
long diblock;
long atime;
long mtime;
} Dentry;
and perhaps would make a good educational implementation. sources for
plan9's own is in plan9/sys/src/cmd/disk, if one needs to take a look.
the document "the plan9 file server" by thompson gives some detail.
oz
---
ozan s. yigit staff engineer, sun microsystems/es
http://www.cs.yorku.ca/~oz [EMAIL PROTECTED] || +1 [905] 415 2878
---
narrowness of imagination leads to narrowness of experience. [corollary to rob]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: NATD libalias bug or feature?
On Tue, Dec 18, 2001 at 05:33:34PM +0300, aka50 wrote: > Hello freebsd-hackers, > > FreeBSD 4.3 RELEASE. > > I tried to use natd transparent proxing ability with encode_ip_hdr > type. I found strange behaviour in function TcpAliasOut() > (/usr/src/lib/libalias/alias.c). When packet modified by > ProxyModify() (/usr/src/lib/libalias/alias_proxy.c), code > doesn't recompute pointer to TCP header by calling > tc = (struct tcphdr *) ((char *) pip + (pip->ip_hl << 2)); [...] Committed, thanks! Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD Romanian l10n
Hi, I would like to begin a Romanian FreeBSD localization project and I lack the necessary information like: * where I should look for appropiate documentation * what are the places L10N is needed * appropiate procedure for submiting patches * advices from skilled people in this area On a side note I would like the patches to catch the 4.5-RELEASE time frame; do you think it's possible ? What are the deadlines ? How different is the l10n procedure between -stable and -current ? ATTN: fellows interested on this project are very welcomed to contribute, please contact me. This project will be one of the main projects supported by the Romanian FreeBSD Users Group (RoFUG, www.rofug.ro). Thank you, Ady (@warpnet.ro) ___ | Programming in BASIC causes brain damage. | | (Edsger Wybe Dijkstra)| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Enhancing the CS461x audio driver...
On Tuesday 18 December 2001 12:59, you wrote: Hi there, > if you have docs that actually specify how to control the spdif output, > send them to me and i'll include it in a future driver version. > > -cg Unfortunately it seems I jumped to soon over it, the PDFs available on the Cirrus site don't contain any info about SPDIF, but I recall that the linux driver they have on their did contain the register addresses in a .h file, although I've seen that the ALSA driver for my card (4624 actually) is not able to enable digital output. I've gone to the cirrus site but somehow can't figure out how to download the linux driver (that or maybe is their javascript playing nasty with opera) and don't remember where I did put the copy I downloaded some time ago, but I would swear there is info on the spdif registers in the linux driver, I'll try to download it from a *gasp* windows box laster this evening and will look at it. Yours, -- Miguel Mendez - [EMAIL PROTECTED] EnergyHQ :: http://energyhq.homeip.net FreeBSD - The power to serve! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Instead of JFS, why not a whole new FS?
> UFS/FFS is/are proven through time. Throw in the softupdates technology,
> and you have the upside of journalling, without the downside of journalling.
> No. I'm not going into details, first because I'm not qualified, and second,
> others already have.
I think the bottom line to this whole thread is most folks out there
want a quick recovery (i.e., fast fsck's for large volumes).
I'm one of those folks who's gotten used to {XFS, JFS, EXT3, ReiserFS,
AdvFS, etc.}. Sure, journaling has it's issues (and I'm no expert), but
still having to wait for a fsck is a pain on large volumes, where as
waiting X number of seconds for a journal log replay is much easier to
contend with.
I've got a 891GB volume that's about 20% full, that takes 90 minutes or
so to fsck (and that's on a fiber channel, hardware RAID1+0 array). I'm
glad softupdates ensure the integrity of my data, but the wait is killer
in this production system :-)
> The one thing that journalling FSes deliver that FFS with softupdates doesn't
> right now is a 'fsck'less boot after an uncontrolled shutdown. I have read
> that the Project has this on their TODO list.
Yep... that's it exactly. I can't wait for 5.x (or fsck -B to be MFC'd
from -CURRENT :-)
Cheers,
Ryan
msg30255/pgp0.pgp
Description: PGP signature
Re: Found NFS data corruption bug... (was Re: NFS: How to make FreeBSD fall on its face in one easy step )
In the last episode (Dec 18), Mike Bristow said: > I suspect that the background fsck[1] that's available in FreeBSD-current > fits the bill just as well as JFS or XFS - and I'll also bet that it'll > be available in a FreeBSD-release before I'd trust data to a port of > JFS or XFS. The problems with a background fsck is you still have to run fsck, which can take 10 minutes on a large volume when it's idle, and who knows how long as a background process when the system's up. It might not even finish at all if a user starts modifying a large file, causing the snapshot file that the background fsck is using to grow and fill up the filesystem. Unlikely, but possible if your disk is almost full already. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deadlock with softupdates ?
On Tue, Dec 18, 2001 at 03:46:18PM +, Josef Karthauser wrote: > > > I've a similar problem with -current from recent (within the last week > > or two). > > > > genius# ps -axl -M vmcore.15 -N kernel.15 > > (attached file) > > > > The back traces for the processes locked in inode is also attached. > > > > Being green to debugging this kind of thing what should I do next? > > Maybe it's the maxusers 0 code. I saw your recent commit to work around > not using the new config. I've rebuilt my kernel from scratch, clean. > If it happens again I'll let you know. Ok. It's not that then. Symptoms processes block on vfscac whatever that is. I've not managed to catch a crash dump yet. Joe msg30257/pgp0.pgp Description: PGP signature
Re: A quick VM question
Now I know FreeBSD could defer creating an VM object until the last minute - when the page fault occurs. Thanks. -Zhihui On Tue, 18 Dec 2001, Matthew Dillon wrote: > > :What are the backing objects of the stack and heap area of a process's > :address space? When are they created? I saw the code vm_map_insert(), but > :the object argument given is NULL. > : > :Thanks, > : > :-Zhihui > > The backing objects are OBJT_DEFAULT objects. They are typically created > when the system first needs to retrieve the map entry's object or needs to > clip the map entry (for example, when extending the stack or > [s]brk()ing), so as to reduce the number of actual VM objects created and > to share the same VM object (with different offsets) whenever possible. > If you look in vm/vm_map.c that is what all those NULL tests and calls > to vm_object_allocate(OBJT_DEFAULT, ...) do. > > An OBJT_DEFAULT object is effectively a swap-backed object, just one > that does not yet have any swap associated with it. If/When the > system decides it needs to swap it will convert OBJT_DEFAULT objects > for the memory in question to OBJT_SWAP objects. The two are really > almost the same type of VM object. The type distinction is simply used > to optimize performance. > > The main VM object types are: > > OBJT_PHYS physically-backed, never swapped out. > OBJT_DEFAULTswap-backed with no swap yet assigned > OBJT_SWAP swap-backed > OBJT_VNODE vnode (e.g. file) backed object > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deadlock with softupdates ?
:genius# ps -axl -M vmcore.15 -N kernel.15=20 :(attached file) : :The back traces for the processes locked in inode is also attached. : :Being green to debugging this kind of thing what should I do next? : :Joe Please backtrace the processes stuck in 'vfscac' as well. Actually, backtrace all the processes that are stuck in weird places. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tx driver
Hi, On Tue, 18 Dec 2001, Petr Holub wrote: > Hi all! > > I've encountered really awful behavior of my SMC card using > tx driver in FreeBSD 4.3. On 100 Mbps network I get the throughput > just about 200 kBps :-( Colleagues of mine running some PC > based routers have very similar experiences with this driver > (in both 4.3 and 4.4 Rel's) The same card running under the > exactely same conditions in NetBSD is working pretty good > (11 MBps) and in Windows 2000 (8 MBps). Also running other cards > (like those with rl drivers) on the same network gives > very reasonable results in FreeBSD (approx. 10.5 MBps) so > I'm pretty convinced driver is to blame. Does anybody have > some workaround for this? the usual problem with this kind of performance with any driver is failed full/half duplex negotiation. Please try manually forcing your card to half or full duplex Add one of -mediaopt full-duplex or -mediaopt half-duplex depending on the setting of your switch to your ifconfig line in /etc/rc.conf This is the single most common cause of really low ethernet performance. I have had good experiences with the tx driver on 4.3 ond 4.4 releases. Greetings Christian -- CK Software GmbH Christian Kratzer, Schwarzwaldstr. 31, 71131 Jettingen Email: [EMAIL PROTECTED] Phone: +49 7452 889-135Open Software Solutions, Network Security Fax:+49 7452 889-136FreeBSD spoken here! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
userland program panics freebsd 4.3
I have a userland program that canpanic/reboot a freebsd 4.3 system.
Hardware is Intel isp1100 (mbx440 motherboard) 850MHZ pIII, 256mb ram, 640mb
swapfile
software is 'nessusd' (network security scanner) hits the ethernet port
pretty hard when running.
If I read the dumpdev right, it is crashing in the vm section of the kernel,
refrencing a structure that is not within kernel space?
(sp)
enabled ulimits (as per suggestion in comp.os.group)
cputime infinity secs
filesize 131072 kb
datasize-cur65536 kb
stacksize-cur 32768 kb
coredumpsize-cur0 kb
memoryuse-cur 65536 kb
memorylocked-cur65536 kb
maxprocesses 64
openfiles 128
sbsize infinity bytes
never hits these (at least, not log entries)
top shows it doesn't even hit swap file:(note, crashes with and without
snort running for those who know snort)
last pid: 27785; load averages: 0.46, 0.36, 0.25up 0+03:28:26
14:13:58
33 processes: 3 running, 30 sleeping
CPU states: 23.3% user, 0.0% nice, 4.7% system, 1.6% interrupt, 70.5%
idle
Mem: 42M Active, 157M Inact, 24M Wired, 14M Cache, 35M Buf, 13M Free
Swap: 640M Total, 640M Free
PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND
317 root4 0 9940K 9508K bpf 16:58 11.52% 11.52% snort
322 root4 0 9368K 8968K bpf 11:18 6.88% 6.88% snort
27343 root 10 0 5148K 4800K RUN 0:03 0.15% 0.15% nessusd
24346 root 10 0 4960K 4604K RUN 0:37 0.00% 0.00% nessusd
24566 root 28 0 1888K 1108K RUN 0:07 0.00% 0.00% top
165 root2 0 932K 512K select 0:07 0.00% 0.00% syslogd
14859 root2 0 2240K 1748K select 0:03 0.00% 0.00% sshd
262 root 10 0 4072K 3692K nanslp 0:02 0.00% 0.00% perl
173 root2 -12 1256K 912K select 0:01 0.00% 0.00% ntpd
330 root2 0 5692K 5168K select 0:00 0.00% 0.00% perl
255 root2 0 7208K 4780K select 0:00 0.00% 0.00% httpd
299 mysql 2 0 26168K 5280K poll 0:00 0.00% 0.00% mysqld
27353 root2 0 2280K 1792K select 0:00 0.00% 0.00% sshd
25728 root2 0 2240K 1756K select 0:00 0.00% 0.00% sshd
231 root 10 0 3380K 2904K nanslp 0:00 0.00% 0.00% perl
14887 root 18 0 1324K 944K pause0:00 0.00% 0.00% csh
27363 root3 0 1328K 960K ttyin0:00 0.00% 0.00% csh
enabled dumpdev and compiled kernel with -g
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
stray irq 7
fault virtual address = 0x8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01625d5
stack pointer = 0x10:0xd2110e1c
frame pointer= 0x10:0xd2110f2c
stray irq 7
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 = 27343 (nessusd)
interrupt mask = none
stray irq 7
trap number = 12
stray irq 7
panic: page fault
syncing disks... 7 1
done
Uptime: 3h27m57s
dumping to dev #ad/0x20001, offset 786944
dump ata0: resetting devices .. done
where
#0 dumpsys () at ../../kern/kern_shutdown.c:469
#1 0xc0134643 in boot (howto=256) at ../../kern/kern_shutdown.c:309
#2 0xc01349c0 in poweroff_wait (junk=0xc020454f, howto=-791358464)
at ../../kern/kern_shutdown.c:556
#3 0xc01d8b11 in trap_fatal (frame=0xd2110ddc, eva=8)
at ../../i386/i386/trap.c:951
#4 0xc01d87e9 in trap_pfault (frame=0xd2110ddc, usermode=0, eva=8)
at ../../i386/i386/trap.c:844
#5 0xc01d83cf in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -791358464, tf_esi = 72, tf_ebp = -770633940,
tf_isp = -770634232, tf_ebx = 0, tf_edx = -1047781184,
tf_ecx = -1071582376, tf_eax = -769392960, tf_trapno = 12, tf_err = 0,
tf_eip = -1072290347, tf_cs = 8, tf_eflags = 66118, tf_esp
= -791358464,
tf_ss = 2}) at ../../i386/i386/trap.c:443
#6 0xc01625d5 in fstatfs (p=0xd0d4d400, uap=0xd2110f80)
at ../../kern/vfs_syscalls.c:681
#7 0xc01d8dbd in syscall2 (frame={tf_fs = 134610991, tf_es = 47,
tf_ds = -1078001617, tf_edi = 134647524, tf_esi = 9,
tf_ebp = -1077939040, tf_isp = -770633772, tf_ebx = 672247464,
tf_edx = 3, tf_ecx = 672320104, tf_eax = 158, tf_trapno = 7, tf_err =
2,
tf_eip = 671957244, tf_cs = 31, tf_eflags = 663, tf_esp = -1077939468,
tf_ss = 47}) at ../../i386/i386/trap.c:1150
#8 0xc01cdb45 in Xint0x80_syscall ()
up 5
#5 0xc01d83cf in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -791358464, tf_esi = 72, tf_ebp = -770633940,
tf_isp = -770634232, tf_ebx = 0, tf_edx = -1047781184,
tf_ecx = -1071582376, tf_eax = -769392960, tf_trapno = 12, tf_err = 0,
tf_eip = -1072290347, tf_cs = 8, tf_eflags = 66118, tf_esp
= -791358464,
Re: Found NFS data corruption bug... (was Re: NFS: How to makeFreeBSD fall on its face in one easy step )
On Tue, 18 Dec 2001, Mike Bristow wrote: >I suspect that the background fsck[1] that's available in FreeBSD-current >fits the bill just as well as JFS or XFS - and I'll also bet that it'll >be available in a FreeBSD-release before I'd trust data to a port of >JFS or XFS. This is a killer feature. Has anyone decided whether snapshots and background fsck will ever be backported to the RELENG_4 branch or are they destined for 5.0? Brandon D. Valentine -- "Iam mens praetrepidans avet vagari." - G. Valerius Catullus, Carmina, XLVI To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deadlock with softupdates ?
On Tue, Dec 18, 2001 at 11:24:28AM -0800, Matthew Dillon wrote:
>
> :genius# ps -axl -M vmcore.15 -N kernel.15=20
> :(attached file)
> :
> :The back traces for the processes locked in inode is also attached.
> :
> :Being green to debugging this kind of thing what should I do next?
> :
> :Joe
>
> Please backtrace the processes stuck in 'vfscac' as well. Actually,
> backtrace all the processes that are stuck in weird places.
Ok, here are some vfscac processes:
(kgdb) bt
#0 0xc01db56d in mi_switch () at /usr/src/sys/kern/kern_synch.c:781
#1 0xc01dad33 in msleep (ident=0xc03326c0, mtx=0xc0355720, priority=66,
wmesg=0xc02e8634 "vfscache", timo=0) at
/usr/src/sys/kern/kern_synch.c:496
#2 0xc01cc709 in malloc (size=55, type=0xc03326c0, flags=0)
at /usr/src/sys/kern/kern_malloc.c:162
#3 0xc020acb6 in cache_enter (dvp=0xe42d5380, vp=0xe42d2900,
cnp=0xe4646c6c)
at /usr/src/sys/kern/vfs_cache.c:415
#4 0xc0277535 in ufs_lookup (ap=0xe4646b6c)
at /usr/src/sys/ufs/ufs/ufs_lookup.c:627
#5 0xc027c729 in ufs_vnoperate (ap=0xe4646b6c)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2658
#6 0xc020b1f6 in vfs_cache_lookup (ap=0xe4646bc4) at vnode_if.h:66
#7 0xc027c729 in ufs_vnoperate (ap=0xe4646bc4)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2658
#8 0xc020e9b9 in lookup (ndp=0xe4646c44) at vnode_if.h:45
#9 0xc020e4a4 in namei (ndp=0xe4646c44) at
/usr/src/sys/kern/vfs_lookup.c:168
#10 0xc0215df5 in lstat (td=0xe44ec104, uap=0xe4646d20)
at /usr/src/sys/kern/vfs_syscalls.c:2012
#11 0xc02b1c88 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077942172, tf_esi = -1077940908, tf_ebp = -1077942076,
tf_isp = -463180428, tf_ebx = 5, tf_edx = -1077940908, tf_ecx = 2,
tf_eax = 190, tf_trapno = 22, tf_err = 2, tf_eip = 673929251,
tf_cs = 31, tf_eflags = 663, tf_esp = -1077942312, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1150
#12 0xc02a52ed in syscall_with_err_pushed ()
#13 0x808e39c in ?? ()
#14 0x8052201 in ?? ()
#15 0x805abd0 in ?? ()
#16 0x806b735 in ?? ()
#17 0x804b699 in ?? ()
(kgdb) bt
#0 0xc01db56d in mi_switch () at /usr/src/sys/kern/kern_synch.c:781
#1 0xc01dad33 in msleep (ident=0xc03326c0, mtx=0xc0355720, priority=66,
wmesg=0xc02e8634 "vfscache", timo=0) at
/usr/src/sys/kern/kern_synch.c:496
#2 0xc01cc709 in malloc (size=42, type=0xc03326c0, flags=0)
at /usr/src/sys/kern/kern_malloc.c:162
#3 0xc020acb6 in cache_enter (dvp=0xe4765000, vp=0xe47c2840,
cnp=0xe44eac54)
at /usr/src/sys/kern/vfs_cache.c:415
#4 0xc68f936e in ?? ()
#5 0xc020e9b9 in lookup (ndp=0xe44eac2c) at vnode_if.h:45
#6 0xc020e4a4 in namei (ndp=0xe44eac2c) at
/usr/src/sys/kern/vfs_lookup.c:168
#7 0xc02193d8 in vn_open_cred (ndp=0xe44eac2c, flagp=0xe44eabf8,
cmode=3201,
cred=0xc7218500) at /usr/src/sys/kern/vfs_vnops.c:162
#8 0xc021919e in vn_open (ndp=0xe44eac2c, flagp=0xe44eabf8, cmode=3201)
at /usr/src/sys/kern/vfs_vnops.c:85
#9 0xc02147ca in open (td=0xe439f404, uap=0xe44ead20)
at /usr/src/sys/kern/vfs_syscalls.c:1115
#10 0xc02b1c88 in syscall (frame={tf_fs = 134545455, tf_es =
-1078001617,
tf_ds = -1078001617, tf_edi = 134591808, tf_esi = -1077937040,
tf_ebp = -1077937572, tf_isp = -464605836, tf_ebx = -1077939620,
tf_edx = 17, tf_ecx = -1077940892, tf_eax = 5, tf_trapno = 22,
tf_err = 2, tf_eip = 672822595, tf_cs = 31, tf_eflags = 647,
tf_esp = -1077940800, tf_ss = 47}) at
/usr/src/sys/i386/i386/trap.c:1150
#11 0xc02a52ed in syscall_with_err_pushed ()
#12 0x8049a75 in ?? ()
#13 0x8049a17 in ?? ()
#14 0x8049fa5 in ?? ()
#15 0x80496e2 in ?? ()
#16 0x8049622 in ?? ()
#17 0x8049219 in ?? ()
Joe
>
> -Matt
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
msg30263/pgp0.pgp
Description: PGP signature
Re: Found NFS data corruption bug... (was Re: NFS: How to make FreeBSD fall on its face in one easy step )
Dan Nelson wrote: > > In the last episode (Dec 18), Mike Bristow said: > > I suspect that the background fsck[1] that's available in FreeBSD-current > > fits the bill just as well as JFS or XFS - and I'll also bet that it'll > > be available in a FreeBSD-release before I'd trust data to a port of > > JFS or XFS. > > The problems with a background fsck is you still have to run fsck, > which can take 10 minutes on a large volume when it's idle, and who By the way the journaling filesystems don't neccessary guarantee that you won't need fsck: for example, if VXFS crashes at a particularly bad moment, it will require you to do "fsck -o full" which is as slow as the fsck on traditional UFS. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Found NFS data corruption bug... (was Re: NFS: How to make FreeBSD fall on its face in one easy step )
* Sergey Babkin <[EMAIL PROTECTED]> [011218 19:45] wrote: > Dan Nelson wrote: > > > > In the last episode (Dec 18), Mike Bristow said: > > > I suspect that the background fsck[1] that's available in FreeBSD-current > > > fits the bill just as well as JFS or XFS - and I'll also bet that it'll > > > be available in a FreeBSD-release before I'd trust data to a port of > > > JFS or XFS. > > > > The problems with a background fsck is you still have to run fsck, > > which can take 10 minutes on a large volume when it's idle, and who > > By the way the journaling filesystems don't neccessary guarantee that > you won't need fsck: for example, if VXFS crashes at a particularly > bad moment, it will require you to do "fsck -o full" which is as slow > as the fsck on traditional UFS. Yeah, but that's not mentioned in the whitepaper! :) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Found NFS data corruption bug... (was Re: NFS: How to make FreeBSD fall on its face in one easy step )
Alfred Perlstein wrote: > > By the way the journaling filesystems don't neccessary guarantee that > > you won't need fsck: for example, if VXFS crashes at a particularly > > bad moment, it will require you to do "fsck -o full" which is as slow > > as the fsck on traditional UFS. > > Yeah, but that's not mentioned in the whitepaper! :) Your insane humor quotient is very high today... Actually, this is mentioned in the white papers of all journalling FSs, but is generally glossed over with application specific hardware that is missing on PCs, which will record the cause of the failure across a reboot, and will throw a chock in front of the wheels before a bad write on a power failure... something IDE drives fail to do, but SCSI drives do not (or did not, until recently). Of course, you can't just use PC CMOS for this because of the lack of DC hold up time and AC fail notification in standard PC power supplies. You owe the Oracle your first born child, and , because of the GPL, anyone who marries your first born child owes the Oracle their first born child, and so on, recursively and eternally, forever after. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Found NFS data corruption bug... (was Re: NFS: How to make FreeBSD fall on its face in one easy step )
On Tue, 18 Dec 2001, Brandon D. Valentine wrote: > On Tue, 18 Dec 2001, Mike Bristow wrote: > > >I suspect that the background fsck[1] that's available in FreeBSD-current > >fits the bill just as well as JFS or XFS - and I'll also bet that it'll > >be available in a FreeBSD-release before I'd trust data to a port of > >JFS or XFS. > > This is a killer feature. Has anyone decided whether snapshots and > background fsck will ever be backported to the RELENG_4 branch or are > they destined for 5.0? In a word (or two): highly unlikely. This code has been considered experimental for a while now, and I expect that it will remain so. While it has been gradually improving stability (it no longer toasts your system when you send a kill signal to fsck_ffs in the background), a number of usability factors are still being addressed. Kirk recently committed several performance improvements that (apparently) result in a far more usable system during the background fsck. Previously, my system was available, but largely unuseful, during the background fsck. This code relies on the FFS snapshot feature, which is also not as widely tested, and has some compatibility concerns. If the support for snapshots hasn't yet been MFC'd to -STABLE fsck, we may want to consider doing so; last time I checked, if a snapshot was found by RELENG_4's fsck, it would be rather sadly removed with some unhappiness from fsck. As such, I'd probably resist efforts to MFC this code, and just go for inclusion in 5.0-RELEASE. We'll need to give it a lot of testing however. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Creative dxr2 DVD Decoder Card (fwd)
I was told that this would be the more appropiate place to send my question. I am not currently subscribed to the list, so please Cc: all msg's too my email. Thanks -- Forwarded message -- Date: Tue, 18 Dec 2001 13:41:55 +0100 From: Stijn Hoop <[EMAIL PROTECTED]> To: Josh <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: Creative dxr2 DVD Decoder Card On Tue, Dec 18, 2001 at 06:49:12AM -0500, Josh wrote: > Hello, > I am inquiring about the dxr2 dvd decoder card made by creative. > I would like to have some information about it, and whether anyone has > tried to support it under FreeBSD. I am active with the dxr2 decoder card > driver project for linux, and would like to possibly port the driver (and > player) to FreeBSD. Has anyone tried this before? The biggest problem I > find that I am going to run into is the non-opensource firmware file > distributed by creative that needs to be loaded into the card for it too > work. Any information anyone can give me would be appreicated, as I > didn't know what list to send this request to. I didn't try to port anything, but I was keeping an eye on the Linux project because I have a DXR-3 myself. If you are in need of FreeBSD testers, I'll gladly volunteer. Writing kernel drivers is still a bit above my head though... Maybe you should also ask on [EMAIL PROTECTED] - that is a more appropriate list for kernel hacking questions, in as far as I understand. --Stijn -- Tact, n.: The unsaid part of what you're thinking. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
request for %busy feature in iostat
Any possiblity of incorporating the %busy stats in iostat for 4.5, I know that it's available in systat, but it would be great if iostat would show this detailed info as well. If it makes things easier, I submitted a patch against -stable back on Aug 27th: - Date: Mon, 27 Aug 2001 22:28:06 -0700 - To: [EMAIL PROTECTED] - Subject: thoughts on %busy in iostat - Message-ID: <[EMAIL PROTECTED]> Thanks much in advance, -mohan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re[2]: NATD libalias bug or feature?
Hello everybody, Tuesday, December 18, 2001, 6:17:30 PM, you wrote: RE> On Tue, Dec 18, 2001 at 05:33:34PM +0300, aka50 wrote: >> Hello freebsd-hackers, >> >> FreeBSD 4.3 RELEASE. >> >> I tried to use natd transparent proxing ability with encode_ip_hdr >> type. I found strange behaviour in function TcpAliasOut() >> (/usr/src/lib/libalias/alias.c). When packet modified by >> ProxyModify() (/usr/src/lib/libalias/alias_proxy.c), code >> doesn't recompute pointer to TCP header by calling >> tc = (struct tcphdr *) ((char *) pip + (pip->ip_hl << 2)); RE> [...] RE> Committed, thanks! I'm using FreeBSD 4.2 REL as a natd transparent proxy. I looked through the /usr/src/lib/libalias/alias.c and of course I ain't got than string tc = (struct tcphdr *) ((char *) pip + (pip->ip_hl << 2)); in the source code. Should I correct that one or it is not necessary? -- Best regards, shupilovmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NATD libalias bug or feature?
On Wed, Dec 19, 2001 at 09:25:02AM +0200, shupilov wrote: > Hello everybody, > > Tuesday, December 18, 2001, 6:17:30 PM, you wrote: > > RE> On Tue, Dec 18, 2001 at 05:33:34PM +0300, aka50 wrote: > >> Hello freebsd-hackers, > >> > >> FreeBSD 4.3 RELEASE. > >> > >> I tried to use natd transparent proxing ability with encode_ip_hdr > >> type. I found strange behaviour in function TcpAliasOut() > >> (/usr/src/lib/libalias/alias.c). When packet modified by > >> ProxyModify() (/usr/src/lib/libalias/alias_proxy.c), code > >> doesn't recompute pointer to TCP header by calling > >> tc = (struct tcphdr *) ((char *) pip + (pip->ip_hl << 2)); > RE> [...] > > RE> Committed, thanks! > > I'm using FreeBSD 4.2 REL as a natd transparent proxy. I looked > through the /usr/src/lib/libalias/alias.c and of course I ain't got > than string > tc = (struct tcphdr *) ((char *) pip + (pip->ip_hl << 2)); > in the source code. Should I correct that one or it is not necessary? > It's only necessary if you use the "encode_ip_hdr" type of proxying. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
