Re: Promise/ATA-Raid making panic in -CURRENT?
Here's the box: Asus CUV4X-D mainboard, VIA 694X, dual-capable 2x P3-933, 768MB PC133 RAM in 3 DIMM(s) Two IBM IC35L 60.1GB disks on first IDE Pioneer DVD-A05SZ on second IDE Two IBM IC35L 60.1GB on Promise Fasttrak TX2 (PDC20268/70) in RAID0 How do I dump the dmesg when it crashs into the debugger? With a current kernel from before you found it failed ? No, first time I compiled a -CURRENT. I finally pulled the Promise out and it boots. Since I need it for some Windows apps on the same box I put it back in and commented some lines in ata driver regarding the detection of Promise Fasttrak controllers and it boots now w/o detecting it. The -CURRENT kernel runs fine so far. /tso __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise/ATA-Raid making panic in -CURRENT?
It seems Tom Servo wrote: I finally pulled the Promise out and it boots. Since I need it for some Windows apps on the same box I put it back in and commented some lines in ata driver regarding the detection of Promise Fasttrak controllers and it boots now w/o detecting it. This is strange, the error message you got is *not* from the ATA driver, and putting a TX2 in a system here work just fine, I'm out of ideas -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: time breakage.
On Fri, 8 Feb 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: phk, is this you? /usr/include/sys/time.h:137: integer constant out of range /usr/include/sys/time.h:137: warning: decimal integer constant is so large that it is unsigned Yes, that was me, seems like I did my buildworld test in the wrong source tree here. Thanks to peter for fixing this, and sorry for the trouble! not out of the woods yet... I'm not sure but make world still breaks for me with: off/new.cc -o new.o In file included from /usr/include/sys/stat.h:50, from /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/include/posix.h:22, from /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/new.cc:24: /usr/include/sys/time.h: In function `void timespec2bintime(timespec *, bintime *)': /usr/include/sys/time.h:137: integer constant out of range /usr/include/sys/time.h:137: warning: decimal integer constant is so large that it is unsigned /usr/include/sys/time.h: In function `void timeval2bintime(timeval *, bintime *)': /usr/include/sys/time.h:153: integer constant out of range /usr/include/sys/time.h:153: warning: decimal integer constant is so large that it is unsigned *** Error code 1 I'm doing a make includes and will try again as it could be that it is erroneously looking in /usr/include instead of at the sources. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise/ATA-Raid making panic in -CURRENT?
I finally pulled the Promise out and it boots. Since I need it for some Windows apps on the same box I put it back in and commented some lines in ata driver regarding the detection of Promise Fasttrak controllers and it boots now w/o detecting it. This is strange, the error message you got is *not* from the ATA driver, and putting a TX2 in a system here work just fine, I'm out of ideas Well, maybe some other system/PCI code has been changed and doesn't work so well with the detection code in ata-raid.c? This would be my first guess, but I am no big programmer and I'm even less aware how it kernel internas work. To be exact, I commented stuff in ata-raid.c, ata-dma.c and ata-pci.c (everything related to device ID 0x4d68105a). And I made ar_probe to return 1 immediately. Like this I can leave the Promise in w/o getting that error. It happens on GENERIC and the configured kernel. PS booting verbose doesn't throw any usable info at all. PS2 my TX2 has BIOS 2.00 build 2 located in PCI slot 5. The mobo chipset is a VIA 694XDP. I hope this info helps. /tso __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ucred for threads
On Thu, 7 Feb 2002, Julian Elischer wrote:
As part of the KSe stuff I ended up changing ht ebehaviour of threads with
respect to their ucreds. Previously, they freed their ucred reference when
they entered user space and picked them up again when they re-entered the
kernel. It there was an AST then they re-loaded teh already freed ucred to
perform the AST. (and then freed it again, (For each AST).
Since each 'get' and free required a lock and unlock of the proc
structure, this meant that there were at least 2 locks and 2 unlocks, and
possibly many more, for the average kernel entry/exit pair.
The 2 locks and 2 unlocks pessimized syscall overhead by 10-20%.
Since the chance that the ucred on the next entry is not the same as the
thread already had on it's last kernel exit, is almiost negligible,
it makes sence to hold the ucred acress the user period an dsimply check
it agains the process's ucred on th enext entry.
In the KSE code I have:
in trap(), and syscall()
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
td-td_ucred = NULL;
}
if (p-p_ucred != NULL) {
td-td_ucred = crhold(p-p_ucred);
}
PROC_UNLOCK(p);
}
I deleted too much of the followup to this, so I can't quote it.
Races here could be reduced by putting some sort of synchronization
instruction at the beginning. Then there would only be a race between
executing the sync instruction and checking p_ucred. The race window
could be very large if the process is preempted in between. But this
race is obviously unavoidable in the current framework. You may end
up with a slightly stale td_ucred, but this is insignificantly different
from ending up with a slightly stale td_ucred when p_ucred changes
just after you release the lock. Both can have almost any amount of
staleness if processes can be preempted...
Without the sync instruction, the race starts a little earlier, in
userland. It's not so obvious that the effects of this race are not
really different from the the effects of p_ucred changing after you
release the lock, but I think they are. Terry argued this point from
a different viewpoint.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: time breakage.
for what it's worth, doing a make includes before the make buildworld seems to have got me going again. On Fri, 8 Feb 2002, Julian Elischer wrote: On Fri, 8 Feb 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: phk, is this you? /usr/include/sys/time.h:137: integer constant out of range /usr/include/sys/time.h:137: warning: decimal integer constant is so large that it is unsigned Yes, that was me, seems like I did my buildworld test in the wrong source tree here. Thanks to peter for fixing this, and sorry for the trouble! not out of the woods yet... I'm not sure but make world still breaks for me with: off/new.cc -o new.o In file included from /usr/include/sys/stat.h:50, from /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/include/posix.h:22, from /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/new.cc:24: /usr/include/sys/time.h: In function `void timespec2bintime(timespec *, bintime *)': /usr/include/sys/time.h:137: integer constant out of range /usr/include/sys/time.h:137: warning: decimal integer constant is so large that it is unsigned /usr/include/sys/time.h: In function `void timeval2bintime(timeval *, bintime *)': /usr/include/sys/time.h:153: integer constant out of range /usr/include/sys/time.h:153: warning: decimal integer constant is so large that it is unsigned *** Error code 1 I'm doing a make includes and will try again as it could be that it is erroneously looking in /usr/include instead of at the sources. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Binutils fixed in -current?
On Wed, Feb 06, 2002 at 12:35:39PM -0800, Alfred Perlstein wrote: * David W. Chapman Jr. [EMAIL PROTECTED] [020206 12:33] wrote: Does anyone know if the problem with kde and other programs not working with the new binutils not working have been fixed yet? I find that mozilla 0.9.8 dies with pure virtual called or something to that effect, however I don't have a super recent world, I'm compiling one now and will let you know if it at least fixes that for me. FYI, I also get this on 4.5-STABLE. Bye, Andrea -- To boldly go where I surely don't belong. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MODULES_WITH_WORLD=true means no modules?
BOUWSMA Beery [EMAIL PROTECTED] writes: In order to get /boot/kernel/ populated with modules, either one needs to installworld again, or use one of the targets to install only modules, I guess. The recommended build sequence is: # make buildworld # make buildkernel # make installkernel # make installworld DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Binutils fixed in -current?
* Andrea Campi [EMAIL PROTECTED] [020208 03:51] wrote: On Wed, Feb 06, 2002 at 12:35:39PM -0800, Alfred Perlstein wrote: * David W. Chapman Jr. [EMAIL PROTECTED] [020206 12:33] wrote: Does anyone know if the problem with kde and other programs not working with the new binutils not working have been fixed yet? I find that mozilla 0.9.8 dies with pure virtual called or something to that effect, however I don't have a super recent world, I'm compiling one now and will let you know if it at least fixes that for me. FYI, I also get this on 4.5-STABLE. If you do a pkg_deletew of mozilla and then nuke /usr/X11R6/lib/mozilla then reinstall it the problem should go away. -- -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.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Binutils fixed in -current?
Alfred Perlstein wrote: If you do a pkg_deletew of mozilla and then nuke /usr/X11R6/lib/mozilla then reinstall it the problem should go away. pgk_deelete is broken?!? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ucred for threads
On 08-Feb-02 Terry Lambert wrote: John Baldwin wrote: No, an unlocked compare is _not_ ok. What if the p_ucred pointer was changed on some other processor by another thread from this processor? I saw your response to Julian... I understand the concern, but I think it's unfounded. Let me explain. Yes, it's an acceptable race to lose as you say. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /dev/rtc not configured message when starting VMWare2 on-current
From: Georg-W Koltermann [EMAIL PROTECTED]
Date: Thu, 07 Feb 2002 11:04:22 +0100
::Hi,
::
::since many weeks I get /dev/rtc: device not configured in -current
::when I start VMWare2. The VMWare2 port works fine otherwise.
::
::Yes, rtc-2001.09.16.1 is installed, and the module is loaded during
::startup.
Hi,
I have a hack^Wpatch that should fix your problem.
Hope this helps,
Haro
=--
_ _Munehiro (haro) Matsuda
-|- /_\ |_|_| Business Incubation Dept., Kubota Corp.
/|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome
Chuo-ku Tokyo 103-8310, Japan
Tel: +81-3-3245-3318 Fax: +81-3-3245-3315
Email: [EMAIL PROTECTED]
--- ports/emulators/rtc/files/rtc.c.ctm Tue Dec 11 02:20:24 2001
+++ ports/emulators/rtc/files/rtc.c Sat Feb 9 00:23:10 2002
@@ -266,9 +266,30 @@
{
int error;
+#if __FreeBSD_version = 500023
+dev_t dev;
+struct rtc_softc *sc;
+
+ if (rtc_sc!=NULL)
+ return (EINVAL);
+
+ dev = make_dev(rtc_cdevsw, 0, UID_ROOT, GID_WHEEL, 0644, DEVICE_NAME);
+ if (dev==NULL)
+ return (EINVAL);
+
+ MALLOC(sc, struct rtc_softc*, sizeof(*sc), M_DEVBUF, M_WAITOK);
+ if (sc==NULL)
+ return (EINVAL);
+
+ bzero(sc, sizeof(*sc));
+ rtc_sc = sc;
+ dev-si_drv1 = sc; /* Link together */
+ sc-dev = dev;
+#else
error = cdevsw_add(rtc_cdevsw);
if (error)
return error;
+#endif
return error;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Binutils fixed in -current?
* Terry Lambert [EMAIL PROTECTED] [020208 07:12] wrote: Alfred Perlstein wrote: If you do a pkg_deletew of mozilla and then nuke /usr/X11R6/lib/mozilla then reinstall it the problem should go away. pgk_deelete is broken?!? I think what happens is people like me sometimes just install a new package over the old instead of properly deinstalling first. I think what's actually happening is that files from 0.9.6 are getting picked up by 0.9.8 because 0.9.7 spammed 0.9.6's plist. Just a guess though. :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Binutils fixed in -current?
Alfred Perlstein wrote: I think what happens is people like me sometimes just install a new package over the old instead of properly deinstalling first. I think what's actually happening is that files from 0.9.6 are getting picked up by 0.9.8 because 0.9.7 spammed 0.9.6's plist. That should force a deinstall of everything but data files as part of the install, anyway, right? Good to know it's pilot error, and that the tools aren't a problem (except maybe the install-over ;^)). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Hang on flushing buffers w/today's -CURRENT, SMP system
OK; I got today's -CURRENT built running on each of my build machine (freebeast) my laptop. (Got today's -STABLE built earlier; I mention this as a reference point/comparison. I similarly note that I've been tracking each daily on each machine for several months, and that today is the first time I've seen this problem.) Anyway, the laptop seems fairly normal: I got -CURRENT built, booted it up, ran a few things, used boot0cfg to switch to the slice with today's -STABLE, and it came right down (gracefully) and back up again: g1-7(4.5-S)[1] uname -a FreeBSD g1-7.catwhisker.org 4.5-STABLE FreeBSD 4.5-STABLE #74: Fri Feb 8 05:58:01 PST 2002 [EMAIL PROTECTED]:/common/S1/obj/usr/src/sys/LAPTOP_30W i386 g1-7(4.5-S)[2] But on the build machine, I got it running -CURRENT, then did the same procedure (boot0cfg reboot), but on the (serial) console, I see: Feb 8 08:45:32 freebeast mountd[181]: bad exports list line /cdrom-ro -alldirs apache cvsupd . Additional TCP options:. Starting background filesystem checks Fri Feb 8 08:45:34 PST 2002 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: boot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 15 15 ...and it's been sitting like that for about half an hour. This is the second time I've tried this with today's -CURRENT on the box; the first time, it hung at syncing disks... 7 7 -- and I finally hit the reset button. (I don't have a keyboard on the machine, though I suppose I could try putting one on. Getting a (PC) monitor would be a little harder, though, since the only one we have is on my spouse's M$ machine, and the only spare monitor I have is a Sun-badged Sony for the SPARCstation. One other thing: the machine is pingable: bunrab(4.5-S)[1] ping freebeast PING freebeast.catwhisker.org (172.16.8.10): 56 data bytes 64 bytes from 172.16.8.10: icmp_seq=0 ttl=64 time=0.398 ms 64 bytes from 172.16.8.10: icmp_seq=1 ttl=64 time=0.189 ms ^C --- freebeast.catwhisker.org ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.189/0.293/0.398/0.105 ms bunrab(4.5-S)[2] So I'd guess that while things that require process creation are unlikely to succeed, the network is still capable of (primitive) functioning. I don't run much fancy stuff on the build machine -- Apache (so I can easily use cvsweb locally); cvsupd (for internal use); sshd (so I can login to the machine); that's about it. Is there a way to force the debugger from the serial console? About the only salient difference between the two machines that occurs to me is that the laptop has a single CPU (750 MHz PIII), while the build machine has a pair of them (2x866 MHz PIII). It's not a serious problem (in and of itself) for me at this time, but it certainly appears broken, so I'd like to help fix it. (I've reduced the list of likely candidate files that contributed to this down to 71 via a quick, casual inspection. I don't want to spam the list any worse than I already have, though) Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: bremfree related panic
On Thu, 7 Feb 2002, John Baldwin wrote: IdlePTD at phsyical address 0x003d1000 initial pcb at physical address 0x00329bc0 panicstr: bremfree: bp 0xc2161734 not locked panic messages: --- panic: msleep Hmmm, wonder where that came from. oh: KASSERT(ident != NULL td-td_proc-p_stat == SRUN, (msleep)); However, your trace shows some other type of panic, one not in msleep but from a fatal kernel trap. As a data point, i can cause bremfree panics with ddb's panic function too. There is some wart in the panic handling that triggers the bremfree one, or the strings are screwed up :) Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
can you try a kernel from JUST BEFORE I did the KSE commit yesterday? I heard someone else complain of thisyesterday afternoon. At that time I wascertain it was too soon after my commit for him to already have got it, but it would be nice tio know if I screwed something... On Fri, 8 Feb 2002, David Wolfskill wrote: OK; I got today's -CURRENT built running on each of my build machine (freebeast) my laptop. (Got today's -STABLE built earlier; I mention this as a reference point/comparison. I similarly note that I've been tracking each daily on each machine for several months, and that today is the first time I've seen this problem.) Anyway, the laptop seems fairly normal: I got -CURRENT built, booted it up, ran a few things, used boot0cfg to switch to the slice with today's -STABLE, and it came right down (gracefully) and back up again: g1-7(4.5-S)[1] uname -a FreeBSD g1-7.catwhisker.org 4.5-STABLE FreeBSD 4.5-STABLE #74: Fri Feb 8 05:58:01 PST 2002 [EMAIL PROTECTED]:/common/S1/obj/usr/src/sys/LAPTOP_30W i386 g1-7(4.5-S)[2] But on the build machine, I got it running -CURRENT, then did the same procedure (boot0cfg reboot), but on the (serial) console, I see: Feb 8 08:45:32 freebeast mountd[181]: bad exports list line /cdrom-ro -alldirs apache cvsupd . Additional TCP options:. Starting background filesystem checks Fri Feb 8 08:45:34 PST 2002 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: boot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 15 15 ...and it's been sitting like that for about half an hour. This is the second time I've tried this with today's -CURRENT on the box; the first time, it hung at syncing disks... 7 7 -- and I finally hit the reset button. (I don't have a keyboard on the machine, though I suppose I could try putting one on. Getting a (PC) monitor would be a little harder, though, since the only one we have is on my spouse's M$ machine, and the only spare monitor I have is a Sun-badged Sony for the SPARCstation. One other thing: the machine is pingable: bunrab(4.5-S)[1] ping freebeast PING freebeast.catwhisker.org (172.16.8.10): 56 data bytes 64 bytes from 172.16.8.10: icmp_seq=0 ttl=64 time=0.398 ms 64 bytes from 172.16.8.10: icmp_seq=1 ttl=64 time=0.189 ms ^C --- freebeast.catwhisker.org ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.189/0.293/0.398/0.105 ms bunrab(4.5-S)[2] So I'd guess that while things that require process creation are unlikely to succeed, the network is still capable of (primitive) functioning. I don't run much fancy stuff on the build machine -- Apache (so I can easily use cvsweb locally); cvsupd (for internal use); sshd (so I can login to the machine); that's about it. Is there a way to force the debugger from the serial console? About the only salient difference between the two machines that occurs to me is that the laptop has a single CPU (750 MHz PIII), while the build machine has a pair of them (2x866 MHz PIII). It's not a serious problem (in and of itself) for me at this time, but it certainly appears broken, so I'd like to help fix it. (I've reduced the list of likely candidate files that contributed to this down to 71 via a quick, casual inspection. I don't want to spam the list any worse than I already have, though) Thanks, david -- David H. Wolfskill[EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
reboot and sync behaviour.
This succeeded, but looks suspicious to me. syncing disks... 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 I've never seen it like that before.. It might be related to the problem some have seen with syncing.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Binutils fixed in -current?
On 2002-02-08 06:57, Alfred Perlstein wrote:
* Andrea Campi [EMAIL PROTECTED] [020208 03:51] wrote:
On Wed, Feb 06, 2002 at 12:35:39PM -0800, Alfred Perlstein wrote:
* David W. Chapman Jr. [EMAIL PROTECTED] [020206 12:33] wrote:
Does anyone know if the problem with kde and other programs not
working with the new binutils not working have been fixed yet?
I find that mozilla 0.9.8 dies with pure virtual called or something
to that effect, however I don't have a super recent world, I'm compiling
one now and will let you know if it at least fixes that for me.
FYI, I also get this on 4.5-STABLE.
If you do a pkg_deletew of mozilla and then nuke /usr/X11R6/lib/mozilla
then reinstall it the problem should go away.
Just my $0.02:
A reinstall of the port fixed the problems I was having with the
www/linux-netscape47-communicator port after a buildworld at Jan 7.
Probably unrelated to the mozilla problems, but I thought I'd mention in
case someone else sees netscape start, and dump core before even displaying
the main window in X11.
--
Giorgos Keramidas . . . . . . . . . keramida@{ceid.upatras.gr,freebsd.org}
FreeBSD Documentation Project . . . http://www.freebsd.org/docproj/
FreeBSD: The power to serve . . . . http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
cred stuff..
I'd like to commit the code to keep the ucred across userland,
with the code to clear it to NULL kept under DEBUG ifdefs.
i.e.
in trap(), ast() and syscall()
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
td-td_ucred = NULL;
}
if (p-p_ucred != NULL) {
td-td_ucred = crhold(p-p_ucred);
}
PROC_UNLOCK(p);
}
and in userret() and ast()
#ifdef DEBUG /*your choice of variable here*/
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
td-td_ucred = NULL;
}
PROC_UNLOCK(p);
#endif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
Date: Fri, 8 Feb 2002 10:54:55 -0800 (PST) From: Julian Elischer [EMAIL PROTECTED] can you try a kernel from JUST BEFORE I did the KSE commit yesterday? OK; results below I heard someone else complain of thisyesterday afternoon. At that time I wascertain it was too soon after my commit for him to already have got it, but it would be nice tio know if I screwed something... Date: Fri, 8 Feb 2002 11:29:51 -0800 (PST) From: Julian Elischer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: reboot and sync behaviour. This succeeded, but looks suspicious to me. syncing disks... 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 I've never seen it like that before.. It might be related to the problem some have seen with syncing.. I was able to build a kernel from just prior to the Pre-KSE/M3 commit (http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1278231+0+current/cvs-all); it did not exhibit the problem. I then updated the sources to just after that commit, booted, then on the reboot (while running this new kernel), I get the hang again: Additional TCP options:. Starting background filesystem checks Fri Feb 8 13:22:59 PST 2002 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: boot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 7 7 So, yes, Julian, I think there's something not quite right there. How can I help debug this? Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
acpi and device.hints
Is it possible to make devices enumerated by acpi to take notice of the flags given to them in device.hints? for example if I allow acpi then I get: sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A despite the fact that I have in device.hints: hint.sio.1.at=isa hint.sio.1.port=0x2F8 hint.sio.1.irq=3 hint.sio.1.flags=0xc0 which should reserve the port for gdb. My answer is to simply do mv /boot/kernel/acpi.ko /boot/kernel/xacpi.ko but it's be nice to have both the gdb AND the acpi abilities. regards, Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On Fri, 8 Feb 2002, David Wolfskill wrote: FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: boot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 7 7 can you hit CTLALTESC and get into the debugger? So, yes, Julian, I think there's something not quite right there. How can I help debug this? First I'm going over the diff to look for anything suspicious.. I didn't think I had changed any locking To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, David Wolfskill wrote: Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 7 7 can you hit CTLALTESC and get into the debugger? My box shows the same symptom, and yes I can enter DDB. How may I help? Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, David Wolfskill wrote: Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 7 7 can you hit CTLALTESC and get into the debugger? My box shows the same symptom, and yes I can enter DDB. How may I help? Eugene show locks whould be good. also 'ps' and the stack trace of the process doing the sync... tr PID if you can get a serial console that would be best of course. you may wait a while to see if dave can get into ddb on his serial console. that may save you a lot of writing :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ucred for threads
On Fri, 8 Feb 2002, Bruce Evans wrote:
[...]
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
td-td_ucred = NULL;
}
if (p-p_ucred != NULL) {
td-td_ucred = crhold(p-p_ucred);
}
PROC_UNLOCK(p);
}
I deleted too much of the followup to this, so I can't quote it.
Races here could be reduced by putting some sort of synchronization
instruction at the beginning. Then there would only be a race between
executing the sync instruction and checking p_ucred. The race window
could be very large if the process is preempted in between. But this
race is obviously unavoidable in the current framework. You may end
up with a slightly stale td_ucred, but this is insignificantly different
from ending up with a slightly stale td_ucred when p_ucred changes
just after you release the lock. Both can have almost any amount of
staleness if processes can be preempted...
Without the sync instruction, the race starts a little earlier, in
userland. It's not so obvious that the effects of this race are not
really different from the the effects of p_ucred changing after you
release the lock, but I think they are. Terry argued this point from
a different viewpoint.
That's my point. There is already an unavoidable (by us here) race on the
macro level between two threads of the same process. The micro race
introduced here is irrelevant in comparison, and if you solve the macro
race, the micro one is solved for free, so it's pointless trying to
protect against it here.
John would like to clear the ucred while the thread is in user space
just as a debug aid to help catch any bad uses (I guess during fast
interrupts or something), but that reason asside there is no reason to
do so, and a good reason to keep the ucreds.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
Attached is the requested DDB log (I guessed pid 7 `syncer' is the process doing the sync; if this is wrong let me know). Eugene PS. I used the serial console, so don't feel sorry to ask. =) On Fri, Feb 08, 2002 at 02:41:30PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, David Wolfskill wrote: Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 7 7 can you hit CTLALTESC and get into the debugger? My box shows the same symptom, and yes I can enter DDB. How may I help? Eugene show locks whould be good. also 'ps' and the stack trace of the process doing the sync... tr PID if you can get a serial console that would be best of course. you may wait a while to see if dave can get into ddb on his serial console. that may save you a lot of writing :-) syncing disks... 4 4 Debugger(manual escape to debugger) Stopped at Debugger+0x41: xorl%eax,%eax db show locks exclusive (sleep mutex) Giant (0xc02e6100) locked @ /usr/src/sys/kern/kern_intr.c:532 db ps pid proc addruid ppid pgrp flag stat wmesg wchan cmd 192 cc989300 cdbc50000 0 0 204 3 nfsidl c1d0538c nfsiod 3 191 cc989600 cdbc10000 0 0 204 3 nfsidl c1d05388 nfsiod 2 190 cc989900 cdbbd0000 0 0 204 3 nfsidl c1d05384 nfsiod 1 189 cc989c00 cdbb90000 0 0 204 3 nfsidl c1d05380 nfsiod 0 9 cc98c000 cd1af0000 0 0 204 3 pccbbev c1b39400 pccbb1 8 cc98c300 cd1ab0000 0 0 204 3 pccbbev c1b39800 pccbb0 7 cc98c600 cd1a70000 0 0 204 3 ktsusp cc98c800 syncer 6 cc98c900 cd1a30000 0 0 204 3 ktsusp cc98cb00 vnlru 5 cc98cc00 cd19f0000 0 0 204 3 ktsusp cc98ce00 bufdaemon 4 cc98cf00 cd19b0000 0 0 204 3 pgzero c0327fc8 pagezero 3 cc98d200 cd1970000 0 0 204 3 psleep c0327fdc vmdaemon 2 cc98d500 cd1930000 0 0 204 3 psleep c02e06d8 pagedaemon 31 cc98d800 cc9920000 0 0 204 6 irq8: rtc 30 cc98db00 cc98e0000 0 0 204 6 irq0: clk 29 cc320f00 cc9850000 0 0 204 6 irq4: sio0 28 cc321200 cc9810000 0 0 204 6 swi0: tty:sio 27 cc321500 cc97d0000 0 0 204 6 irq7: ppc0 26 cc321800 cc9790000 0 0 204 6 irq12: psm0 25 cc321b00 cc9750000 0 0 204 2 irq1: atkbd0 24 cc321e00 cc9710000 0 0 204 3 usbevt c1b60210 usb0 --More-- 23 cc322100 cc96d0000 0 0 204 6 irq15: ata1 22 cc322400 cc9690000 0 0 204 6 irq14: ata0 21 cc322700 cc9640000 0 0 204 6 irq11: pccbb0++ 20 cc322a00 cc95a0000 0 0 204 6 irq5: pcm0 19 cc322d00 cc9520000 0 0 204 6 irq13: 18 cc323000 cc94e0000 0 0 204 6 swi5: acpitaskq 17 cc323300 cc94a0000 0 0 204 6 swi5: task queue 16 cc323600 cc9460000 0 0 204 6 swi3: cambio 15 cc323900 cc9420000 0 0 204 6 swi2: camnet 14 cc323c00 cc93e0000 0 0 204 3 sleep c0417120 random 13 cc323f00 cc93a0000 0 0 204 6 swi4: vm 12 cc324200 cc9360000 0 0 20c 2 swi6: tty:sio clock 11 cc324500 cc9320000 0 0 204 6 swi1: net 10 cc324800 cc32d0000 0 0 20c 2 idle 1 cc324b00 cc3290000 0 1 0004200 2 init 0 c02c4200 c0480 0 0 200 3 sched c02c4200 swapper db tr 7 mi_switch(cc98c800,cc98c600,c1b688dc,1,0) at mi_switch+0x153 msleep(cc98c800,cc98c814,68,c0288668,0,cc98c800) at msleep+0x322 kthread_suspend_check(cc98c600,cc98c704,c01b5cf4,cc98c600,cd1aacf8) at kthread_suspend_check+0x50 sched_sync(0,cd1aad48,0,c01b5cf4,0) at sched_sync+0x4c fork_exit(c01b5cf4,0,cd1aad48) at fork_exit+0x9e fork_trampoline() at fork_trampoline+0x8 db
Re: reboot and sync behaviour.
I have had lots of these :) --- Julian Elischer [EMAIL PROTECTED] wrote: This succeeded, but looks suspicious to me. syncing disks... 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 regards, -- Hiten __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
cool.. ok, how about adding show witness (we need to figure out which process SHOULD be doing the reboot, but it's not obvious from this ps, which one we should be looking at.) if you have it compiled in, show ktr (a couple of pages of it anyhow) MIGHT show something. On Fri, 8 Feb 2002, Eugene M. Kim wrote: Attached is the requested DDB log (I guessed pid 7 `syncer' is the process doing the sync; if this is wrong let me know). Eugene PS. I used the serial console, so don't feel sorry to ask. =) On Fri, Feb 08, 2002 at 02:41:30PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, David Wolfskill wrote: Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 7 7 can you hit CTLALTESC and get into the debugger? My box shows the same symptom, and yes I can enter DDB. How may I help? Eugene show locks whould be good. also 'ps' and the stack trace of the process doing the sync... tr PID if you can get a serial console that would be best of course. you may wait a while to see if dave can get into ddb on his serial console. that may save you a lot of writing :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
david,
On Fri, 8 Feb 2002, Julian Elischer wrote:
cool..
ok, how about adding show witness
[...]
can you do a cvs diff -D{time1] -D[time2] /sys
where time2 is the earliest kernel that has the problem and time1 is the
last kernel that doesn't?
there may be some other diffs in there I'm not aware of..
I want to check it against my diff as I believe I committed it.
(there could be someone else's commit in there too)
julian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
Eh; I suspect that's showing the entry to ddb. Hmmm... gow about: db show witness Sleep locks: 0 Giant -- last acquired @ /usr/src/sys/kern/kern_intr.c:532 1 eventhandler -- last acquired @ /usr/src/sys/kern/subr_eventhandler.c:162 3lockmgr -- last acquired @ /usr/src/sys/kern/kern_lock.c:227 4 malloc -- last acquired @ /usr/src/sys/kern/kern_malloc.c:303 5 zone -- last acquired @ /usr/src/sys/vm/vm_zone.c:506 1 pbuf mutex -- last acquired @ /usr/src/sys/vm/vm_pager.c:466 6 ucred -- last acquired @ /usr/src/sys/kern/kern_prot.c:1601 1 sf_bufs list lock -- last acquired @ /usr/src/sys/kern/uipc_syscalls.c:1556 4 malloc -- last acquired @ /usr/src/sys/kern/kern_malloc.c:303 3lockmgr -- last acquired @ /usr/src/sys/kern/kern_lock.c:227 Looking at the ps I can't even see the process doing the exit.. it may be proc 0 or proc 1 can you trace them? also show pcpu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
In your case we need totrace proc 1 I think.. On Fri, 8 Feb 2002, Eugene M. Kim wrote: Attached is the requested DDB log (I guessed pid 7 `syncer' is the process doing the sync; if this is wrong let me know). Eugene PS. I used the serial console, so don't feel sorry to ask. =) On Fri, Feb 08, 2002 at 02:41:30PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, David Wolfskill wrote: Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 7 7 can you hit CTLALTESC and get into the debugger? My box shows the same symptom, and yes I can enter DDB. How may I help? Eugene show locks whould be good. also 'ps' and the stack trace of the process doing the sync... tr PID if you can get a serial console that would be best of course. you may wait a while to see if dave can get into ddb on his serial console. that may save you a lot of writing :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene show locks exclusive (sleep mutex) Giant (0xc02e60c0) locked @ /usr/src/sys/kern/kern_intr.c:532 db ps pid proc addruid ppid pgrp flag stat wmesg wchan cmd 279 cdbdc500 cdc6e0000 1 279 0004002 2 reboot 185 cc988900 cdbbc0000 0 0 204 3 nfsidl c1d053ac nfsiod 3 184 cc988c00 cdbb80000 0 0 204 3 nfsidl c1d053a8 nfsiod 2 183 cc988f00 cdbb40000 0 0 204 3 nfsidl c1d053a4 nfsiod 1 182 cc989200 cdbb0 0 0 204 3 nfsidl c1d053a0 nfsiod 0 7 cc98b600 cd1a60000 0 0 204 3 ktsusp cc98b800 syncer 6 cc98b900 cd1a20000 0 0 204 3 ktsusp cc98bb00 vnlru 5 cc98bc00 cd19e0000 0 0 204 3 ktsusp cc98be00 bufdaemon 4 cc98bf00 cd19a0000 0 0 204 3 pgzero c0327f88 pagezero 3 cc98c200 cd1960000 0 0 204 3 psleep c0327f9c vmdaemon 2 cc98c500 cd1920000 0 0 204 3 psleep c02e0698 pagedaemon 31 cc98c800 cc9910000 0 0 204 6 irq8: rtc 30 cc98cb00 cc98d0000 0 0 204 6 irq0: clk 29 cc321f00 cc9840000 0 0 204 6 irq4: sio0 28 cc322200 cc980 0 0 204 6 swi0: tty:sio 27 cc322500 cc97c0000 0 0 204 6 irq7: ppc0 26 cc322800 cc9780000 0 0 204 6 irq12: psm0 25 cc322b00 cc9740000 0 0 204 2 irq1: atkbd0 24 cc322e00 cc970 0 0 204 3 usbevt c1b60210 usb0 23 cc323100 cc96c0000 0 0 204 6 irq11: uhci0 --More-- 22 cc323400 cc9680000 0 0 204 6 irq15: ata1 21 cc323700 cc9640000 0 0 204 6 irq14: ata0 20 cc323a00 cc95b0000 0 0 204 6 irq5: pcm0 19 cc323d00 cc9530000 0 0 204 6 irq13: 18 cc324000 cc94f0000 0 0 204 6 swi5: acpitaskq 17 cc324300 cc94b0000 0 0 204 6 swi5: task queue 16 cc324600 cc9470000 0 0 204 6 swi3: cambio 15 cc324900 cc9430000 0 0 204 6 swi2: camnet 14 cc324c00 cc93f0000 0 0 204 3 sleep c04141c0 random 13 cc324f00 cc93b0000 0 0 204 6 swi4: vm 12 cc325200 cc9370000 0 0 20c 2 swi6: tty:sio clock 11 cc325500 cc9330000 0 0 204 6 swi1: net 10 cc325800 cc32e0000 0 0 20c 2 idle 1 cc325b00 cc32a0000 0 1 0004200 3wait cc325b00 init 0 c02c41c0 c047c0000 0 0 200 3 sched c02c41c0 swapper db tr 279 mi_switch(0,cdbdc500,cdbdc604,10,0) at mi_switch+0x153 boot(0,cdbdc714,cdc71d40,c0262b80,cdbdc604) at boot+0x200 reboot(cdbdc604,cdc71d20,2,0,0) at reboot+0x37 syscall(2f,2f,2f,0,0) at syscall+0x254 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (55, FreeBSD ELF, reboot), eip = 0x8048b8b, esp = 0xbfbffb1c, ebp = 0xbfbffb48 --- db tr 1 mi_switch(1,0,cc32dd20,1,0) at mi_switch+0x153 msleep(cc325b00,0,15c,c0287e85,0) at msleep+0x322 wait1(cc325c04,cc32dd20,0,cc32dd40,c0262b80) at wait1+0x617 wait4(cc325c04,cc32dd20,0,bfbffe18,bfbffe24) at wait4+0x12 syscall(2f,2f,2f,bfbffe24,bfbffe18) at syscall+0x254 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (7, FreeBSD ELF, wait4), eip = 0x8050c37, esp = 0xbfbffcf8, ebp = 0xbfbffd14 --- db tr 0 mi_switch(c02def10,0,483000,1,0) at mi_switch+0x153 msleep(c02c41c0,0,44,c02a7570,3e8) at msleep+0x322 scheduler(0,47bc00,47b000,0,c0121d1c) at scheduler+0x146 mi_startup() at mi_startup+0x95 begin() at begin+0x43 db ~~ show witness Sleep locks: 0 (dead) -- last acquired @ (dead):0 0 (dead) -- last acquired @ (dead):0 0 Giant -- last acquired @ /usr/src/sys/kern/kern_intr.c:532 1 ithread -- last acquired @ /usr/src/sys/kern/kern_intr.c:269 2 struct filedesc -- last acquired @ /usr/src/sys/kern/kern_descrip.c:1170 2 fork list -- last acquired @ /usr/src/sys/kern/kern_fork.c:649 3lockmgr -- last acquired @ /usr/src/sys/kern/kern_lock.c:227 2 proctree -- last acquired @
double-free in mtree(1)
I get the following error when running mtree(1) in a jail:
root@p4 /usr/src# gdb =mtree
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-freebsd...Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 2629
in elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 935
in fill_symbuf
(gdb) set args -deU -f /etc/mtree/BSD.root.dist -p /
(gdb) run
Starting program: /usr/sbin/mtree -deU -f /etc/mtree/BSD.root.dist -p /
mtree in free(): error: chunk is already free
Program received signal SIGABRT, Aborted.
0x280b4f07 in kill () from /usr/lib/libc.so.5
(gdb) where
#0 0x280b4f07 in kill () from /usr/lib/libc.so.5
#1 0x28108aa1 in abort () at /usr/src/lib/libc/../libc/stdlib/abort.c:70
#2 0x28107534 in wrterror (p=0x2811193b chunk is already free\n)
at /usr/src/lib/libc/../libc/stdlib/malloc.c:303
#3 0x28107560 in wrtwarning (p=0x2811193b chunk is already free\n)
at /usr/src/lib/libc/../libc/stdlib/malloc.c:311
#4 0x28108446 in ifree (ptr=0x8055700)
at /usr/src/lib/libc/../libc/stdlib/malloc.c:989
#5 0x281086d1 in free (ptr=0x8055700)
at /usr/src/lib/libc/../libc/stdlib/malloc.c:1121
#6 0x280aff2a in fts_close (sp=0x8059000)
at /usr/src/lib/libc/../libc/gen/fts.c:235
#7 0x804c0d4 in vwalk () at /usr/src/usr.sbin/mtree/verify.c:155
#8 0x804be12 in verify () at /usr/src/usr.sbin/mtree/verify.c:72
#9 0x804b3c1 in main (argc=6, argv=0xbfbff574)
at /usr/src/usr.sbin/mtree/mtree.c:167
#10 0x80493c9 in _start (arguments=0xbfbff688 /usr/sbin/mtree)
at /usr/src/lib/csu/i386-elf/crt1.c:96
(gdb) up 6
#6 0x280aff2a in fts_close (sp=0x8059000)
at /usr/src/lib/libc/../libc/gen/fts.c:235
235 free(p);
(gdb) p *p
$1 = {fts_cycle = 0xd0d0d0d0, fts_parent = 0xd0d0d0d0, fts_link = 0xd0d0d0d0,
fts_number = -791621424, fts_pointer = 0xd0d0d0d0,
fts_accpath = 0xd0d0d0d0 Error reading address 0xd0d0d0d0: Bad address,
fts_path = 0xd0d0d0d0 Error reading address 0xd0d0d0d0: Bad address,
fts_errno = -791621424, fts_symfd = -791621424, fts_pathlen = 53456,
fts_namelen = 53456, fts_ino = 3503345872, fts_dev = 3503345872,
fts_nlink = 53456, fts_level = -12080, fts_info = 53456, fts_flags = 53456,
fts_instr = 53456, fts_statp = 0xd0d0d0d0, fts_name = }
(gdb) p *sp
$2 = {fts_cur = 0x8055700, fts_child = 0x0, fts_array = 0x0, fts_dev = 29708,
fts_path = 0x805a000 ./proc, fts_rfd = 3, fts_pathlen = 1280,
fts_nitems = 0, fts_compar = 0, fts_options = 528}
(gdb) p *(sp-fts_cur)
$3 = {fts_cycle = 0xd0d0d0d0, fts_parent = 0xd0d0d0d0, fts_link = 0xd0d0d0d0,
fts_number = -791621424, fts_pointer = 0xd0d0d0d0,
fts_accpath = 0xd0d0d0d0 Error reading address 0xd0d0d0d0: Bad address,
fts_path = 0xd0d0d0d0 Error reading address 0xd0d0d0d0: Bad address,
fts_errno = -791621424, fts_symfd = -791621424, fts_pathlen = 53456,
fts_namelen = 53456, fts_ino = 3503345872, fts_dev = 3503345872,
fts_nlink = 53456, fts_level = -12080, fts_info = 53456, fts_flags = 53456,
fts_instr = 53456, fts_statp = 0xd0d0d0d0, fts_name = }
(gdb)
Same thing happens when I run it outside the jail, but pointing to the
jail's root directory. Seems like an fts bug, but I was unable to
discover the exact cause.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
yes but is it a SMP or UP kernel? (SMP kernel can run on some UP h/w) thanks! On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
I tlooks as if show locks would not show any locks held by anyone.. is this true? On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
It's an UP kernel running on an UP box. Eugene On Fri, Feb 08, 2002 at 04:53:28PM -0800, Julian Elischer wrote: yes but is it a SMP or UP kernel? (SMP kernel can run on some UP h/w) thanks! On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
I'm not particularly good at reading the lock-related output, but it doesn't have other lines than the one that says about the Giant lock, so it seems there isn't any other locks being held by anyone. Eugene On Fri, Feb 08, 2002 at 04:55:42PM -0800, Julian Elischer wrote: I tlooks as if show locks would not show any locks held by anyone.. is this true? On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
h so what is the difference between your kernel and mine that works? just out of curiosity, have you tried a very latest -current? do you have your own config? how does GENERIC behave? (what kind of disks do you have?) Julian On Fri, 8 Feb 2002, Eugene M. Kim wrote: It's an UP kernel running on an UP box. Eugene On Fri, Feb 08, 2002 at 04:53:28PM -0800, Julian Elischer wrote: yes but is it a SMP or UP kernel? (SMP kernel can run on some UP h/w) thanks! On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
h so what is the difference between your kernel and mine that works?
just out of curiosity, have you tried a very latest -current?
do you have your own config? how does GENERIC behave?
(what kind of disks do you have?)
It looks like a call to setrunqueue() was incorrectly dropped in
the latest version of kern_shutdown.c.
Index: kern_shutdown.c
===
RCS file: /home/ncvs/src/sys/kern/kern_shutdown.c,v
retrieving revision 1.118
diff -u -r1.118 kern_shutdown.c
--- kern_shutdown.c 7 Feb 2002 20:58:44 - 1.118
+++ kern_shutdown.c 9 Feb 2002 01:11:18 -
@@ -272,6 +272,7 @@
DROP_GIANT();
for (subiter = 0; subiter 50 * iter; subiter++) {
mtx_lock_spin(sched_lock);
+ setrunqueue(curthread);
curthread-td_proc-p_stats-p_ru.ru_nvcsw++;
mi_switch(); /* Allow interrupt threads to run
*/
mtx_unlock_spin(sched_lock);
- Tor Egge
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On Fri, Feb 08, 2002 at 05:09:31PM -0800, Julian Elischer wrote: h so what is the difference between your kernel and mine that works? /me scratches his head just out of curiosity, have you tried a very latest -current? Not the very latest; this source is about a day old. do you have your own config? how does GENERIC behave? I do have my own config; you can get it at: http://home.the-7.net/~ab/PL-DAAL (config file itself) http://home.the-7.net/~ab/PL-DAAL.hints (... and device hints) I haven't tried GENERIC yet. Eugene (what kind of disks do you have?) Julian On Fri, 8 Feb 2002, Eugene M. Kim wrote: It's an UP kernel running on an UP box. Eugene On Fri, Feb 08, 2002 at 04:53:28PM -0800, Julian Elischer wrote: yes but is it a SMP or UP kernel? (SMP kernel can run on some UP h/w) thanks! On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: double-free in mtree(1)
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Same thing happens when I run it outside the jail, but pointing to the jail's root directory. Seems like an fts bug, but I was unable to discover the exact cause. FWIW, I unmounted the jail's /proc and the problem went away. Perhaps fts makes assumptions that do not hold for procfs? Strange that it works on my / but not on the jail directory... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
Thats it for sure!
committing now..
On Sat, 9 Feb 2002 [EMAIL PROTECTED] wrote:
h so what is the difference between your kernel and mine that works?
just out of curiosity, have you tried a very latest -current?
do you have your own config? how does GENERIC behave?
(what kind of disks do you have?)
It looks like a call to setrunqueue() was incorrectly dropped in
the latest version of kern_shutdown.c.
Index: kern_shutdown.c
===
RCS file: /home/ncvs/src/sys/kern/kern_shutdown.c,v
retrieving revision 1.118
diff -u -r1.118 kern_shutdown.c
--- kern_shutdown.c 7 Feb 2002 20:58:44 - 1.118
+++ kern_shutdown.c 9 Feb 2002 01:11:18 -
@@ -272,6 +272,7 @@
DROP_GIANT();
for (subiter = 0; subiter 50 * iter; subiter++) {
mtx_lock_spin(sched_lock);
+ setrunqueue(curthread);
curthread-td_proc-p_stats-p_ru.ru_nvcsw++;
mi_switch(); /* Allow interrupt
threads to run */
mtx_unlock_spin(sched_lock);
- Tor Egge
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
yes,, this exactly fits the symptoms!
I've committed it.
(it's definitly wrong)
assume this will solv ethe problem.
now why doesn't MINE fail?
On Sat, 9 Feb 2002 [EMAIL PROTECTED] wrote:
h so what is the difference between your kernel and mine that works?
just out of curiosity, have you tried a very latest -current?
do you have your own config? how does GENERIC behave?
(what kind of disks do you have?)
It looks like a call to setrunqueue() was incorrectly dropped in
the latest version of kern_shutdown.c.
Index: kern_shutdown.c
===
RCS file: /home/ncvs/src/sys/kern/kern_shutdown.c,v
retrieving revision 1.118
diff -u -r1.118 kern_shutdown.c
--- kern_shutdown.c 7 Feb 2002 20:58:44 - 1.118
+++ kern_shutdown.c 9 Feb 2002 01:11:18 -
@@ -272,6 +272,7 @@
DROP_GIANT();
for (subiter = 0; subiter 50 * iter; subiter++) {
mtx_lock_spin(sched_lock);
+ setrunqueue(curthread);
curthread-td_proc-p_stats-p_ru.ru_nvcsw++;
mi_switch(); /* Allow interrupt
threads to run */
mtx_unlock_spin(sched_lock);
- Tor Egge
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Proxim Farallon usb ethernet support
Hi I just got the FARALLON PN796 (Proxim) usb ethernet
adapter working with my current thought I should post the
2 lines i needed to add to make it working to the
mailing list
/usr/src/sys/dev/usb
in file if_aue.c
Static struct aue_type aue_devs[] = {
{ USB_VENDOR_ADMTEK,USB_PRODUCT_ADMTEK_PEGASUS, 0 },
{ USB_VENDOR_ADMTEK, USB_PRODUCT_ADMTEK_FARALLON_PN796, PII},
{ USB_VENDOR_BILLIONTON,USB_PRODUCT_BILLIONTON_USB100,0 },
{ USB_VENDOR_MELCO, USB_PRODUCT_MELCO_LUATX1, 0 },
{ USB_VENDOR_MELCO, USB_PRODUCT_MELCO_LUATX5, 0 },
{ USB_VENDOR_MELCO, USB_PRODUCT_MELCO_LUA2TX5,PII },
{ USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DSB650, LSYS },
{ USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DSB650TX, LSYS },
{ USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DSB650TX_PNA, 0 },
{ USB_VENDOR_SMC, USB_PRODUCT_SMC_2202USB, 0 },
{ USB_VENDOR_LINKSYS, USB_PRODUCT_LINKSYS_USB100TX, LSYS },
{ USB_VENDOR_LINKSYS, USB_PRODUCT_LINKSYS_USB10TA, LSYS },
{ USB_VENDOR_LINKSYS, USB_PRODUCT_LINKSYS_USB10TX2, LSYS },
{ USB_VENDOR_COREGA,USB_PRODUCT_COREGA_FETHER_USB_TX, 0 },
{ USB_VENDOR_KINGSTON, USB_PRODUCT_KINGSTON_KNU101TX,0 },
{ USB_VENDOR_ABOCOM,USB_PRODUCT_DLINK_DSB650TX_PNA, 0 },
{ USB_VENDOR_IODATA,USB_PRODUCT_IODATA_USBETTX, 0 },
{ USB_VENDOR_ACCTON,USB_PRODUCT_ACCTON_USB320_EC, 0 },
{ 0, 0, 0 }
};
I just added the FARALLON line in this structure
in file usbdevs
/* ADMtek products */
product ADMTEK PEGASUS 0x0986 AN986 USB Ethernet adapter
product ADMTEK FARALLON_PN796 0x8511 NetLine 10/100 USB Ethernet Adapter (ADMtek
chipset AN986) by proxim
here i have just added the FARALLON line again which is i believe line #382
the line no. shouldnt matter tho.
Thats it
I realise that i should post a diff but i made the changes directly in these
files and will need to get the unchanged version from the cvs again to
produce a diff and its not too much change.
can someone please commit this change to the main source tree
also if someone is using this right out of this posting to get the adapter
working please dont forget to do
(after adding these 2 lines in the required files)
prompt# cd /usr/src/sys/dev/usb
prompt# make -f Makefile.usbdevs all
(before remaking and reinstalling the kernel)
Have fun
Saurabh Gupta
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
Julian Elischer wrote: h so what is the difference between your kernel and mine that works? For the love of God, please do not post your kernels to the list next. Much of the data transfer of the dumps should probably have been off list already. Please, please do not post your kernels. Thanks. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: cred stuff..
On 08-Feb-02 Julian Elischer wrote: I'd like to commit the code to keep the ucred across userland, with the code to clear it to NULL kept under DEBUG ifdefs. Use INVARIANTS for the ifdef macro name, but sure. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
Date: Fri, 8 Feb 2002 17:34:45 -0800 (PST) From: Julian Elischer [EMAIL PROTECTED] Thats it for sure! committing now.. On Sat, 9 Feb 2002 [EMAIL PROTECTED] wrote: It looks like a call to setrunqueue() was incorrectly dropped in the latest version of kern_shutdown.c. Applying that one-line patch to the kernel sources from this morning, then rebuilding the kernel, yielded a kernel that no longer exhibited the earlier-reported symptoms did not occur. Thanks to all! Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On 09-Feb-02 Julian Elischer wrote: yes,, this exactly fits the symptoms! I've committed it. (it's definitly wrong) assume this will solv ethe problem. now why doesn't MINE fail? Probably cause you are running your other tree that makes mi_switch() auto do the setrunqueue? :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On 09-Feb-02 Eugene M. Kim wrote: I'm not particularly good at reading the lock-related output, but it doesn't have other lines than the one that says about the Giant lock, so it seems there isn't any other locks being held by anyone. show locks pid only shows the locks held by a single thread. Trying to show all locks in the system would be a bit more work. You would basically need to add a new DDB command that walked the allproc list doing a show locks on each thread. show witness really isn't useful in most cases unless you are working on witness itself. It merely shows the tree of lock order relationships. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: cred stuff..
I'm a little worried about invariants because the behaviour when INVARIANTS is set wil be different to teh behaviour when it is off, which is 'strange' to say the least. Normally the behaviour si the same but you just check for invariant conditions. On Fri, 8 Feb 2002, John Baldwin wrote: On 08-Feb-02 Julian Elischer wrote: I'd like to commit the code to keep the ucred across userland, with the code to clear it to NULL kept under DEBUG ifdefs. Use INVARIANTS for the ifdef macro name, but sure. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
No, I just never went into that particular clause of code But is has made me rethink the whole issue. On Fri, 8 Feb 2002, John Baldwin wrote: On 09-Feb-02 Julian Elischer wrote: yes,, this exactly fits the symptoms! I've committed it. (it's definitly wrong) assume this will solv ethe problem. now why doesn't MINE fail? Probably cause you are running your other tree that makes mi_switch() auto do the setrunqueue? :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
fast interrupt handler threads.
Bruce, for the low-level impared such as myself, can you give a quick precis on teh difference between fast interrupt handlers in -current and 'normal' interrupt handlers. Do fast interrupt handlers enter through trap() ? if they interrupt a user process, do they take on the cred of the running thread? do they return via doreti() on returning do they check for ASTs and run userret()? I have seen the answers to some of these questions in the code, but I'd like to get a more 'english' explanation from someone who seems to understand them.. Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: cred stuff..
John, (peter? others?) How is it that getting a ucred reference is guarded by PROC_LOCK(p) but freeing it is guarded by mtx_lock(Giant); ? Call me naive, but shouldn't they be guarded by the same thing? Julian On Fri, 8 Feb 2002, Julian Elischer wrote: I'm a little worried about invariants because the behaviour when INVARIANTS is set wil be different to teh behaviour when it is off, which is 'strange' to say the least. Normally the behaviour si the same but you just check for invariant conditions. On Fri, 8 Feb 2002, John Baldwin wrote: On 08-Feb-02 Julian Elischer wrote: I'd like to commit the code to keep the ucred across userland, with the code to clear it to NULL kept under DEBUG ifdefs. Use INVARIANTS for the ifdef macro name, but sure. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
