RE: Large array in KVM
> On Fri, Dec 07, 2007 at 10:43:00AM +0100, Gerald Heinig wrote: > > Hi Sonja, > > > > > Hi everyone. > > > > > > I'm working on a kernel module that needs to maintain a large > > structure > > > in memory. As this structure could grow too big to be stored in > > memory, > > > it would be good to offload parts of it to the disk. What would be the > > > best way to do this? Could using a memory-mapped file help? > > > > How about implementing your code as a system call, which is called from > > a process that maps a large file into memory, as you suggested above. > > I presume you'd have to handle the question of whether or not your pages > > are in memory yourself, ie. pretty much like any other system call. > > > > Interesting question. > > Somewhat related question: > > What purpose does SYSCALL_MODULE(9) serve? I attempted to use this last > month while writing a kernel module of my own, and was never able to get > it to work for (what understood to be) a couple different reasons: > > 1) There's a maximum # of syscalls permitted (see SYS_MAXSYSCALL in > include/sys/sycall.h), which means a dynamically-allocated syscall via > SYSCALL_MODULE(9) cannot be inserted into the syscalls list. > > 2) The example code in share/examples/kld/syscall/module/syscall.c > specifies the sysent offset as NO_SYSCALL (e.g. -1). You can't pick an > arbitrary number here (from what I could tell), because the kernel > explicitly ensures that the syscall number being called is not larger > than SYS_MAXSYSCALL. This forces you to "steal" a syscall number > between 1 and SYS_MAXSYSCALL, no? > > 3) I tried using a syscall number (115, deprecated vtrace), using it as > the offset when calling SYSCALL_MODULE, but the userland program calling > syscall(2) returned an error. I didn't research this too thoroughly. > > As this was the first (only?) kernel module I attempted to write, it's > safe to say I'm missing some key knowledge, hence my question. :-) I've only ever written device drivers; I haven't yet implemented a system call so unfortunately I can't answer your questions, sorry. I do know that system calls have to deal with the possibility of pages being non-resident, and this prompted my suggestions above. Cheers, Gerald ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Large array in KVM
> Gerald Heinig wrote: > > > How about implementing your code as a system call, which is called from > > a process that maps a large file into memory, as you suggested above. > > What if the code is a device driver? I'm just assuming it isn't a device driver. Sonja (the original poster) just mentioned 'a kernel module'. It might be worth asking what exactly this module does and why it would need to be implemented as a kernel module if it needs so much memory. If it's a device driver, what is it driving? The only hardware that springs to mind which might need large amounts of memory is a camera driver or some high-speed sampling device. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Large array in KVM
Hi Sonja, > Hi everyone. > > I'm working on a kernel module that needs to maintain a large structure > in memory. As this structure could grow too big to be stored in memory, > it would be good to offload parts of it to the disk. What would be the > best way to do this? Could using a memory-mapped file help? How about implementing your code as a system call, which is called from a process that maps a large file into memory, as you suggested above. I presume you'd have to handle the question of whether or not your pages are in memory yourself, ie. pretty much like any other system call. Interesting question. Cheers, Gerald ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ????: Help:why bus resource shortage?
Hi Guys, On Fri, 2006-06-30 at 01:16 -0700, John-Mark Gurney wrote: > [EMAIL PROTECTED] wrote this message on Fri, Jun 30, 2006 at 14:26 +0800: > > I found the problem! It was caused by an existed ata driver in FreeBSD. I > > have mentioned before that the existed ata driver can take over the > > management of our HBA card, leading to our driver can not probe our card! By > > getting rid of the ID in ata-chipset.c,we can probe the HBA card, but we > > still can not get the pci resources! Instead, I can get rid of the effects > > of the existed ata driver by only getting rid of the ID in probe function of > > ata-pci.c! > > This has now been fixed by making the built in driver return a negative > value for the probe.. so your probe routine can return 0, and it will > win the probe for the device... Minor nitpick: it may perhaps be better to return a smaller negative value (eg. -5) rather than 0. IIRC -10 is the default score used by standard system drivers and 0 is the highest score available. If someone wants to use an alternative driver to Hong's and the standard system's it won't attach. > > > In summon, the problems (probe failure and bus resource short) lie in the > > hmm. that seems wierd, are you trying to allocate the resource in the > _probe function? You shouldn't need to unless you need to do special > munging of the resources to properly identify the device.. and unless > you return 0 from your _probe function, you will have to release the > resrouce at the end of the _probe function... > > > ata driver in FreeBSD, which can recognize our HBA card because it records > > the ID of this HBA. By getting rid of the switch case of this ID in probe > > function of ata-pci.c, you can take over the HBA completely. > > > > Here, I would like to report my solution (not tested yet) on a previous > > question about how to transfer physical address into kernel virtual address > > in FreeBSD: > > That is what the bus_space api is for... The method you propose is a > hack and not very useful for ensuring that your driver run on other > platforms... > > > -- > > ??: John-Mark Gurney [mailto:[EMAIL PROTECTED] > > : 2006??6??30?? 6:36 > > ??: [EMAIL PROTECTED] > > : freebsd-hackers@freebsd.org > > : Re: Help:why bus resource shortage? > > > > [EMAIL PROTECTED] wrote this message on Thu, Jun 15, 2006 at 14:55 > > +0800: > > > I failed to get the pci bus resource after the driver is loaded (sc->r_mem > > > is NULL after bus_alloc_resource_any is called). Is it because bus > > resources > > > have been consumed by other drivers? Or other something happened? Please > > > help me on this! > > > > Please provide a verbose boot (boot -v) output of the pci card... > > > > > rid = 0x10; > > > > You really should be using PCIR_BAR macro instead of hard coding it... > > > > > sc->r_mem = bus_alloc_resource_any(sc->dev, SYS_RES_MEMORY, &rid, > > > RF_ACTIVE); > > > > > > if (!sc->r_mem) return ENOMEM; > > > > > > > > > > > > The pci resources on our cards: > > > > > > shasta0: port 0x2400-0x247f, > > > 0x2000-0x20ff mem 0xe9021000-0xe9021fff, 0xe900-0xe901 irq 17 at > > > device 5.0 on pci2 > > > > The resources could be in a different order than listed... Are you > > sure the memory resource is in the first bar possition? > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: link_elf:symol m_gethdr udefined
Hi Puramukas, Puramukas wrote: I get this error when try to load NICs driver kldload if_yk.ko for Marvel Yukon 88E8053 Gigabit adapter on frebsd 5.3 ---^^^ This is a Yukon-EC adapter which isn't supported yet for FreeBSD. Where did you get this driver from? The page you cited below doesn't have any FreeBSD drivers for Yukon-EC cards. All the same, you certainly shouldn't get an error message about any undefined functions. The driver shouldn't even attach. Are you _sure_ that the error message is produced when you load the driver and that it isn't caused by something else? i tryed to recompile kernel with variuos conf but nothing helped and maybe the drive wich i try to use do not fit for 5.3 http://www.syskonnect.com/syskonnect/support/driver/d0102_driver.html i also posted this probelm in questions ML several times but with no repsone so can someone help me pls? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: link_elf:symol m_gethdr udefined
Hi Puramukas, which driver version are you using? Did you get this error message with the standard GENERIC kernel that came with 5.3-RELEASE, or did you get it with your own kernel? By the way, if you get problems with our drivers, please contact [EMAIL PROTECTED] That way we can log problems officially and provide new releases. Cheers, Gerald Puramukas wrote: I get this error when try to load NICs driver kldload if_yk.ko for Marvel Yukon 88E8053 Gigabit adapter on frebsd 5.3 i tryed to recompile kernel with variuos conf but nothing helped and maybe the drive wich i try to use do not fit for 5.3 http://www.syskonnect.com/syskonnect/support/driver/d0102_driver.html i also posted this probelm in questions ML several times but with no repsone so can someone help me pls? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bus_dmamem_alloc strangeness
Hi hackers,
I've come across weird behaviour in bus_dmamem_alloc() whilst trying to
allocate small memory blocks (less than PAGE_SIZE) which have to be
aligned to PAGE_SIZE.
My segment size is 2048, my maximum number of segments is 1 (it MUST be
contiguous), my max. total segment size is also 2048 and my alignment
constraint is 4k (PAGE_SIZE). However, the DMA memory I'm getting from
bus_dmamem_alloc() is NOT aligned to 4k.
The relevant code in sys/i386/i386/busdma_machdep.c is:
=
if ((dmat->maxsize <= PAGE_SIZE) &&
dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem)) {
*vaddr = malloc(dmat->maxsize, M_DEVBUF, mflags);
} else {
/*
* XXX Use Contigmalloc until it is merged into this facility
* and handles multi-seg allocations. Nobody is doing
* multi-seg allocations yet though.
* XXX Certain AGP hardware does.
*/
*vaddr = contigmalloc(dmat->maxsize, M_DEVBUF, mflags,
0ul, dmat->lowaddr, dmat->alignment? dmat->alignment : 1ul,
dmat->boundary);
}
==
My lowaddr is BUS_SPACE_MAXADDR and I'm allocating 2k blocks which have
to be 4k-aligned, which would imply the first if branch.
Surely the code should adhere to the alignment restrictions and not
simply allocate memory without checking, or am I missing something here?
Cheers,
Gerald
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewire blues
Stephan Uphoff wrote:
On Wed, 2005-02-16 at 07:19, Gerald Heinig wrote:
Gerald Heinig wrote:
Ulrich Spoerlein wrote:
[stuff snipped]
Other than that, remote gdb is working. Poking inside the fwmem itself
is however not working, I get this after setting eui64_{hi,lo}
% kgdb -c /dev/fwmem0.0 kernel.debug
...
0x in ?? ()
I got this as well. In my case I assumed it's due to the fact that I
wasn't using the same kernel file for the debugger as was running on the
target machine. I didn't investigate further because I can't spend any
more time on this problem at the moment.
I'd be interested to know whether that is the problem though.
I just tried it (had to compile new kernel anyway). It's not due to a
symbol mismatch.
ENOCLUE :(
With this way of debugging you can only read the memory of the target
machine and NOT the state of the CPU.
This means that you can not get a current stack backtrace or the current
pc. You can however go through the list of processes, find the currently
running thread, look at data structures, get backtraces of non-running
threads
That makes sense.
Are there any macros with which one can get the thread table address,
the address of the currently running thread etc etc?
I noticed in Greg's paper he makes several .gdbinit files. Does any of
that work/exist under 5.3?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewire blues
Gerald Heinig wrote:
Ulrich Spoerlein wrote:
[stuff snipped]
Other than that, remote gdb is working. Poking inside the fwmem itself
is however not working, I get this after setting eui64_{hi,lo}
% kgdb -c /dev/fwmem0.0 kernel.debug
...
0x in ?? ()
I got this as well. In my case I assumed it's due to the fact that I
wasn't using the same kernel file for the debugger as was running on the
target machine. I didn't investigate further because I can't spend any
more time on this problem at the moment.
I'd be interested to know whether that is the problem though.
I just tried it (had to compile new kernel anyway). It's not due to a
symbol mismatch.
ENOCLUE :(
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewire blues
Ulrich Spoerlein wrote:
On Sun, 13.02.2005 at 22:46:29 -0500, Stephan Uphoff wrote:
+device dcons
+device dcons_crom
Then configured/compiled/installed the GENERIC.debug kernel.
Copied the kernel.debug file in the GENERIC.debug compile directory to
the debug station and rebooted the target machine.
I tried this with modules first, and failed every time. It needs to be
compiled into the kernel to really work, which brings me to the next
problem.
When dcons_crom is loaded (module or not) and I boot my system (laptop),
I only get the "kernel output" on screen. All the other output (starting
from Mounting root from ufs) goes to the firewire console.
I don't know whether this will break other stuff, but in the course of
my attempts to get the setup working, I tried setting
options DCONS_FORCE_CONSOLE=1
This caused all the output of the console to go to the Firewire port. I
could log in etc. as normal on the console (over Firewire of course).
But since I'm using GBDE on this laptop, the startup scripts want me to
enter my passphrase, which in turn I can only enter via a second machine
through firewire.
This _is_ rather unpractical :( and renders single-user console useless.
What am I doing wrong here?
Other than that, remote gdb is working. Poking inside the fwmem itself
is however not working, I get this after setting eui64_{hi,lo}
% kgdb -c /dev/fwmem0.0 kernel.debug
...
0x in ?? ()
I got this as well. In my case I assumed it's due to the fact that I
wasn't using the same kernel file for the debugger as was running on the
target machine. I didn't investigate further because I can't spend any
more time on this problem at the moment.
I'd be interested to know whether that is the problem though.
What's missing here?
Ulrich Spoerlein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewire blues
Stephan Uphoff wrote: On Tue, 2005-02-15 at 11:55, Gerald Heinig wrote: Hi Stephan, I'm happy to say that it's working now :) I grabbed a 5.3-STABLE snapshot to get the updated kgdb and completely reinstalled my 5.3-RELEASE system. I compiled the kernel using your options and it worked straight away. I have no idea why it didn't work before. It must be some boot variable I set way back whenever. Thanks very much indeed for helping me out with this! I really appreciate your patience. Great. By the way, did you ever get the non-cooperative debugging working? I tried that, but it doesn't work, complaining about invalid hex digits. That's the debug method I'm _really_ interested in, because it enables you to debug hangs and freezes. Never used it before - but is works for me. debug# fwcontrol 2 devices (info_len=2) node EUI64 status 0 00-11-06-66-40-00-82-34 0 1 00-11-06-66-40-00-18-dd 1 debug# sysctl -w hw.firewire.fwmem.eui64_hi=0x00110666 hw.firewire.fwmem.eui64_hi: 1073775156 -> 1115750 debug# sysctl -w hw.firewire.fwmem.eui64_lo=0x400018dd hw.firewire.fwmem.eui64_lo: 0 -> 1073748189 debug# kgdb -c /dev/fwmem0.0 kernel.debug Damn. I was using the -r option. Of course it should be -c. D'oh.. :( Anyway, it works fine for me too now. Stephan, you da man!! :) Cheers, Gerald Anyway, enough for now. Thanks again. Cheers, Gerald Stephan Uphoff wrote: On Mon, 2005-02-14 at 11:41, Gerald Heinig wrote: Gerald Heinig wrote: Hi Stephan, first off, thanks very much for your continuing help on this. It's very much appreciated. I compiled a kernel with exactly the same options that you cited below. I tried booting it and it stops before the kernel probe routines and waits for the FireWire GDB connect. I can't understand how you managed to reboot the target machine without it entering the debugger and waiting for the remote gdb attach. My machine refuses to do anything else. I tried unsetting boot_ddb and boot_gdb in the loader, as well as clearing the -d and -g flags in the boot_flags variable. No deal, it still stops and waits for the remote gdb attach. I did change anything at the bootstrap loader. The tests were done 15 minutes after a complete new install (wiped the disk) from a 5.3 CD. You may want to take another look at you boot flags / variables. When I try to attach from the debug machine, gdb complains about operation not supported. Also, I don't understand how your command line kgdb -r : -t 11-22-33-44-55... D'oh... What I meant was: kgdb -r : kernel.debug . Time to go home I suppose... can work. I just get ':: no such file or directory' when I try that. The kgdb manpage also states that it needs a device Just looked at the CVS repository. Seems like you need to update to a newer kgdb on the debug station. The old version does not understand tcp ports and needs devices. If this is not an option then you can probably use some pty to tcp forwarding program. The debugger would connect to the pty and the forwarding program opens a connection to dconschat and forwards data in both directions. ( Sorry - used such a program a long, long time ago but can't remember the name ) Stephan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewire blues
Hi Stephan, I'm happy to say that it's working now :) I grabbed a 5.3-STABLE snapshot to get the updated kgdb and completely reinstalled my 5.3-RELEASE system. I compiled the kernel using your options and it worked straight away. I have no idea why it didn't work before. It must be some boot variable I set way back whenever. Thanks very much indeed for helping me out with this! I really appreciate your patience. By the way, did you ever get the non-cooperative debugging working? I tried that, but it doesn't work, complaining about invalid hex digits. That's the debug method I'm _really_ interested in, because it enables you to debug hangs and freezes. Anyway, enough for now. Thanks again. Cheers, Gerald Stephan Uphoff wrote: On Mon, 2005-02-14 at 11:41, Gerald Heinig wrote: Gerald Heinig wrote: Hi Stephan, first off, thanks very much for your continuing help on this. It's very much appreciated. I compiled a kernel with exactly the same options that you cited below. I tried booting it and it stops before the kernel probe routines and waits for the FireWire GDB connect. I can't understand how you managed to reboot the target machine without it entering the debugger and waiting for the remote gdb attach. My machine refuses to do anything else. I tried unsetting boot_ddb and boot_gdb in the loader, as well as clearing the -d and -g flags in the boot_flags variable. No deal, it still stops and waits for the remote gdb attach. I did change anything at the bootstrap loader. The tests were done 15 minutes after a complete new install (wiped the disk) from a 5.3 CD. You may want to take another look at you boot flags / variables. When I try to attach from the debug machine, gdb complains about operation not supported. Also, I don't understand how your command line kgdb -r : -t 11-22-33-44-55... D'oh... What I meant was: kgdb -r : kernel.debug . Time to go home I suppose... can work. I just get ':: no such file or directory' when I try that. The kgdb manpage also states that it needs a device Just looked at the CVS repository. Seems like you need to update to a newer kgdb on the debug station. The old version does not understand tcp ports and needs devices. If this is not an option then you can probably use some pty to tcp forwarding program. The debugger would connect to the pty and the forwarding program opens a connection to dconschat and forwards data in both directions. ( Sorry - used such a program a long, long time ago but can't remember the name ) Stephan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewire blues
Gerald Heinig wrote: Hi Stephan, first off, thanks very much for your continuing help on this. It's very much appreciated. I compiled a kernel with exactly the same options that you cited below. I tried booting it and it stops before the kernel probe routines and waits for the FireWire GDB connect. I can't understand how you managed to reboot the target machine without it entering the debugger and waiting for the remote gdb attach. My machine refuses to do anything else. I tried unsetting boot_ddb and boot_gdb in the loader, as well as clearing the -d and -g flags in the boot_flags variable. No deal, it still stops and waits for the remote gdb attach. When I try to attach from the debug machine, gdb complains about operation not supported. Also, I don't understand how your command line kgdb -r : -t 11-22-33-44-55... D'oh... What I meant was: kgdb -r : kernel.debug . Time to go home I suppose... can work. I just get ':: no such file or directory' when I try that. The kgdb manpage also states that it needs a device ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewire blues
Hi Stephan, first off, thanks very much for your continuing help on this. It's very much appreciated. I compiled a kernel with exactly the same options that you cited below. I tried booting it and it stops before the kernel probe routines and waits for the FireWire GDB connect. I can't understand how you managed to reboot the target machine without it entering the debugger and waiting for the remote gdb attach. My machine refuses to do anything else. I tried unsetting boot_ddb and boot_gdb in the loader, as well as clearing the -d and -g flags in the boot_flags variable. No deal, it still stops and waits for the remote gdb attach. When I try to attach from the debug machine, gdb complains about operation not supported. Also, I don't understand how your command line kgdb -r : -t 11-22-33-44-55... can work. I just get ':: no such file or directory' when I try that. The kgdb manpage also states that it needs a device after the -r option, so I presume your kgdb version works somewhat differently to mine. I tried the following devices after kgdb's -r option: /dev/fwmem0.0, /dev/fw0, /dev/net/fwe0, /dev/net/fwip0 None worked. I tried taking the dcons/dcons_crom options out of the kernel and loading the corresponding modules before booting the kernel. This sort of worked in that I could then start a dconschat session on the debug machine and enter the ddb debugger. Switching to gdb didn't work, since the gdb backend was missing. When the kernel booted, it complained about there being no debug ports for gdb present, so it didn't enable the gdb backend support. Stephan Uphoff wrote: OK - I finally managed to try this on a newly installed 5.3-RELEASE. I copied the GENERIC config file (to GENERIC.debug) and added a few lines diff -u GENERIC GENERIC.debug --- GENERIC Sun Oct 24 14:02:52 2004 +++ GENERIC.debug Mon Feb 14 03:15:21 2005 @@ -24,6 +24,14 @@ cpuI686_CPU ident GENERIC +makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols +options KDB # Enable kernel debugger support. +options DDB # Support DDB. +options GDB # Support remote GDB. +options ALT_BREAK_TO_DEBUGGER +device dcons +device dcons_crom + # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. This is pretty much what I had before. Then configured/compiled/installed the GENERIC.debug kernel. Copied the kernel.debug file in the GENERIC.debug compile directory to the debug station and rebooted the target machine. Why does your machine boot without waiting for a debug connection? With the debug options mentioned above, my kernel waits for the remote Firewire gdb connection here, which doesn't work. Are there any loader flags I have to set? After reboot I set the default debugger to gdb target# sysctl -w debug.kdb.current=gdb and entered the debugger target# sysctl -w debug.kdb.enter=1 On the debugging station I entered debug 1# dconschat -br -G -t and then in another window debug 2# kgdb -r : kernel.debug ---^ This doesn't work on my system: kgdb complains about ': : no such file or directory' And it just worked for me. I have to admit that my debugging machine is not 5.3 .. but I believe I used the same setup with pre 5.3 userland before. Let me know if you can repeat my steps. If not then I can set up a 5.3 debugging station in the next days. Thanks again for your patience. Cheers, Gerald ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VMCORE NOT FOUND
Ashwin Chandra wrote: ryan, i think i was a bit vague in my email. I am correctly usnig the swap device and dump directory. Before the system reboots the core should be saved from the swap device (before it mounts) and into the path that i specified. dumpdev="/dev/ad0s1b", our 2gb swap device and dumpdir="/usr/crash" So I am doing all this correctly, yet still no dump comes up and I am not sure why! =( Hi Ashwin, for what it's worth, I have exactly the same problem on my Dell GX 260/FreeBSD 5.3 RELEASE machine. When it panics, it says it's starting to write a dump, but doesn't continue. The disk lights remain off, so there's definitely no activity. Strangely enough, when I use my Dual Tyan box (AMD-based) with a kernel compiled with the same config file, I get a dump without ahny problems. I mentioned this on -hackers a few weeks ago. Cheers, Gerald ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewire blues
Stephan Uphoff wrote: Once I linked in dcons, dcons_crom and firewire into the kernel everything worked. (I think only dcons is really needed - maybe a link set issue?) I only used the gdb stub method. Can you send me your dmesg? (After you linked the dcons stuff into the kernel) Another thing: what system are you on? -current? I'm using 5.3-RELEASE and I've noticed that a lot of the commands and responses in the HowTo are different to my system. Could that be the problem? Cheers, Gerald ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewire blues
Stephan Uphoff wrote: On Wed, 2005-02-09 at 03:13, Gerald Heinig wrote: Stephan Uphoff wrote: There are two ways using kgdb to debug a target with firewire. The first way basically replaces the slow serial cable for communication to the remote target gdb stub. The second way uses the remote DMA capabilities of firewire to directly read memory of the target WITHOUT using any debugging software/stub on the target. (Think remote core file) Greg Lehey wrote a nice kernel debugging tutorial that explains both types of firewire debugging. http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf This should get you started with only minor adjustments (gdb->kgdb) . This is actually the paper I'm using. I've followed the instructions on both methods, but I can't get it to work. The direct machine-machine connection is fine (ie. the one with dconschat). It's the kgdb connection that doesn't work. I presume it worked out of the box for you then? Once I linked in dcons, dcons_crom and firewire into the kernel everything worked. (I think only dcons is really needed - maybe a link set issue?) I only used the gdb stub method. Can you send me your dmesg? (After you linked the dcons stuff into the kernel) Hi Stephan, here's my dmesg: Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-RELEASE #0: Thu Feb 10 11:28:00 CET 2005 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/FIREWIRE MPTable: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (2000.04-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff real memory = 535236608 (510 MB) avail memory = 514101248 (490 MB) ioapic0: Changing APIC ID to 1 ioapic0: Assuming intbase of 0 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: at device 2.0 (no driver attached) uhci0: port 0xff80-0xff9f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xff60-0xff7f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib1: at device 30.0 on pci0 pci1: on pcib1 pci1: at device 7.0 (no driver attached) fwohci0: port 0xec80-0xecff mem 0xff8fb800-0xff8fbfff irq 17 at device 8.0 on pci1 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:01:08:00:37:01:c3:be fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1f2fc000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:01:08:01:c3:be fwe0: Ethernet address: 02:01:08:01:c3:be fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc1, gen=1, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) pci1: at device 9.0 (no driver attached) pci1: at device 10.0 (no driver attached) em0: port 0xec40-0xec7f mem 0xff8c-0xff8d irq 18 at device 12.0 on pci1 em0: Ethernet address: 00:08:74:f5:ca:44 em0: Speed:N/A Duplex:N/A isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) cpu0 on motherboard orm0: at iomem 0xc9800-0xcbfff,0xc8000-0xc97ff,0xc-0xc7fff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 fdc0: at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of pro
Re: Firewire blues
Stephan Uphoff wrote: There are two ways using kgdb to debug a target with firewire. The first way basically replaces the slow serial cable for communication to the remote target gdb stub. The second way uses the remote DMA capabilities of firewire to directly read memory of the target WITHOUT using any debugging software/stub on the target. (Think remote core file) Greg Lehey wrote a nice kernel debugging tutorial that explains both types of firewire debugging. http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf This should get you started with only minor adjustments (gdb->kgdb) . This is actually the paper I'm using. I've followed the instructions on both methods, but I can't get it to work. The direct machine-machine connection is fine (ie. the one with dconschat). It's the kgdb connection that doesn't work. I presume it worked out of the box for you then? Cheers, Gerald ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewire blues
Gerald Heinig wrote: I recall some issues with gdb and firewire as a module that may or may not be fixed. I recommend to put the dcons into the kernel to avoid any problems. I tried that too. There are a few additional flags that can be set. Of particular interest are DCONS_FORCE_CONSOLE and DCONS_FORCE_GDB. I presume I should set FORCE_CONSOLE to 1 if I want a console over firewire, am I right? I'll take a look and see if there are any bugfixes for firewire. It turns out that you need to set DCONS_FORCE_CONSOLE to 1 if you want to have a remote console over firewire. I've got my link working with firewire now, but unfortunately I still can't get kgdb to connect. If I do the following on the debugging machine: kgdb -r /dev/fwmem0.0 kernel.debug I get: [general gdb stuff] Switching to remote protocol get_tty_state failed: Invalid argument set_tty_state failed: Invalid argument get_tty_state failed: Invalid argument set_tty_state failed: Invalid argument Couldn't establish connection to remote target Reply contains invalid hex digit 12 When doing this, the remote machine's kernel wqas compiled with devices dcons and dcons_crom and options DCONS_FORCE_GDB=1 Any ideas? Cheers, Gerald ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewire blues
Stephan Uphoff wrote: On Mon, 2005-02-07 at 04:16, Gerald Heinig wrote: Hi all, I'm having problems getting two 5.3-RELEASE boxes to communicate over firewire. I'm using two VIA Vt-6306 -based cards which are correctly recognised at boot-time. I've loaded the dcons and dconschat modules and obtained both firewire addresses via fwcontrol. I assume you mean dcons_crom module instead of dconschat. Yes, sorry, my mistake. Did you reset the firewire bus? I did reset it, but only on the debugging system, not on the target system. DCONS_CROM(4): . BUGS If you load dcons_crom.ko manually after booted, you may have to initiate a bus reset by ``fwcontrol -r'' to update Configuration ROM. When I try to set up a connection with dconschat I get [dcons disconnected (get crom failed)] The exact command I gave is: dconschat -br -G 5556 -t I also tried setting the control ROM address with the -a option, to no avail. Anyone have any ideas as to where I'm going wrong? BTW, I'm trying to set up remote debugging with gdb to debug a kernel hang. I recall some issues with gdb and firewire as a module that may or may not be fixed. I recommend to put the dcons into the kernel to avoid any problems. I tried that too. There are a few additional flags that can be set. Of particular interest are DCONS_FORCE_CONSOLE and DCONS_FORCE_GDB. I presume I should set FORCE_CONSOLE to 1 if I want a console over firewire, am I right? I'll take a look and see if there are any bugfixes for firewire. Thanks for the reply! Cheers, Gerald ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Firewire blues
Hi all, I'm having problems getting two 5.3-RELEASE boxes to communicate over firewire. I'm using two VIA Vt-6306 -based cards which are correctly recognised at boot-time. I've loaded the dcons and dconschat modules and obtained both firewire addresses via fwcontrol. When I try to set up a connection with dconschat I get [dcons disconnected (get crom failed)] The exact command I gave is: dconschat -br -G 5556 -t I also tried setting the control ROM address with the -a option, to no avail. Anyone have any ideas as to where I'm going wrong? BTW, I'm trying to set up remote debugging with gdb to debug a kernel hang. Cheers, Gerald ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Kernel won't dump on panic
Hi all, I'm having problems getting a kernel to write a crash dump on my Dell Optiplex under FreeBSD 5.3. I've set dumpdev="/dev/ad0s1b", set kern.sync_on_panic to 1, the dump device has enough space (1 Gig, physical RAM is 512M). When the kernel panics, it starts writing out a vmcore, but only gets to 2 blocks and then stops. Things work fine with my dual processor Tyan Tiger box. Anyone have any ideas as to what I might be doing wrong? Cheers, Gerald ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Benchmark: NetBSD 2.0 beats FreeBSD 5.3
Hi Kamal,
I don't know about any switches for ULE. My point is that it's not
particularly meaningful to compare a system that's built for SMP to one
that isn't. There have been a number of tests (sorry, don't have time to
dig them all out) of systems with MP locks against systems without on a
uniprocessor machine. The systems with MP locks were all slower.
I remember a test done with Linux (2.4 IIRC) compiled with MP support
and without; there were significant differences. Tests with Solaris x86
against Linux on a 1-processor machine also showed Solaris performing
poorly. Use a proper MP box ("proper" meaning >= 4 CPUs) and the picture
usually changes.
I'd be interested to see the same test done on a 4 CPU box.
Cheers,
Gerald
Kamal R. Prasad wrote:
--- Gerald Heinig <[EMAIL PROTECTED]> wrote:
Hi Robert,
the benchmark you cited is for uniprocessor systems
only.
It says nothing about multiprocessor performance,
which is what FreeBSD
is aiming for.
Doesn't the (ULE) scheduler have a switch to ensure
that performance is optimal on a uniprocessor machine
too?
It's comparing apples with oranges.
Cheers,
Gerald
Netbsd works for upto 4 processors. So you should be
able to run the same tests on a quad-processor SMP
machine.
regards
-kamal
Robert Ryan wrote:
Fellow FreeBSD developers,
I hate to say I told you but it was inevitable.
Check this out:
http://www.feyrer.de/NetBSD/gmcgarry/
As I predicted more than a year ago FreeBSD 5.3
has
finally lost its only advantage: performance.
NetBSD
2.0 shows that when you write code the right way
and
end up with SOLUTIONS AND NOT HACKS you have a
system
that works, and works well on all platforms.
This is the consequence of a series of mistakes
made
by the FreeBSD developers, the most important
being
too arrogant and selfish to listen to Matt Dillon,
the
man that warned you all about this. What did he
get
in return? An expulsion from your gentlemen club.
Poul-Henning Kamp has been using FreeBSD to push
his
personal agenda, with completely useless features
such
as GEOM and devfs, instead of concentrating on the
real
problem. The fact that your heavily mutexed system
doesn't work and never will.
Jeff Roberson's ULE is still broken but don't
worry,
Matt Dillon will be hacking a much better
scheduler
for DragonFly that you can later borrow.
Mike Smith warned you about committee-designed
code
years ago, why don't you listen? Why do you insist
on
this arrogant pose and on treating potential
contributors like pariahs?
Why do you tolerate assholes like Dag-Erling and
Poul-Henning?
I hope you can learn something from the NetBSD
people
before it's too late for FreeBSD. They managed to
do
much more with less resources. You should feel
ashamed
of yourselves.
Sincerely,
Robert
PS: if I've offended anyone (yeah, I singled a few
out)
, prove me wrong, but spare me your insultedness.
It's become a pathetic hobby in -core.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Benchmark: NetBSD 2.0 beats FreeBSD 5.3
Hi Robert, the benchmark you cited is for uniprocessor systems only. It says nothing about multiprocessor performance, which is what FreeBSD is aiming for. It's comparing apples with oranges. Cheers, Gerald Robert Ryan wrote: Fellow FreeBSD developers, I hate to say I told you but it was inevitable. Check this out: http://www.feyrer.de/NetBSD/gmcgarry/ As I predicted more than a year ago FreeBSD 5.3 has finally lost its only advantage: performance. NetBSD 2.0 shows that when you write code the right way and end up with SOLUTIONS AND NOT HACKS you have a system that works, and works well on all platforms. This is the consequence of a series of mistakes made by the FreeBSD developers, the most important being too arrogant and selfish to listen to Matt Dillon, the man that warned you all about this. What did he get in return? An expulsion from your gentlemen club. Poul-Henning Kamp has been using FreeBSD to push his personal agenda, with completely useless features such as GEOM and devfs, instead of concentrating on the real problem. The fact that your heavily mutexed system doesn't work and never will. Jeff Roberson's ULE is still broken but don't worry, Matt Dillon will be hacking a much better scheduler for DragonFly that you can later borrow. Mike Smith warned you about committee-designed code years ago, why don't you listen? Why do you insist on this arrogant pose and on treating potential contributors like pariahs? Why do you tolerate assholes like Dag-Erling and Poul-Henning? I hope you can learn something from the NetBSD people before it's too late for FreeBSD. They managed to do much more with less resources. You should feel ashamed of yourselves. Sincerely, Robert PS: if I've offended anyone (yeah, I singled a few out) , prove me wrong, but spare me your insultedness. It's become a pathetic hobby in -core. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Accessing (the i4b) device driver
Martin, take a look at isdnd. If all you want is a program to tell you whether someone's calling you and under what number, isdnd will tell you that in full screen mode. Alternatively, if you want to write your own program, take a look at the isdnd sources to see how it's done. HTH, Gerald Martin Moeller wrote: Hi all, I'm totally new to FreeBSD programming, so please forgive my troll-like question! I'd like to write a nifty little program showing if somebody is calling me via an ISDN line. In the far future, the program should show the caller's telephone number. The ISDN kernel options are set and compiled ok, the system comes up with isic0: port 0xb800-0xb803,0xd000-0xd07f mem 0xeb80-0xeb80007f irq 9 at device 11.0 on pci2 isic0: passive stack unit 0 so I assume everything's working great so far. I've looked around in /usr/src/sys/i386/include/i4b_ioctl.h and other files but - to be honest - I don't have a clue how to go on from here. This kernel stuff seems to be more complicated than the usual little useless programs I write. :-( Could you please point me to some documentation that is helpful? Nothing in the FBSD developer/architecture handbook was able to enlighten me. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sysctl and ifmibdata/ifmib_iso_8802_3
Hi,
I have a question regarding the use of sysctl and snmp MIBs for network
adapters.
I've taken a look at the ifmib(4) manpage and the corresponding files in
...sys/net/if_mib.c and /usr/include/net/if_mib.h and it seems that only
a few network drivers declare the ifmib structures. When I try to
declare them in my driver[1], nothing happens, ie. I can't see the
structure. snmpwalk gives nothing and sysctl net.link.generic.ifmib is
empty.
Is any of this stuff implemented at all, or is it deprecated or what? It
Just Doesn't Work.
Anyone know any more about this?
Thanks for any info,
Gerald
[1] To be exact:
struct yk_softc {
...
struct ifmib_iso_8802_3 yk_ethermib;
...
}
in yk_attach():
struct ifnet*yk_if;
struct yk_softc *sc;
...
...
yk_if->if_linkmib = &sc->yk_ethermib;
yk_if->if_linkmiblen = sizeof(struct ifmib_iso_8802_3);
--
S y s K o n n e c t G m b H
A Marvell Company
Siemensstr. 23
D-76275 Ettlingen, Germany
---------
Gerald Heinig
Software Engineer
-
phone: + 49 (0) 7243 502 354
fax:+49 (0) 7243 502 364
email: [EMAIL PROTECTED]
http://www.syskonnect.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Ethernet stats in sysctl and SNMP MIBs
Hi all, I'm trying to retrieve Ethernet MIB data from my driver using UCD SNMP and sysctl. For some reason, I can't get any of the info I've put in (I've just set some dummy values for the moment). In particular, I'm trying to get the ISO 8802.3 MIB to display with snmpwalk. I've declared and set the pointer to the struct ifmib_iso_8802_3 in my softc struct and set the structure length. However, neither snmpwalk nor sysctl produces any dot3 MIB data. Is this implemented yet or am I doing something wrong? Cheers, Gerald -- S y s K o n n e c t G m b H A Marvell Company Siemensstr. 23 D-76275 Ettlingen, Germany ----- Gerald Heinig Software Engineer - phone: + 49 (0) 7243 502 354 fax:+49 (0) 7243 502 364 email: [EMAIL PROTECTED] http://www.syskonnect.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel malloc usage
Hi all, I have a question concerning the use of malloc to allocate small amounts of memory for packet wrappers for certain packets. Basically, I'm using malloc in much the same way as one would use it in a standard userland program: allocating small chunks and freeing them again a short(ish) time later. A colleague said this was a bad idea, since malloc should only really be used to allocate larger chunks (PAGE_SIZE and over) at driver initialisation. Management and partition of the allocated space should be done by the driver. His reason was that over time, the kernel heap memory gets progressively more fragmented until it becomes difficult to get larger blocks. Is this true? I seem to remember that FreeBSD has a slab allocator, which IIRC is particularly good at allocating small chunks. Is it a better idea to write my own allocators which use a larger block of memory allocated by malloc at driver start-time, or can I use malloc as in userland? Cheers, Gerald -- S y s K o n n e c t G m b H A Marvell Company Siemensstr. 23 D-76275 Ettlingen, Germany - Gerald Heinig Software Engineer - phone: + 49 (0) 7243 502 354 fax:+49 (0) 7243 502 364 email: [EMAIL PROTECTED] http://www.syskonnect.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel malloc usage
Hi all, I have a question concerning the use of malloc to allocate small amounts of memory for packet wrappers for certain packets. Basically, I'm using malloc in much the same way as one would use it in a standard userland program: allocating small chunks and freeing them again a short(ish) time later. A colleague said this was a bad idea, since malloc should only really be used to allocate larger chunks (PAGE_SIZE and over) at driver initialisation. Management and partition of the allocated space should be done by the driver. His reason was that over time, the kernel heap memory gets progressively more fragmented until it becomes difficult to get larger blocks. Is this true? I seem to remember that FreeBSD has a slab allocator, which IIRC is particularly good at allocating small chunks. Is it a better idea to write my own allocators which use a larger block of memory allocated by malloc at driver start-time, or can I use malloc as in userland? Cheers, Gerald -- S y s K o n n e c t G m b H A Marvell Company Siemensstr. 23 D-76275 Ettlingen, Germany - Gerald Heinig Software Engineer - phone: + 49 (0) 7243 502 354 fax:+49 (0) 7243 502 364 email: [EMAIL PROTECTED] http://www.syskonnect.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Using kernel mod instead of built-in driver
Hi all, I'm currently developing a kernel module for a device for which there is already a driver present in the GENERIC kernel. Is there any other mechanism apart from device.hints by which I can turn off the in-kernel driver and only use my module? It doesn't seem to work with device.hints. Is something like this at all possible? Cheers, Gerald -- S y s K o n n e c t G m b H A Marvell Company Siemensstr. 23 D-76275 Ettlingen, Germany ----- Gerald Heinig Software Engineer - phone: + 49 (0) 7243 502 354 fax:+49 (0) 7243 502 364 email: [EMAIL PROTECTED] http://www.syskonnect.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
