Re: FreeBSD kernel Debugging tools for Virtual Memory Module
Eugene Grosbein eu...@kuzbass.ru writes: First, you need to recompile source you change for sure :-) But you have not rebuild all other files all the time. You need to add to your /etc/src.conf (or /etc/make.conf for 6.x and earlier): MODULES_WITH_WORLD=yes This will skip rebuilding of all modules during 'make buildkernel' but you MUST to copy all modules from /boot/kernel to /boot/modules (all files other than /boot/kernel/kernel*) if you do this. What is the point, if you use NO_KERNELCLEAN as recommended below? The modules won't be rebuilt either unless something that affects them has changed. Running a new kernel with old modules is a great way to shoot yourself in the foot. If you absolutely want to skip modules, build your kernel with -DNO_MODULES, but install it normally, or use reinstallkernel instead of installkernel. The latter will overwrite your running kernel - but you should keep an unmodified kernel around anyway. You can boot entirely without modules if you include everything you need (including acpi) in your kernel config. Then, if you do not change kernel config file, recompile your changes with command (only second time and then): cd /usr/src; make NO_KERNELDEPEND=yes NO_KERNELCLEAN=yes buildkernel You should not use -DNO_KERNELDEPEND unless you know for sure that no #include directives have been added or removed and no kernel options have changed. It is safe to use -DNO_KERNELCLEAN, but not -DNO_KERNELDEPEND, even if your config file changed. Second, you should use some kind of virtual machine (like qemu from ports) to speedup your development cycle even more: install the system into virtual machine and you'll need not another box to debug the kernel and need not rebuild your development box. Test your changes with the system installed into VM and reboot it only. Use ddb or kgdb already noted here. The best solution by far is to use actual hardware and netboot from your development machine. It's easy to set up, and you don't lose context every time you reboot the test system. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD kernel Debugging tools for Virtual Memory Module
ddb and kgdb are two useful and often indispensable tools for kernel debugging on FBSD. ddb won't allow you source level debugging, kgdb will, but you'll need an extra machine. If the code you are debugging doesn't depend on specific hardware, one option is to run FreeBSD (with the kernel being debugged) under qemu and run kgdb on the host FreeBSD. Something like In Window1 $ qemu -s freebsd-disk-img ... In Window2 $ cd where the kernel under test was built $ kgdb kernel.debug (gdb) target remote localhost:1234 do your debugging (gdb) detach Ending remote debugging. (gdb) q $ Note: I have not tried this recently but it should work. AFAIK, if you are modifying the kernel source directly there is no option but to recompile all the changed and dependent files. Well... there used to be a debugger called ups with a builtin C interpreter. It allowed you to add code at run time. This was quite handy when you wanted to temporarily patch things up and continue debugging or set conditional breakpoints or insert assertion verification code on the fly. The C interpreter is worth adding to gdb but I am not sure if any of ups code can be reused. See http://ups.sourceforge.net/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD kernel Debugging tools for Virtual Memory Module
On Thu, Jan 01, 2009 at 06:27:44PM -0800, Kamlesh Patel wrote: I am working on Virtual Memory parts of FreeBSD OS. My Problem is, whenever i modify little code of vmpage.c file i need to build the whole kernel to check the modification and i even am not able to debug the kernel code. Could anyone please inform me kernel Debugging tools for FreeBSD OS? First, you need to recompile source you change for sure :-) But you have not rebuild all other files all the time. You need to add to your /etc/src.conf (or /etc/make.conf for 6.x and earlier): MODULES_WITH_WORLD=yes This will skip rebuilding of all modules during 'make buildkernel' but you MUST to copy all modules from /boot/kernel to /boot/modules (all files other than /boot/kernel/kernel*) if you do this. Otherwise, you'll lose modules and system may not boot due to missing vital modules like acpi.ko Then, if you do not change kernel config file, recompile your changes with command (only second time and then): cd /usr/src; make NO_KERNELDEPEND=yes NO_KERNELCLEAN=yes buildkernel So, your rebuild time changes drastically: no modules rebuild, no other sources rebuild other that you touched last time. It will relink previously compiled object code with your changes only, that's way much quicker. Reinstall kernel and reboot. Second, you should use some kind of virtual machine (like qemu from ports) to speedup your development cycle even more: install the system into virtual machine and you'll need not another box to debug the kernel and need not rebuild your development box. Test your changes with the system installed into VM and reboot it only. Use ddb or kgdb already noted here. Eugene Grosbein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
FreeBSD kernel Debugging tools for Virtual Memory Module
Hi Friends, Happy New Year, I am working on Virtual Memory parts of FreeBSD OS. My Problem is, whenever i modify little code of vmpage.c file i need to build the whole kernel to check the modification and i even am not able to debug the kernel code. Could anyone please inform me kernel Debugging tools for FreeBSD OS? Kamlesh MS CS, CSUS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD kernel Debugging tools for Virtual Memory Module
Hi kamlesh, Happy New Year. I am not aware of the debugging tools in freebsd available right now in the market. But I am working on a virtual mode freebsd project similar to what UML does in linux. This will help in executing the entire OS in the user space of real OS running on HW. This will be the best debugging tool to debug all the non architecture specific code in freebsd. The project is specially catered to problems similar to what you are facing. We are expecting the project to be completed in next 3 months. Regards, Mehul On Fri, Jan 2, 2009 at 7:57 AM, Kamlesh Patel shilp.ka...@yahoo.com wrote: Hi Friends, Happy New Year, I am working on Virtual Memory parts of FreeBSD OS. My Problem is, whenever i modify little code of vmpage.c file i need to build the whole kernel to check the modification and i even am not able to debug the kernel code. Could anyone please inform me kernel Debugging tools for FreeBSD OS? Kamlesh MS CS, CSUS ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD kernel Debugging tools for Virtual Memory Module
On Fri, Jan 2, 2009 at 7:57 AM, Kamlesh Patel shilp.ka...@yahoo.com wrote: Hi Friends, Happy New Year, I am working on Virtual Memory parts of FreeBSD OS. My Problem is, whenever i modify little code of vmpage.c file i need to build the whole kernel to check the modification and i even am not able to debug the kernel code. Could anyone please inform me kernel Debugging tools for FreeBSD OS? Hi, ddb and kgdb are two useful and often indispensable tools for kernel debugging on FBSD. ddb won't allow you source level debugging, kgdb will, but you'll need an extra machine. Dtrace from the Solaris world is being ported to FBSD, that too can be useful at times. You can find more information in the FBSD developers handbook here - http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html AFAIK, if you are modifying the kernel source directly there is no option but to recompile all the changed and dependent files. I do not know whether it works out of the box, but you can try using ccache to speed up the compilation. HTH. Best regards, Pranav http://pranavsbrain.peshwe.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD and Debugging?
In the last episode (Apr 10), Ted Unangst said: On Fri, 9 Apr 2004, Brandon Erhart wrote: Are there any debuggers out there for BSD that will detect the heap/stack corruption!? valgrind and electric fence are very good suggestions. my own personal pet project was adding guard pages to the system malloc. then linking malloc.conf - AFGJ or setenv MALLOC_OPTIONS and you can find bugs in all the software you run. it's less complete than a dedicated heap checker, but lightweight enough (well, 20% penalty may not be light for some) that i run with it full time. we've had a fairly significant amount of success with it finding bugs in software that just happened to work. http://www.zeitbombe.org/patches/malloc_guard.diff should apply pretty cleanly to freebsd's malloc.c I also have a malloc debugging patch that changes the Junk flag to fill with a counter value, so you can track down where in your program a particular block of memory was allocated/freed. http://dan.allantgroup.com/FreeBSD/malloc.diff , or PR 52907 -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
Colin Percival wrote: At 06:11 10/04/2004, Brandon Erhart wrote: Are there any debuggers out there for BSD that will detect the heap/stack corruption!? Real Men use printf(3). :-) You are talking as Linus ;-) rik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
On Fri, Apr 09, 2004 at 10:17:08PM -0700, Lev Walkin wrote: Valgrind is available for FreeBSD. http://eirikn.kerneled.com/valgrind/ Wow!! This is excellent. Is anyone planning to add this to the ports collection? -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
On Saturday 10 April 2004 07:23, Brandon Erhart wrote: Thank you. You are my new god. I had checked out a version of valgrind for BSD (one of the patches) and it failed to compile. Everything seems to be working, except I get this warning at the beginning of the program: Warning: ignoring --pointercheck=yes, because i386_set_ldt failed (errno=45) Sounds like you need options USER_LDT in you kernel. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
On Saturday 10 April 2004 06:17, Lev Walkin wrote: Brandon Erhart wrote: For Linux, I've seen valgrind (probably one of the best) as well as several others. In the commercial arena, Rational's PURIFY and Parasoft's INSURE++ work on every OS *but* BSD. Any particular reason for this? Are there any debuggers out there for BSD that will detect the heap/stack corruption!? Valgrind is available for FreeBSD. http://eirikn.kerneled.com/valgrind/ Or alternatively, a more up-to-date version (which the above is a snapshot of) at http://www.rabson.org/#valgrind. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
On Saturday 10 April 2004 09:13, Craig Rodrigues wrote: On Fri, Apr 09, 2004 at 10:17:08PM -0700, Lev Walkin wrote: Valgrind is available for FreeBSD. http://eirikn.kerneled.com/valgrind/ Wow!! This is excellent. Is anyone planning to add this to the ports collection? It's still in development, see http://www.rabson.org/. A port would be nice though :). Arjan pgp0.pgp Description: signature
Re: FreeBSD and Debugging?
On Fri, 9 Apr 2004, Brandon Erhart wrote: Are there any debuggers out there for BSD that will detect the heap/stack corruption!? [standard disclaimer and note about self-promotion goes here :)] valgrind and electric fence are very good suggestions. my own personal pet project was adding guard pages to the system malloc. then linking malloc.conf - AFGJ or setenv MALLOC_OPTIONS and you can find bugs in all the software you run. it's less complete than a dedicated heap checker, but lightweight enough (well, 20% penalty may not be light for some) that i run with it full time. we've had a fairly significant amount of success with it finding bugs in software that just happened to work. http://www.zeitbombe.org/patches/malloc_guard.diff should apply pretty cleanly to freebsd's malloc.c -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD and Debugging?
Hi, I've been writing an application for some time now, and I seem to have introduced some kind of bug that is smashing the stack or the heap *somewhere*. One of my variables (or more) are being changed, and the program relies on this being set to the last time data was read from a socket. It's getting reset to 0 for some odd, odd reason. But enough of my whining. My code, my problems. What isn't my problem, though, and is probably a lot of people's problem, is the lack of a *good* debugger for BSD. I know gdb is pretty good, and it does help me often, but I can't seem to find a debugger that will detect under/over reads/writes in the heap and/or stack (bounds checking). I had downloaded the bounds checking gcc, it compiled fine, but I get an error that doesn't allow it to run on FreeBSD 4.9 (w/ gcc-2.95.2) -- something about ulimit not being found. I checked Google, and of course, found nothing. I didn't bother enough to look any deeper than that. For Linux, I've seen valgrind (probably one of the best) as well as several others. In the commercial arena, Rational's PURIFY and Parasoft's INSURE++ work on every OS *but* BSD. Any particular reason for this? Are there any debuggers out there for BSD that will detect the heap/stack corruption!? Thanks in advance for you support, Brandon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
At 06:11 10/04/2004, Brandon Erhart wrote: Are there any debuggers out there for BSD that will detect the heap/stack corruption!? Real Men use printf(3). :-) Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
Brandon Erhart wrote: For Linux, I've seen valgrind (probably one of the best) as well as several others. In the commercial arena, Rational's PURIFY and Parasoft's INSURE++ work on every OS *but* BSD. Any particular reason for this? Are there any debuggers out there for BSD that will detect the heap/stack corruption!? Valgrind is available for FreeBSD. http://eirikn.kerneled.com/valgrind/ -- Lev Walkin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
Thank you. You are my new god. I had checked out a version of valgrind for BSD (one of the patches) and it failed to compile. Everything seems to be working, except I get this warning at the beginning of the program: Warning: ignoring --pointercheck=yes, because i386_set_ldt failed (errno=45) Any ideas? Brandon At 11:17 PM 4/9/2004, you wrote: Brandon Erhart wrote: For Linux, I've seen valgrind (probably one of the best) as well as several others. In the commercial arena, Rational's PURIFY and Parasoft's INSURE++ work on every OS *but* BSD. Any particular reason for this? Are there any debuggers out there for BSD that will detect the heap/stack corruption!? Valgrind is available for FreeBSD. http://eirikn.kerneled.com/valgrind/ -- Lev Walkin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
On Fri, Apr 09, 2004 at 11:11:49PM -0600, Brandon Erhart wrote: [...] Are there any debuggers out there for BSD that will detect the heap/stack corruption!? ElectricFence (devel/ElectricFence in the ports collection) detects most kinds of heap corruption, but not stack corruption. It will reliably abort the program on the exact instruction that first corrupts the heap (e.g. overruns a buffer), then you can use gdb on the core dump to analyze it further. After installing the port, run your program with ef.sh. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for FreeBSD kernel debugging help
Hi Everybody, First, thanks to everybody offering tips and help. The good news is that the problem is solved. I couldn't wait, so I finally decided to learn a little FreeBSD kernel debugging. After reading lots of not very comprehensive man pages and other guides, I got a 4.4 kernel compiled with ddb and set up remote debugging over the 2nd serial port with gdb. Again, after reading even more on using gdb, I set a bunch of breakpoints a did a little tracing and got the problem localized to a PCI configuration problem, probably a undocumented hardware bug in the Geode SC1100 processor combined with not very smart PCI config code in FreeBSD. I have patched FreeBSD to boot on the net4801 board, more details after I know exactly what's the issue is. Lesson learned: Advanced FreeBSD documentation sucks if you're not a kernel hacker, but remote kernel debugging works great and are actually kinda fun Regards, Soren Kristensen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for FreeBSD kernel debugging help
On Wed, 11 Jun 2003 18:22, Soren Kristensen wrote: Lesson learned: Advanced FreeBSD documentation sucks if you're not a kernel hacker, but remote kernel debugging works great and are actually kinda fun Procedural things are more likely to be usefully documented in the handbook or FAQ (or The Complete FreeBSD), rather than a specific man page. They can be a bit stale though :( Serial GDB is very nice.. You can even do firewire debugging, but I guess you guys can't really use that :) (Firewire mini-PCI board? 8-) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for FreeBSD kernel debugging help
Daniel O'Connor wrote: Serial GDB is very nice.. You can even do firewire debugging, but I guess you guys can't really use that :) (Firewire mini-PCI board? 8-) Someone should port the network debugging from Darwin using the tiny IP stack from NetBSD. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for FreeBSD kernel debugging help
On Wed, 2003-06-11 at 06:22, Terry Lambert wrote: Someone should port the network debugging from Darwin using the tiny IP stack from NetBSD. Well, there's this: http://ipgdb.sourceforge.net/ IPGDB is a collection of extensions to GDB and FreeBSD-4.3 to allow two-machine kernel debugging over UDP. It behaves much like two-machine kernel debugging over serial ports. These extensions can easily be applied to other releases of FreeBSD. With a little bit of modification, these extension can be applied to other BSD variants. It hasn't been updated in a while, but it's definitely a start. It works pretty well for 4.3, and I know it's been updated to work with 4.6 (though possibly not in the sourceforge distribution). --nat ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for FreeBSD kernel debugging help
On Wed, 11 Jun 2003, Nat Lanza wrote: On Wed, 2003-06-11 at 06:22, Terry Lambert wrote: Someone should port the network debugging from Darwin using the tiny IP stack from NetBSD. Well, there's this: http://ipgdb.sourceforge.net/ IPGDB is a collection of extensions to GDB and FreeBSD-4.3 to allow two-machine kernel debugging over UDP. It behaves much like two-machine kernel debugging over serial ports. These extensions can easily be applied to other releases of FreeBSD. With a little bit of modification, these extension can be applied to other BSD variants. It hasn't been updated in a while, but it's definitely a start. It works pretty well for 4.3, and I know it's been updated to work with 4.6 (though possibly not in the sourceforge distribution). I think that Groggy was working on this a while back. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Looking for FreeBSD kernel debugging help
Hi Everybody, I've been working like a madman on bringing up a new Geode SC1100 based embedded board, but are stalled right now, and need help for debugging with FreeBSD The hardware basically seems to be working just fine, and I can boot both MS-DOS and OpenBSD 2.9 from a CompactFlash. But I can't boot FreeBSD, and need to find out why, and I'm looking for somebody that can help me, as I'm just the hardware guy When booting freeBSD I get: Type '?' for a list of commands, 'help' for more detailed help. ok boot -v Copyright (c) 1992-2001 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 4.4-RELEASE #1: Sun Jun 8 19:08:24 PDT 2003 [EMAIL PROTECTED]:/usr/src/sys/compile/KERN_NSC Calibrating clock(s) ... TSC clock: 27486 Hz, i8254 clock: 1193267 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Cyrix GXm (266.65-MHz 586-class CPU) Origin = CyrixInstead Id = 0x540 DIR=0x81b7 Stepping=8 Revision=1 real memory = 134217728 (131072K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x003c1000 - 0x07ff7fff, 130248704 bytes (31799 pages) avail memory = 126984192 (124008K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f0080 bios32: Entry = 0xf00c0 (c00f00c0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xe1 Other BIOS signatures found: ACPI: Preloaded elf kernel kernel at 0xc039b000. md0: Malloc disk Creating DISK md0 Math emulator present pci_open(1):mode 1 addr port (0x0cf8) is 0x800090d0 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=00011078) And there it just hangs forever Normally it would continue with: npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard . . . So it looks like it hangs between first PCI check probe and printing the NPX info. The question is, what hardware specific could there be that could hang ? It's probably PCI config or floating point related, I tried to follow the source, but couldn't really Some additional info: The PCI bus seems fine, I can netboot, but it then hangs the same place. Same with a 4.2-release and 4.8-release. Same with and without NSC VSA extension. Same with GENERIC kernel. I did some search on the net, and all info indicated that a stock FreeBSD should work, although a patch for the TSC counter is needed for optimal performance and a patch if you use the Video (which the SC1100 don't have). I have tried every single register in the SC1100 chip (And there are tons of them...) I also tried changed the chip ID from Geode by NSC to CyrixInstead, but that just resulted in FreeBSD recognizing the CPU and providing a little better CPU information. More info on the hardware at: http://www.soekris.com/net4801.htm So I need: All qualified help pinpointing the problem. Or a kernel hacker that can come by Morgan Hill, CA and debug the FreeBSD kernel telling me exactly where and why it hangs. Once I know that, it's usually easy to fix. I'm prepared to pay for solving the problem, cash and/or net4801 hardware Regards, Soren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
