Re: mdmfs mount_mfs compatibility bug?
In message <[EMAIL PROTECTED]>, Jos Backus writes:
>>
>> This was fixed some time ago, I thought. Are you up to date?
>
>There was a commit to mdmfs.c in August.
>This is with yesterday's -current, sorry, should have mentioned that.
The "mount -t mfs" case doesn't work with mdmfs, because mount(8)
uses the filesystem name, not the mount_xxx program as argv[0]. I
had guessed this would be a problem when I read the commit message
for revision 1.7 of mdmfs.c, but then I forgot to mention it to
Dima.
Here is a patch that should help - it makes mdmfs accept "mount_mfs"
or "mfs" to trigger compatibility mode instead of mount_*.
Ian
Index: mdmfs.8
===
RCS file: /dump/FreeBSD-CVS/src/sbin/mdmfs/mdmfs.8,v
retrieving revision 1.8
diff -u -r1.8 mdmfs.8
--- mdmfs.8 16 Aug 2001 07:43:16 - 1.8
+++ mdmfs.8 29 Sep 2001 23:50:29 -
@@ -304,9 +304,10 @@
flag,
or by starting
.Nm
-with
-.Li mount_
-at the beginning of its name
+with the name
+.Li mount_mfs
+or
+.Li mfs
(as returned by
.Xr getprogname 3 ) .
In this mode, only the options which would be accepted by
Index: mdmfs.c
===
RCS file: /dump/FreeBSD-CVS/src/sbin/mdmfs/mdmfs.c,v
retrieving revision 1.7
diff -u -r1.7 mdmfs.c
--- mdmfs.c 16 Aug 2001 02:40:29 - 1.7
+++ mdmfs.c 29 Sep 2001 22:58:05 -
@@ -116,8 +116,9 @@
newfs_arg = strdup("");
mount_arg = strdup("");
- /* If we were started as mount_*, imply -C. */
- if (strncmp(getprogname(), "mount_", 6) == 0)
+ /* If we were started as mount_mfs or mfs, imply -C. */
+ if (strcmp(getprogname(), "mount_mfs") == 0 ||
+ strcmp(getprogname(), "mfs") == 0)
compat = true;
while ((ch = getopt(argc, argv,
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mdmfs mount_mfs compatibility bug?
Ian Dowse <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]>, Jos Backus writes: > >> > >> This was fixed some time ago, I thought. Are you up to date? > > > >There was a commit to mdmfs.c in August. > >This is with yesterday's -current, sorry, should have mentioned that. > > The "mount -t mfs" case doesn't work with mdmfs, because mount(8) > uses the filesystem name, not the mount_xxx program as argv[0]. This seems to violate POLA. Would something break if it was changed to use mount_xxx (unforunately, I'm ~ 200 km away from my -current box at the moment, so I can't try it myself)? > I > had guessed this would be a problem when I read the commit message > for revision 1.7 of mdmfs.c, but then I forgot to mention it to > Dima. > > Here is a patch that should help - it makes mdmfs accept "mount_mfs" > or "mfs" to trigger compatibility mode instead of mount_*. The problem with this is that in a bikeshed far, far in the past, some people wanted to me able to call it "mount_md" instead of "mount_mfs". Of course, we could allow "mfs" and "md", but that seems rather ugly (what if someone wants "fish"?). I'd rather see mount(8) use mount_xxx, although if we think that would break something, your patch is probably the best solution. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mdmfs mount_mfs compatibility bug?
On Sat, Sep 29, 2001 at 05:25:20PM -0700, Dima Dorfman wrote: > The problem with this is that in a bikeshed far, far in the past, some > people wanted to me able to call it "mount_md" instead of "mount_mfs". Hardcoding the fsname may not be terribly elegant but does work. > Of course, we could allow "mfs" and "md", but that seems rather ugly > (what if someone wants "fish"?). I'd rather see mount(8) use > mount_xxx, although if we think that would break something, your patch > is probably the best solution. Fwiw, agreed on both counts. Thanks Ian, for providing the (temporary?) fix. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: blockable sleep lock (sx) ...
On Sat, Sep 29, 2001 at 12:52:48PM -0700, John Baldwin wrote: > > could figure out the faulting address that it trapp'd one that would help. You > could add KTR tracepoints or some such to store the log message to do that and > then examin the KTR buffer to get the actual faulting address. Ok. In the remote debugger I got a lot more data. In fact, it brought me to linux_alarm() in /sys/compat/linux_misc.c First some data about the trapping thread: td = curthread = 0xcbb89304 looks ok kg = td->ksegrp = 0xcbb89230looks ok td->td_proc->p_comm = "swi6: tty:sio clock" The LTP test that seems to be causing this is doing an alarm(). In linux_alarm() I see: : s = splsoftclock(); old_it = td->td_proc->p_realtimer; : td->td_proc->p_realtimer = it; splx(s); : Is the splsoftclock() acceptable locking to access td->td_proc? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mdmfs mount_mfs compatibility bug?
In message <[EMAIL PROTECTED]>, Dima Dorfman writes: > >The problem with this is that in a bikeshed far, far in the past, some >people wanted to me able to call it "mount_md" instead of "mount_mfs". >Of course, we could allow "mfs" and "md", but that seems rather ugly >(what if someone wants "fish"?). I'd rather see mount(8) use >mount_xxx, although if we think that would break something, your patch >is probably the best solution. I can't think of any good reason not to change mount(8), but I also think that mdmfs only needs to support the weird mount_mfs defaults when invoked with a name of "mount_mfs" or "mfs". People can call it mount_fish if they like and it will work fine, just with the mdmfs rather than mount_mfs defaults. The non-compatibility defaults are better defaults anyway, so they should probably be used in all cases except those that are necessary for compatibility with mount_mfs. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undefined symbol "__stderrp"
On Sat, Sep 29, 2001 at 10:34:46AM +0100, Paul Richards wrote: > --On Friday, September 28, 2001 19:04:39 -0700 Matthew Jacob > <[EMAIL PROTECTED]> wrote: > > > > > So, you're gonna be rude and drive away a user because they missed one > > line? > > Well, -current is supposed to be for developers and if you don't know C > you're probably not a developer. We certainly want to encourage more > developers to run -current but we don't really want users to be running it. > What about ports committers who test their ports on -current, but may not have a very good C knowledge(like myself). -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undefined symbol "__stderrp"
On Sat, Sep 29, 2001 at 09:10:45PM -0500, David W. Chapman Jr. wrote: > What about ports committers who test their ports on -current, but may > not have a very good C knowledge(like myself). You would read this list (as obviously you do if you saw this thread). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
modules/ed/../../dev/if_ed.c:40: opt_ed.h: No such file or directory
Apologies for this - I missed out a file in a commit earlier. Fixed now. Any other (non-module) complaints about opt_ed.h can be cured by rerunning config. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undefined symbol "__stderrp"
* David W. Chapman Jr. <[EMAIL PROTECTED]> [010929 21:11] wrote: > On Sat, Sep 29, 2001 at 10:34:46AM +0100, Paul Richards wrote: > > --On Friday, September 28, 2001 19:04:39 -0700 Matthew Jacob > > <[EMAIL PROTECTED]> wrote: > > > > > > > > So, you're gonna be rude and drive away a user because they missed one > > > line? > > > > Well, -current is supposed to be for developers and if you don't know C > > you're probably not a developer. We certainly want to encourage more > > developers to run -current but we don't really want users to be running it. > > > What about ports committers who test their ports on -current, but may > not have a very good C knowledge(like myself). I was going to respond to that myself (but I hit D), yes people should watch the lists more closely, but one doesn't have to be a C wizard to be qualified and an asset running current. Besideds ports people such as yourself there's also _users_ who like the pain and living on the edge, some of them are able to give quite comprehensive bug reports and provide valueable feedback and testing. So, let's give them a bit of kick in the pants in hope that it will motivate them to learn more (which is my story), but let's be careful that the kick we give doesn't send them packing. These users are very useful and valueable asset to the community. Their current utility is useful and who knows that the future holds for some of these enterprising souls, some of them will graduate to be contributors given enough of a chance. At least tack on a smiley or let them know that you'd like them to try harder instead of just going 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.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: blockable sleep lock (sx) ...
On 30-Sep-01 Marcel Moolenaar wrote: > On Sat, Sep 29, 2001 at 12:52:48PM -0700, John Baldwin wrote: >> >> could figure out the faulting address that it trapp'd one that would help. >> You >> could add KTR tracepoints or some such to store the log message to do that >> and >> then examin the KTR buffer to get the actual faulting address. > > Ok. In the remote debugger I got a lot more data. In fact, it > brought me to linux_alarm() in /sys/compat/linux_misc.c > > First some data about the trapping thread: > > td = curthread = 0xcbb89304 looks ok > kg = td->ksegrp = 0xcbb89230 looks ok > > td->td_proc->p_comm = "swi6: tty:sio clock" > > The LTP test that seems to be causing this is doing an alarm(). > > In linux_alarm() I see: > > : > s = splsoftclock(); > old_it = td->td_proc->p_realtimer; > : > td->td_proc->p_realtimer = it; > splx(s); > : > > Is the splsoftclock() acceptable locking to access td->td_proc? For now the code should be fine b/c it is under Giant. (The spl's don't dp anything anymore.) -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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: Undefined symbol "__stderrp"
On Sat, Sep 29, 2001 at 07:18:21PM -0700, David O'Brien wrote: > On Sat, Sep 29, 2001 at 09:10:45PM -0500, David W. Chapman Jr. wrote: > > What about ports committers who test their ports on -current, but may > > not have a very good C knowledge(like myself). > > You would read this list (as obviously you do if you saw this thread). > Unfortunately I didn't catch the thread the very first time it came around. Granted I should have checked the archives(when I originally got flamed), but this is one of those things, no matter how many times you make a big deal of it and how ever many people you flame about doing it, its still going ot happen. Might be best to just press delete instead of reply when you're frustrated at someone who didn't read the list the first time because it is easy to miss. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: blockable sleep lock (sx) ...
Gang, I was running the Linux Test Project's (ltp) regression suite to see how our Linuxulator was doing. It looks like we can use that to test our kernel as well. :-) IdlePTD 4292608 initial pcb at 3077c0 panicstr: bremfree: bp 0xc69541a8 not locked panic messages: --- panic: blockable sleep lock (sx) allproc @ /nfs/5.x/src/sys/kern/kern_proc.c:212 syncing disks... panic: bremfree: bp 0xc69541a8 not locked Uptime: 3h46m47s dumping to dev ad0s3b, offset 1572992 [snip] (kgdb) bt #0 0xc01bc316 in dumpsys () #1 0xc01bc103 in boot () #2 0xc01bc529 in panic () #3 0xc01e96c9 in bremfree () #4 0xc0194d49 in spec_fsync () #5 0xc0194889 in spec_vnoperate () #6 0xc02337fd in ffs_sync () #7 0xc01f5c01 in sync () #8 0xc01bbd4c in boot () #9 0xc01bc529 in panic () #10 0xc01d2582 in witness_lock () #11 0xc01c0555 in _sx_slock () #12 0xc01b76d0 in pfind () #13 0xc01d5cc9 in selwakeup () #14 0xc01df5a7 in ptcwakeup () #15 0xc01df582 in ptsstart () #16 0xc01dcc60 in ttstart () #17 0xc01de08d in tputchar () #18 0xc01cf037 in putchar () #19 0xc01cf29e in kvprintf () #20 0xc01cef64 in printf () #21 0xc026b095 in trap () #22 0xc01b62b7 in _mtx_lock_sleep () #23 0xc01b5f45 in _mtx_lock_flags () #24 0xc01c4594 in realitexpire () #25 0xc01c49fa in softclock () #26 0xc01aff5e in ithread_loop () #27 0xc01af43c in fork_exit () -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: lock (sleep mutex) vnode interlock on Alpga
On Tue, 25 Sep 2001, Wilko Bulte wrote: > I'm not sure if this is new, but anyway on -current as of yesterday > evening: > > Mounting root from ufs:/dev/da1a > panic: lock (sleep mutex) vnode interlock not locked @ > /usr/src/sys/kern/vfs_default.c:460 > panic Is this problem solved ? Can anyone give a 'go' on this one ? I'm waiting for this bug to be solved so that I can upgrade one of my 4.4-RELEASE machines to -CURRENT. :) -Steve -- Stephan van Beerschoten [SVB21-RIPE] [EMAIL PROTECTED] PGP fingerprint: 4557 9761 B212 FB4C 778D 3529 C42A 2D27 "To err is human, to forgive is Not Company Policy" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undefined symbol "__stderrp"
--On Friday, September 28, 2001 19:04:39 -0700 Matthew Jacob <[EMAIL PROTECTED]> wrote: > > So, you're gonna be rude and drive away a user because they missed one > line? Well, -current is supposed to be for developers and if you don't know C you're probably not a developer. We certainly want to encourage more developers to run -current but we don't really want users to be running it. Paul Richards FreeBSD Services Ltd http://www.freebsd-services.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: lock (sleep mutex) vnode interlock on Alpga
On Sat, Sep 29, 2001 at 10:45:22AM +0200, Stephan van Beerschoten wrote: > On Tue, 25 Sep 2001, Wilko Bulte wrote: > > > I'm not sure if this is new, but anyway on -current as of yesterday > > evening: > > > > Mounting root from ufs:/dev/da1a > > panic: lock (sleep mutex) vnode interlock not locked @ > > /usr/src/sys/kern/vfs_default.c:460 > > panic > > Is this problem solved ? Can anyone give a 'go' on this one ? > I'm waiting for this bug to be solved so that I can upgrade one of my > 4.4-RELEASE machines to -CURRENT. :) I think yes. John committed a fix IIRC. At least my Alpha stopped panicing. -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
undefined symbols in libutil.so in -CURRENT
After a recent (last week) cvsup and make world I am getting the following error whe trying to cvsup -CURRENT: /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol "__stdoutp" after which cvsup bails out. Why? I tried to recompile the world and libutil separately -- same result. __ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: undefined symbols in libutil.so in -CURRENT
COMPAT4X=TRUE On Sat, Sep 29, 2001 at 04:38:10AM -0700, Andrei Popov wrote: > After a recent (last week) cvsup and make world I am getting the > following error whe trying to cvsup -CURRENT: > > /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol > "__stdoutp" > > after which cvsup bails out. Why? > > I tried to recompile the world and libutil separately -- same result. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
gnu as problems
When attempting to builworld on a -current system from about the 24th, buildworld bombs like this: -- >>> stage 1: bootstrap tools -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/i386 DESTDIR=/usr/obj/usr/src/i3 86 INSTALL="sh /usr/src/tools/install.sh" MACHINE_ARCH=i386 TOOLS_PREFIX=/usr /obj/usr/src/i386 PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr /bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makef ile.inc1 -DBOOTSTRAPPING -DNOHTML -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHAR ED bootstrap-tools cd /usr/src/games/fortune/strfile; make obj; make depend; make all; make ins tall /usr/obj/usr/src/i386/usr/src/games/fortune/strfile created for /usr/src/games/f ortune/strfile rm -f .depend mkdep -f .depend -a /usr/src/games/fortune/strfile/strfile.c cd /usr/src/games/fortune/strfile; make _EXTRADEPEND echo strfile: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend cc -O -pipe -Wall-c /usr/src/games/fortune/strfile/strfile.c cc: Internal compiler error: program as got fatal signal 11 *** Error code 1 Stop in /usr/src/games/fortune/strfile. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. uriel# /usr/src/games/fortune/strfile/strfile.c: In function `cmp_str': /usr/src/games/fortune/strfile/strfile.c:439: output pipe has been closed Any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Review: change NGROUPS_MAX from 16 to 64
Hi, I'm involved in a project, where we need the ability for users to be in more than 16 groups, on those boxes we're using the below patch, any objections to committing it ? Index: sys/sys/syslimits.h === RCS file: /home/ncvs/src/sys/sys/syslimits.h,v retrieving revision 1.10 diff -u -r1.10 syslimits.h --- sys/sys/syslimits.h 2001/06/18 20:24:54 1.10 +++ sys/sys/syslimits.h 2001/09/29 18:07:00 @@ -45,7 +45,7 @@ #defineMAX_CANON 255 /* max bytes in term canon input line */ #defineMAX_INPUT 255 /* max bytes in terminal input */ #defineNAME_MAX 255 /* max bytes in a file name */ -#defineNGROUPS_MAX16 /* max supplemental group id's */ +#defineNGROUPS_MAX64 /* max supplemental group id's */ #ifndef OPEN_MAX #defineOPEN_MAX 64 /* max open files per process */ #endif /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/etc/services missing dict
Hello - Would it be okay to add the dictionary protocol to /etc/services? URL: http://www.dict.org RFC: ftp://ftp.isi.edu/in-notes/rfc2229.txt dict 2628/tcp # A Dictionary Server Protocol Thanks - David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: undefined symbols in libutil.so in -CURRENT
On Sat, Sep 29, 2001 at 04:38:10AM -0700, Andrei Popov wrote: > After a recent (last week) cvsup and make world I am getting the > following error whe trying to cvsup -CURRENT: > > /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol > "__stdoutp" I cannot believe I am seeing this. Do you even *READ* this list?? JUST YESTERDAY we answered this question. It was also answered in these threads: Date: Fri, 28 Sep 2001 17:12:56 -0700 Subject: Re: Undefined symbol "__stderrp" Subject: libutil.so.3: Undefined symbol "__stdoutp" Date: Mon, 24 Sep 2001 13:06:47 +0800 Subject: stdin/out/err changes kill world Date: Thu, 20 Sep 2001 12:31:24 -0700 As you can see, this issue has been discussed many times in the freebsd-current mailing list (reading this list is a requirement of running -CURRENT). You really need to review the expectations of running -CURRENT and consider if you aren't better off just sticking with the released product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/services missing dict
On Sat, Sep 29, 2001 at 02:22:07PM -0400, David Hill wrote: > Would it be okay to add the dictionary protocol to /etc/services? done To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: blockable sleep lock (sx) ...
On Sat, Sep 29, 2001 at 12:52:48PM -0700, John Baldwin wrote:
>
> Can you do 'show locks' at the ddb prompt to get a list of what locks are held?
db> show locks
exclusive (sleep mutex) Giant (0xc0343ae0) locked @
/nfs/5.x/src/sys/kern/kern_timeout.c:186
exclusive (spin mutex) sched lock (0xc0343940) locked @
/nfs/5.x/src/sys/kern/kern_mutex.c:340
> probably a NULL pointer dereference of some sort in _mtx_lock_sleep().
>From trace:
:
--- trap 0xc, eip = 0xc01b67c6, esp = 0xcbf9ec74, ebp = 0xcbf9ec80 ---
_mtx_lock_sleep(cc4c310c,0,c029b360,27b) at _mtx_lock_sleep+0x14e
:
In gdb (now with debug information):
(kgdb) bt
:
#21 0xc01cf514 in printf (
fmt=0xc02b3480 "kernel trap %d with interrupts disabled\n")
at /nfs/5.x/src/sys/kern/subr_prf.c:262
#22 0xc026bca9 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
tf_edi = -877096400, tf_esi = -867421940, tf_ebp = -872813440,
tf_isp = -872813472, tf_ebx = -877096188, tf_edx = -1049155008,
tf_ecx = 2, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1071945786, tf_cs = 8, tf_eflags = 65666, tf_esp = 635,
tf_ss = 0}) at /nfs/5.x/src/sys/i386/i386/trap.c:206
#23 0xc01b67c6 in _mtx_lock_sleep (m=0xcc4c310c, opts=0,
file=0xc029b360 "/nfs/5.x/src/sys/kern/kern_time.c", line=635)
at /nfs/5.x/src/sys/kern/kern_mutex.c:409
#24 0xc01b6421 in _mtx_lock_flags (m=0xcc4c310c, opts=0,
file=0xc029b360 "/nfs/5.x/src/sys/kern/kern_time.c", line=635)
at /nfs/5.x/src/sys/kern/kern_mutex.c:235
#25 0xc01c4b60 in realitexpire (arg=0xcc4c2f04)
at /nfs/5.x/src/sys/kern/kern_time.c:635
#26 0xc01c4fc6 in softclock (dummy=0x0)
at /nfs/5.x/src/sys/kern/kern_timeout.c:187
#27 0xc01b03ce in ithread_loop (arg=0xc0e45c80)
at /nfs/5.x/src/sys/kern/kern_intr.c:532
#28 0xc01af8ac in fork_exit (callout=0xc01b02a4 ,
arg=0xc0e45c80, frame=0xcbf9ed48) at /nfs/5.x/src/sys/kern/kern_fork.c:
(kgdb) up
:
#22 0xc026bca9 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
tf_edi = -877096400, tf_esi = -867421940, tf_ebp = -872813440,
tf_isp = -872813472, tf_ebx = -877096188, tf_edx = -1049155008,
tf_ecx = 2, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1071945786, tf_cs = 8, tf_eflags = 65666, tf_esp = 635,
tf_ss = 0}) at /nfs/5.x/src/sys/i386/i386/trap.c:206
206 printf("kernel trap %d with interrupts disabled\n",
(kgdb)
#23 0xc01b67c6 in _mtx_lock_sleep (m=0xcc4c310c, opts=0,
file=0xc029b360 "/nfs/5.x/src/sys/kern/kern_time.c", line=635)
at /nfs/5.x/src/sys/kern/kern_mutex.c:409
409 if (td1->td_ksegrp->kg_pri.pri_level >
kg->kg_pri.pri_level)
(kgdb) p td1
$1 = (struct thread *) 0x0
The strange part is that line 409 is the body of a for-loop (TAILQ_FOREACH)
that breaks whrn td1 is NULL.
(kgdb) p m->mtx_blocked
$3 = {tqh_first = 0xc1772a40, tqh_last = 0xcc4c3100}
(kgdb) p $3.tqh_first
$6 = (struct thread *) 0xc1772a40
(kgdb) p $6->td_blkq
$7 = {tqe_next = 0x1, tqe_prev = 0xdeadc0de}
(kgdb) p *$6
$8 = {td_proc = 0x18729006, td_ksegrp = 0x0, td_last_kse = 0x0, td_kse = 0x0,
td_plist = {tqe_next = 0x86001, tqe_prev = 0x0}, td_kglist = {
tqe_next = 0x0, tqe_prev = 0x0}, td_slpq = {tqe_next = 0x0,
tqe_prev = 0xcd20e000}, td_blkq = {tqe_next = 0x1, tqe_prev = 0xdeadc0de},
td_runq = {tqe_next = 0xdeadc0de, tqe_prev = 0xdeadc0de},
td_flags = -559038242, td_dupfd = -559038242, td_wchan = 0x0,
td_wmesg = 0xc16a0cac "\200*wÁ", td_lastcpu = 0 '\000', td_locks = 0,
td_blocked = 0xcd207b48, td_ithd = 0x0,
td_mtxname = 0xcd207a0c "\200*wÁ\220*wÁ\200z ÍW", td_contested = {
lh_first = 0xcd207a80}, td_sleeplocks = 0xcd207940,
td_intr_nesting_level = 1869349888, td_md = {}, td_retval = {
-559060125, -559038242}, td_pcb = 0xdeadc0de, td_slpcallout = {c_links = {
sle = {sle_next = 0xdeadc0de}, tqe = {tqe_next = 0xdeadc0de,
tqe_prev = 0xdeadc0de}}, c_time = -559038242, c_arg = 0xdeadc0de,
c_func = 0, c_flags = -1049941016}, td_frame = 0xc1772b40,
td_kstack_obj = 0xc1772248, td_kstack = 0}
I don't know to what extend the structures have ben globbered by the
double panic, but this is what I see post mortem.
BTW: It seems easily reproducable so if you want some additional
info, let me know. The kernel is bleeding edge with a local fix for
the linprocfs breakage.
FYI,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mdmfs mount_mfs compatibility bug?
On Sat, Sep 29, 2001 at 02:32:31PM -0700, Jos Backus wrote: > It looks like /tmp is not getting the right permissions set (1777). This was fixed some time ago, I thought. Are you up to date? Kris msg31966/pgp0.pgp Description: PGP signature
Re: mdmfs mount_mfs compatibility bug?
On Sat, Sep 29, 2001 at 04:26:03PM -0700, Kris Kennaway wrote: > On Sat, Sep 29, 2001 at 02:32:31PM -0700, Jos Backus wrote: > > It looks like /tmp is not getting the right permissions set (1777). > > This was fixed some time ago, I thought. Are you up to date? There was a commit to mdmfs.c in August. This is with yesterday's -current, sorry, should have mentioned that. > Kris -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linprocfs broken
Doug Barton <[EMAIL PROTECTED]> writes: > With -current sources starting last night, and continuing to a cvsup done > about half an hour ago, linprocfs is preventing kernel build. World build > goes just fine: Yes, I forgot to commit the changes to linprocfs after I committed pseudofs v2. Fixed now, thanks for the warning. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FreeBSD-STABLE panics when playing DVD's
I just cvsupped to the latest stable (from a -STABLE of 2 months ago) and now when I use vlc, or mplayer to play dvd's FreeBSD panics and reboots. I traced the panic but since I don't have a whole lot of time to sit here on the computer and trace kernel panics, I went the lazy man's route and checked out a source tree from a month ago. That kernel still had the same problem, so I checked a source tree out from 2 months ago, and low and behold the problem is gone. I'm still working on figureing out the exact commit that caused the problem, and when I find out, I'll let everyone here know, but I just thought that someone might already know which commit did it once I mentioned the general time the commit occured. Anyway, Just wanted to let everyone know. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD-STABLE panics when playing DVD's
: :I just cvsupped to the latest stable (from a -STABLE of 2 months ago) and now :when I use vlc, or mplayer to play dvd's FreeBSD panics and reboots. I traced :the panic but since I don't have a whole lot of time to sit here on the :computer and trace kernel panics, I went the lazy man's route and checked out :a source tree from a month ago. That kernel still had the same problem, so I :checked a source tree out from 2 months ago, and low and behold the problem :is gone. I'm still working on figureing out the exact commit that caused the :problem, and when I find out, I'll let everyone here know, but I just thought :that someone might already know which commit did it once I mentioned the :general time the commit occured. Anyway, Just wanted to let everyone know. : :Ken Try turning off vfs.vmiodirenable. If that's the problem I'll change the default back to 0 and and try to reproduce the problem here. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: undefined symbols in libutil.so in -CURRENT
--- David O'Brien <[EMAIL PROTECTED]> wrote: > I cannot believe I am seeing this. Do you even *READ* this list?? I guess I was not too current on the list's traffic last few days, sorry. __ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
linprocfs broken
With -current sources starting last night, and continuing to a cvsup done about half an hour ago, linprocfs is preventing kernel build. World build goes just fine: ===> fs/linprocfs rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/dev -I@/../include /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:725: macro `PFS_FILE' used with too many (6) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:726: macro `PFS_SYMLINK' used with too many (6) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:728: macro `PFS_FILE' used with too many (6) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:729: macro `PFS_FILE' used with too many (6) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:737: macro `PFS_FILE' used with too many (6) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:745: macro `PFS_FILE' used with too many (6) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:746: macro `PFS_FILE' used with too many (6) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:747: macro `PFS_FILE' used with too many (6) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:748: macro `PFS_FILE' used with too many (6) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:749: macro `PFS_FILE' used with too many (6) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:753: macro `PFS_FILE' used with too many (6) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:754: macro `PFS_FILE' used with too many (6) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:755: macro `PFS_FILE' used with too many (6) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:756: macro `PFS_DIR' used with too many (6) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:757: macro `PFS_PROCDIR' used with too many (5) args /usr/local/src/sys/modules/fs/linprocfs/../../../compat/linprocfs/linprocfs.c:758: macro `PFS_SYMLINK' used with too many (6) args mkdep: compile failed *** Error code 1 Stop in /usr/local/src/sys/modules/fs/linprocfs. -- "We will not tire, we will not falter, and we will not fail." - George W. Bush, President of the United States September 20, 2001 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Review: change NGROUPS_MAX from 16 to 64
On 29-Sep-01 Jesper Skriver wrote: > Hi, > > I'm involved in a project, where we need the ability for users to > be in more than 16 groups, on those boxes we're using the below > patch, any objections to committing it ? It bloats ucred's. Might as well just leave it as it is. If people need to tweak it it is easy to do, but most people don't need more than 16 groups. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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: panic: blockable sleep lock (sx) ...
On 29-Sep-01 Marcel Moolenaar wrote: > Gang, > > I was running the Linux Test Project's (ltp) regression suite to see > how our Linuxulator was doing. It looks like we can use that to test > our kernel as well. :-)\ Can you do 'show locks' at the ddb prompt to get a list of what locks are held? My guess is that sched_lock is held. The real problem is in the trap. It's probably a NULL pointer dereference of some sort in _mtx_lock_sleep(). Ideally, printf wouldn't be trying to d a wakeup in this case. :-P If you could figure out the faulting address that it trapp'd one that would help. You could add KTR tracepoints or some such to store the log message to do that and then examin the KTR buffer to get the actual faulting address. > panicstr: bremfree: bp 0xc69541a8 not locked > panic messages: > --- > panic: blockable sleep lock (sx) allproc @ > /nfs/5.x/src/sys/kern/kern_proc.c:212 > > syncing disks... panic: bremfree: bp 0xc69541a8 not locked > Uptime: 3h46m47s > > dumping to dev ad0s3b, offset 1572992 > [snip] > > (kgdb) bt >#0 0xc01bc316 in dumpsys () >#1 0xc01bc103 in boot () >#2 0xc01bc529 in panic () >#3 0xc01e96c9 in bremfree () >#4 0xc0194d49 in spec_fsync () >#5 0xc0194889 in spec_vnoperate () >#6 0xc02337fd in ffs_sync () >#7 0xc01f5c01 in sync () >#8 0xc01bbd4c in boot () >#9 0xc01bc529 in panic () >#10 0xc01d2582 in witness_lock () >#11 0xc01c0555 in _sx_slock () >#12 0xc01b76d0 in pfind () >#13 0xc01d5cc9 in selwakeup () >#14 0xc01df5a7 in ptcwakeup () >#15 0xc01df582 in ptsstart () >#16 0xc01dcc60 in ttstart () >#17 0xc01de08d in tputchar () >#18 0xc01cf037 in putchar () >#19 0xc01cf29e in kvprintf () >#20 0xc01cef64 in printf () >#21 0xc026b095 in trap () >#22 0xc01b62b7 in _mtx_lock_sleep () >#23 0xc01b5f45 in _mtx_lock_flags () >#24 0xc01c4594 in realitexpire () >#25 0xc01c49fa in softclock () >#26 0xc01aff5e in ithread_loop () >#27 0xc01af43c in fork_exit () > > -- > Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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: panic: blockable sleep lock (sx) ...
On Sat, Sep 29, 2001 at 12:52:48PM -0700, John Baldwin wrote: > > On 29-Sep-01 Marcel Moolenaar wrote: > > Gang, > > > > I was running the Linux Test Project's (ltp) regression suite to see > > how our Linuxulator was doing. It looks like we can use that to test > > our kernel as well. :-)\ > > Can you do 'show locks' at the ddb prompt to get a list of what locks are held? I'll get back to you. There are a couple of things going on at the same time that I need to serialize... > My guess is that sched_lock is held. The real problem is in the trap. It's > probably a NULL pointer dereference of some sort in _mtx_lock_sleep(). > Ideally, printf wouldn't be trying to d a wakeup in this case. :-P If you > could figure out the faulting address that it trapp'd one that would help. You > could add KTR tracepoints or some such to store the log message to do that and > then examin the KTR buffer to get the actual faulting address. Will do. I also need to figure out if it was directly caused by a test in the LTP suite and which one or that Murphy passed by my window... -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mdmfs mount_mfs compatibility bug?
It looks like /tmp is not getting the right permissions set (1777). /etc/fstab: /dev/md0/tmpmfs rw,nosuid,nodev,-s=32m,-X 0 0 lizzy:/sbin% ls -li mdmfs mount_mfs 38 -r-xr-xr-x 2 root wheel 342876 Sep 29 14:17 mdmfs 38 -r-xr-xr-x 2 root wheel 342876 Sep 29 14:17 mount_mfs Applying this patch --- mdmfs.c.origSat Sep 29 14:11:59 2001 +++ mdmfs.c Sat Sep 29 14:11:41 2001 @@ -119,6 +119,8 @@ /* If we were started as mount_*, imply -C. */ if (strncmp(getprogname(), "mount_", 6) == 0) compat = true; + fprintf(stderr, "getprogname(%s), compat=%d\n", + getprogname(), compat); while ((ch = getopt(argc, argv, "a:b:Cc:Dd:e:F:f:hi:LMm:Nn:O:o:p:Ss:t:Uw:X")) != -1) during bootup shows getprogname(mfs), compat=0 which explains why it doesn't happen (compat needs to be true). So getprogname() returns ``mfs'' instead of the expected ``mount_mfs''. Is this a bug in mount(8) or what? Am I missing something? The manpage clearly suggests that this should Just Work. Thanks, -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
