Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010
> Masanori OZAWA wrote:
> [...]
>
> Nice work! This is just a "works for me". In only find some issues with
> permissions that were already present in the previous implementation of
> unionfs. Some of them are partially corrected in the "useful" copymode.
> I mailed the details to the author.
the following will hang the kernel:
root is mounted nfs,
/etc is unionfs'ed so:
from /etc/rc.initdiskless:
...
# Create a generic memory disk
#
mount_md() {
/sbin/mdmfs -i 4096 -s $1 -M md $2
}
kldload unionfs
mount_md 4096 /.etc
mount_unionfs /.etc /etc
...
and now:
cd /etc
mv some-file somefile
and now the system is stuck.
this behaviour is also present in the unpatched unionfs, but would be nice
if it can be fixed.
danny
ps: see http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84107
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Deadlock FreeBSD 6 / 7
> >>>Use prime95 (ports/math/mprime) to test your processor and thermal > >>>stability (36 hours or so), and memtest86 (seperately). Please use memtest86+ and not memtest86. -- unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; fsck ; umount ; sleep ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Compiling kernel/modules without INET?
Howdy, One of my new years resolutions was to become a bit more masochistic, so I set out to see if I could build a kernel (and modules) without "options INET" on HEAD. This works flawlessly for the kernel part, but there are tons of issues when building modules -- various problems encountered during "make depend" and "make". So far there appear to be four different classes of errors: 1) Failures during "make depend" due to #error directives hit when INET is not defined. 2) #includes which are always needed but are only pulled in (implicitly) when INET is defined 3) Small blocks of code (variable declarations and tests) which are not wrapped with #ifdef INET (or other #defines), or simply wrapped with the wrong #ifdef 4) Larger messes such as GRE's hard-coded dependence on INET; SLIP/PPP's dependence on packet compress code, etc. I have what I think are valid fixes for the first 3 issues, but I know I'm just making a mess of things to resolve the last issue. Before I spit and polish these patches for public consumption, I want to know if this is even a worthy project. I know there are benefits simply because we should "do the right thing", but I'm sure I'm wading into murky waters. Any guidance would be appreciated. Regards, -- Matt Emmerton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Deadlock FreeBSD 6 / 7
On Sun, 1 Jan 2006, Armin Pirkovitsch wrote: Robert Watson wrote: I guess one of those parts creates the trouble, but I have no idea how to trace it... Is there a way to run the whole thing in some kind of debugger? Or is there a diffrent way to locate the problem? The usual first step to debug a deadlock, if WITNESS or INVARIANTS doesn't trigger dropping you into the debugger, is to break into the debugger using a console or serial break. To do this, you need to compile: I added options BREAK_TO_DEBUGGER and used make buildkernel and make installkernel.debug and was not able to reconstruct the crash. I guess the debug stuff slowed it down enough to not come to the bug... (even installworld worked fine, which usually kills it) So this is what I feared - the debug stuff changes the timing by slowing it down which makes it pretty hard to reconstruct the crash... Is there any other way? (btw. it's a notebook, so there is no old serial bus) Try compiling in only options DDB and BREAK_TO_DEBUGGER. Even without the fully debugging features on, it may be enough to give us some initial insight into the source of the problem. Does your notebook have firewire support? Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Deadlock FreeBSD 6 / 7
Robert Watson wrote: On Sat, 31 Dec 2005, Armin Pirkovitsch wrote: I have some troubles with my notebook and any version of FreeBSD (starting with 6 since my sata controller wasn't supported earlier). It looks like as it would end up in a deadlock which means i have no access to the debugger nor to any other kind of tracing methods. Even with KTR, WITTNESS and DIAGNOSTIC enabled in the kerenl I get no message what went wrong or what might have caused the trouble. These fullstops always turn up when i compile and install programs (or sometimes during the installation of FreeBSD itself) Hardware: Intel Pentium-M 760 (Centrino, 2GHz) VIA VT 6421 SATA Controller 80GB Samsung SATA HD I guess one of those parts creates the trouble, but I have no idea how to trace it... Is there a way to run the whole thing in some kind of debugger? Or is there a diffrent way to locate the problem? The usual first step to debug a deadlock, if WITNESS or INVARIANTS doesn't trigger dropping you into the debugger, is to break into the debugger using a console or serial break. To do this, you need to compile: options BREAK_TO_DEBUGGER options DDB into your kernel. On syscons (not in X11), you can hit Ctrl-Alt-Escape to try to get to the debugger, or send a serial break. The serial break is often more reliable, and the nice thing about running DDB on a serial console from a second machine is that you can easily copy/paste debug output. Once you're in the debugger, you can list the threads, locks held, trace stacks, and so on. If you can't get into the debugger using a serial break, then usually the next thing you have to try is using an NMI. Unfortunately, most hardware doesn't ship with an NMI button, although some server hardware vendors now provide them. In the vast majority of cases, a serial break will get to the debugger, and in many cases, so will a console break. I added options BREAK_TO_DEBUGGER and used make buildkernel and make installkernel.debug and was not able to reconstruct the crash. I guess the debug stuff slowed it down enough to not come to the bug... (even installworld worked fine, which usually kills it) So this is what I feared - the debug stuff changes the timing by slowing it down which makes it pretty hard to reconstruct the crash... Is there any other way? (btw. it's a notebook, so there is no old serial bus) -- Armin Pirkovitsch [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Deadlock FreeBSD 6 / 7
Martin Cracauer wrote: It's more likely to be a general instability from broken hardware. Use prime95 (ports/math/mprime) to test your processor and thermal stability (36 hours or so), and memtest86 (seperately). I guess I should have mentioned that other systems work fine and run stable (and memtest returns no errors) (Linux was up several days compiling stuff like OO etc) Still, we have seen that several times before, machine stable in Linux, not in FreeBSD and vice versa. Using prime95/mprime ist the best way to ensure this. Run it for 36 hours in the torture test mode. 10 hours returned no error nor a warning (I'm pretty impatient...) -- Armin Pirkovitsch [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Deadlock FreeBSD 6 / 7
On Sat, 31 Dec 2005, Armin Pirkovitsch wrote: I have some troubles with my notebook and any version of FreeBSD (starting with 6 since my sata controller wasn't supported earlier). It looks like as it would end up in a deadlock which means i have no access to the debugger nor to any other kind of tracing methods. Even with KTR, WITTNESS and DIAGNOSTIC enabled in the kerenl I get no message what went wrong or what might have caused the trouble. These fullstops always turn up when i compile and install programs (or sometimes during the installation of FreeBSD itself) Hardware: Intel Pentium-M 760 (Centrino, 2GHz) VIA VT 6421 SATA Controller 80GB Samsung SATA HD I guess one of those parts creates the trouble, but I have no idea how to trace it... Is there a way to run the whole thing in some kind of debugger? Or is there a diffrent way to locate the problem? The usual first step to debug a deadlock, if WITNESS or INVARIANTS doesn't trigger dropping you into the debugger, is to break into the debugger using a console or serial break. To do this, you need to compile: options BREAK_TO_DEBUGGER options DDB into your kernel. On syscons (not in X11), you can hit Ctrl-Alt-Escape to try to get to the debugger, or send a serial break. The serial break is often more reliable, and the nice thing about running DDB on a serial console from a second machine is that you can easily copy/paste debug output. Once you're in the debugger, you can list the threads, locks held, trace stacks, and so on. If you can't get into the debugger using a serial break, then usually the next thing you have to try is using an NMI. Unfortunately, most hardware doesn't ship with an NMI button, although some server hardware vendors now provide them. In the vast majority of cases, a serial break will get to the debugger, and in many cases, so will a console break. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem about libnet on FreeBSD 6.0
[EMAIL PROTECTED] wrote: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2005-December/014986.html > > The problem is that libnet defines ether_addr without regard for the fact > that it's defined in our system headers. This is a bug in libnet, not > FreeBSD. No one claimed otherwise -- hence the 'BROKEN_LIBNET' tag in my post. > In particular, libnet/libnet-headers.h has this code, which is very > Linux-centric and works around the duplicate definition problem on Linux, > but doesn't help anyone on other platforms. > > 391 #if (!__GLIBC__) This is typical for libnet, and it has run into compatibility problems of this sort in the past on systems other than freebsd. Search for "edelkind libnet" or "redefinition libnet" on google for some of these. ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
