Re: find / -fstype local traverses non-local filesystems
> The problem is that the find took forever and the disk on host > new was thrashing away most of the time. > > find seems to be traversing all file systems (local and non-local) > but just not reporting the found file when its on a non-local > filesystem. See PR bin/23906. In short, the solution is to use: find . \( -fstype local -o -prune \) -print (obviously you should still put in the directives for what you want to find) Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today's panic :-)
In message <[EMAIL PROTECTED]> Bruce Evans writes: : It seems to be another trap while holding sched_lock. This should be : fatal, but the problem is only detected because trap() enables : interrupts. Then an interrupt causes bad things to happen. Unfortunately, : the above omits the critical information: the instruction at sw1b+0x6b. : There is no instruction at that address here. It is apparently just an : access to a swapped-out page for the new process. I can't see how this : ever worked. The page must be faulted in, but this can't be done while : sched_lock is held (not to mention after we have committed to switching : contexts). sw1b+0x6b is ltr %si I note that this doesn't happen when the disks are clean on boot, but does happen when they are dirty. The kernel is as of a cvsup 3pm MST today. The kernel from 1am last night doesn't seem to have this problem. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today's panic :-)
On Fri, 23 Feb 2001, Warner Losh wrote:
> I've added INVARIANTS and WITNESS to my kernel. Today I get a random
> panic on boot sometimes:
>
> lock order reseral(this doesn't cause the panic, but
> does seem to happen all the time)
> 1st vnode interlock last acquired @ ../../usr/ffs/ffs_fsops.c:396
> 2nd 0xc04837a0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:457
> 3rd 0xc80b9e8c vnode interlock @ ../../kern/vfs_subr.c:1872
> kernel trap 12 with interrupts disabled
> panic: runq-add: proc 0xc7b28ee0 (fsck_ufs) not SRUN
> Debugger("panic")
> Stopeed at Debugger+0x44: pushl %ebx
> db> trace
> Debugger(c03d3c03) at Debugger+0x44
> panic(c03d4040,c7b28ee0,c7b290a5,282,c7b2b960) at panic+0x70
> runq_add(c046ae20,c7b28ee0,c8a4bcra4,c0221ee5,c7b28ee0) at runq_add+0x40
> setrunqueue(c7b28ee0) at setrunqueue+0x10
> ithread_schedule(c0f0a00,1) at ithread_schedule+0x129
> sched_ithd(e) at sched_ithrd+0x3f
> Xresume14() at Xresume14+0x8
> --- interrupt, eip = 0xc03830fb, esp = 0x286, ebp = 0xc8a4bd34 ---
> trap(18,10,10,73b152,0) at trap+0x9b
> calltrap() at calltrap+0x5
> --- trap 0xc, eip = 0xc03822e9, esp = 0xc8a4bd7c, ebp = 0xc8a4bd90 ---
> sw1b(0,...) at sw1b+0x6b
> msleep(...) at msleep+0x588
> physio(...) at physio+0x30d
> spec_read(...) at spec_read+0x71
> ufsspec_read(...) at ufsspec_read+0x20
> ufs_noperatespec(...) at ufs_noperatespec+0x15
> vn_read(...) at vn_read+0x128
> dofileread(...) at dofileread+0xb0
> read(...) at read+0x36
> syscall(...) at syscall+0x551
> Xint0x80_syscall() at Xint0x80_syscall+0x23
> --- syscall 0x3, eip = 0x8054770, esp = 0xbfbfef60, ebp = 0xbfbfef9c ---
> db>
>
> Anything that I can do to help? I don't have a core dump of this, but
> it is happening often enough to be a pain.
It seems to be another trap while holding sched_lock. This should be
fatal, but the problem is only detected because trap() enables
interrupts. Then an interrupt causes bad things to happen. Unfortunately,
the above omits the critical information: the instruction at sw1b+0x6b.
There is no instruction at that address here. It is apparently just an
access to a swapped-out page for the new process. I can't see how this
ever worked. The page must be faulted in, but this can't be done while
sched_lock is held (not to mention after we have committed to switching
contexts).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
find / -fstype local traverses non-local filesystems
> rlogin olde > sudo find / -fstype local -name UPDATING > ls -l /usr/src/UPDATING -rw-r--r-- 1 me wheel 20477 Feb 18 21:48 /usr/src/UPDATING > df Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s2a 198399 1506323189683%/ /dev/ad0s2e 2622211 1497532 91490362%/usr procfs 440 100%/proc linprocfs 440 100%/usr/compat/linux/proc /dev/ad0s1 1050164 428128 62203641%/C /dev/ad0s3a 20550421 1890638 0%/scratch /dev/acd0c647152 6471520 100%/cdrom new:/usr/ports 8024556 3265929 411666344%/usr/ports new:/usr/src 8024556 3265929 411666344%/usr/src new:/usr/obj 8024556 3265929 411666344%/usr/obj new:/usr/sup 8024556 3265929 411666344%/usr/sup This looks fine I know. The problem is that the find took forever and the disk on host new was thrashing away most of the time. find seems to be traversing all file systems (local and non-local) but just not reporting the found file when its on a non-local filesystem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Today's panic :-)
I've added INVARIANTS and WITNESS to my kernel. Today I get a random
panic on boot sometimes:
lock order reseral (this doesn't cause the panic, but
does seem to happen all the time)
1st vnode interlock last acquired @ ../../usr/ffs/ffs_fsops.c:396
2nd 0xc04837a0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:457
3rd 0xc80b9e8c vnode interlock @ ../../kern/vfs_subr.c:1872
kernel trap 12 with interrupts disabled
panic: runq-add: proc 0xc7b28ee0 (fsck_ufs) not SRUN
Debugger("panic")
Stopeed at Debugger+0x44: pushl %ebx
db> trace
Debugger(c03d3c03) at Debugger+0x44
panic(c03d4040,c7b28ee0,c7b290a5,282,c7b2b960) at panic+0x70
runq_add(c046ae20,c7b28ee0,c8a4bcra4,c0221ee5,c7b28ee0) at runq_add+0x40
setrunqueue(c7b28ee0) at setrunqueue+0x10
ithread_schedule(c0f0a00,1) at ithread_schedule+0x129
sched_ithd(e) at sched_ithrd+0x3f
Xresume14() at Xresume14+0x8
--- interrupt, eip = 0xc03830fb, esp = 0x286, ebp = 0xc8a4bd34 ---
trap(18,10,10,73b152,0) at trap+0x9b
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc03822e9, esp = 0xc8a4bd7c, ebp = 0xc8a4bd90 ---
sw1b(0,...) at sw1b+0x6b
msleep(...) at msleep+0x588
physio(...) at physio+0x30d
spec_read(...) at spec_read+0x71
ufsspec_read(...) at ufsspec_read+0x20
ufs_noperatespec(...) at ufs_noperatespec+0x15
vn_read(...) at vn_read+0x128
dofileread(...) at dofileread+0xb0
read(...) at read+0x36
syscall(...) at syscall+0x551
Xint0x80_syscall() at Xint0x80_syscall+0x23
--- syscall 0x3, eip = 0x8054770, esp = 0xbfbfef60, ebp = 0xbfbfef9c ---
db>
Anything that I can do to help? I don't have a core dump of this, but
it is happening often enough to be a pain.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.strap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.ckern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
On Thu, 22 Feb 2001, Daniel Rock wrote: > Jake Burkholder schrieb: > [...] > > As I mentioned in the commit message, this changes the size and layout > > of struct kinfo_proc, so you'll have to recompile libkvm-using programs. > > > > As always, make world is your friend. > > You may have forgotten to also change KINFO_PROC_SIZE in src/sys/user.h Yes, rev.1.31 of src/sys/sys/user.h leaves it as an exercise to change KINFO_PROC_SIZE. > > I'm now getting bootup warning all the time: > > ... > real memory = 197066752 (192448K bytes) > avail memory = 187293696 (182904K bytes) > Preloaded elf kernel "kernel" at 0xc045. > WARNING: size of kinfo_proc (648) should be 644!!! This is normal if you haven't done the exercise. It is just a warning. > Pentium Pro MTRR support enabled > ... > > > BTW What is the purpose of KINFO_PROC_SIZE? Why not simply using sizeof()? It is to inhibit changes in the size of the struct. Such changes would break the interface. The struct must have a certain fixed size (and layout) for binary compatibility. sizeof() would give the current size, not necessarily the size that is required for compatibility. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is src/tools mandatory for buildworld?
On Fri, Feb 23, 2001 at 08:23:56PM -0800, Steve Kargl wrote: > I have never popluated src/tools in my local tree and > I've not experienced a problem with "make buildworld" > because src/tools was empty. In fact, I had a successful > "make buildworld && make installworld" last night at 2231 PST. AFAIK, the tools collection has been mandatory for a long time for just the reason you show. Dunno how you got away without it. Kris PGP signature
is src/tools mandatory for buildworld?
I have never popluated src/tools in my local tree and I've not experienced a problem with "make buildworld" because src/tools was empty. In fact, I had a successful "make buildworld && make installworld" last night at 2231 PST. Tonight I get, ain.o mkpar.o output.o reader.o skeleton.o symtab.o verbose.o warshall.o sh /usr/src/tools/install.sh -c -o root -g wheel -m 555 /usr/src/usr.bin/\ yacc/yyfix.sh /usr/obj/usr/src/i386/usr/bin/yyfix /usr/src/tools/install.sh: Can't open /usr/src/tools/install.sh: No such\ file or directory *** Error code 2 Stop in /usr/src/usr.bin/yacc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 A search through the tree at http://www.FreeBSD.org/cgi/cvsweb.cgi doesn't turn up a obvious commit. And yes, Alfred, I read the cvs-all mailing list, and again missed the commit that makes src/tools mandatory. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: name resolution problems
Hello Wesley, Tuesday, February 20, 2001, 1:26:29 AM, you wrote: WM> Since the big shake-up with -current, I find that mozilla and galeon can WM> no longer function (both up to date), but lynx has no problems. Mozilla WM> seems stuck resolving hostnames, yet tcpdump shows no traffic and truss WM> indicates that it is simply looping around a poll(). The biggest WM> difference between lynx and mozilla in terms of name resolution is that WM> mozilla is linked against libc_r... Could there be some problem here? WM> Is anyone else seeing this? yes, i see that too. but i experience the problem even with statically linked linux-opera from ports. very strange.. -- Best regards, Ilyamailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Release b0rked..
Jun Kuriyama <[EMAIL PROTECTED]> writes: > Assar, can you review and commit this? This is ok, but jhb has already fixed this. /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dirty buffers on reboot again?
In message <[EMAIL PROTECTED]> Wesley Morgan writes: : Not here. Just using ad and friends. I've disabled soft updates on my partitions and it seems to get rid of these. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: as segfaulting during world-build
In message <[EMAIL PROTECTED]> Daniel Rock writes: : I did have the same problem. But just rebuilding binutils didn't help either. : Trying to rebuild libc resulted in above SEGV from as. Some sort of Catch 22 Find a libc from before Feb 10th or after Feb 21 and put it on your system. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dirty buffers on reboot again?
Hmm. I've been getting this on an ATA box as well. Don't seem to get it when softupdates is not set on the root partition, but that's just an observation from a couple of boxes. (Sample size == 2 -> confidence level = 0). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Sat, 24 Feb 2001, Daniel C. Sobral wrote: > David O'Brien wrote: > > > > On Thu, Feb 22, 2001 at 03:20:10PM -0800, Matthew Jacob wrote: > > > login: (da0:ahc0:0:0:0): tagged openings now 16 > > ... > > > syncing disks... 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 > > > giving up on 3 buffers > > ... > > > I'm seeing a lot of this again. Anyone else? > > > > Yep. ahc controller also. By chance is that the commonality to this > > problem? > > MMm... I have an aic, though I'm fairly certain I got unsynced > buffers on ide. > > -- > Daniel C. Sobral (8-DCS) > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > Acabou o hipismo-arte. Mas a desculpa brasileira mais ouvida em Sydney > e' que nao tem mais cavalo bobo por ai'. > > 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
What ??
Dmesg: ---===> Happy Birthday Peter!!! <===--- :) Happy Birthday Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tail -f kernel panic
> In article >[EMAIL PROTECTED]> you >write: > >I found it is quite easy to panic a -current kernel with 2 login windows. > > > >In window 1 do a "tail -f /tmp/world.out" > >In window 2 do a "tail -f /tmp/world.out" > >In window 2 do "^C" to break out of tail -f > >In window 1 do "^C" to break out of tail -f > >The box panic immediately. > > I just commited a fix for this. Yes, no more panic. Thanks. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: btw - Re: whither libtermcap? (fallout of libc dance)
> On Fri, Feb 23, 2001 at 11:29:12AM -0800, Matthew Jacob wrote: > > On Fri, 23 Feb 2001, Kris Kennaway wrote: > > > > > On Fri, Feb 23, 2001 at 11:23:23AM -0800, Matthew Jacob wrote: > > > > > > > The problem is that libtermcap.so, still hanging around, is used by things > > > > that don't usually get rebuilt in a buildworld/installworld run (like X11 > > > > tools like xterm)- and attempts to use such things yield: > > > > > > lrwxr-xr-x 1 root wheel 12 Feb 23 00:55 /usr/lib/libtermcap.a -> >libncurses.a > > > lrwxr-xr-x 1 root wheel 13 Feb 23 00:55 /usr/lib/libtermcap.so -> >libncurses.so > > > -r--r--r-- 1 root wheel 15160 Apr 24 2000 /usr/lib/libtermcap.so.2 > > > l > > > > > > Remove your stale libraries - this one went away before 4.0-REL. > > > > ...Which then also begs the question- if I put this all into /usr/lib/compat- > > and libtermcap.so still whines about missing __stderr- is this a "we don't > > care- it's too old"? > > You shouldn't be building new binaries which link against libtermcap > (i.e. this should never happen) - it's only there for existing > binaries which would be linked against libc.so.3 also (both of which > are under compat/) and should continue to work. Yeah, okay- thanks! apparently the symlink to libncuruses works- so old X11 binaries work with libc.so.3 in /usr/lib/compat Whew! THanks! I didn't wanna have to rebuild all that goop... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: btw - Re: whither libtermcap? (fallout of libc dance)
On Fri, Feb 23, 2001 at 11:29:12AM -0800, Matthew Jacob wrote: > On Fri, 23 Feb 2001, Kris Kennaway wrote: > > > On Fri, Feb 23, 2001 at 11:23:23AM -0800, Matthew Jacob wrote: > > > > > The problem is that libtermcap.so, still hanging around, is used by things > > > that don't usually get rebuilt in a buildworld/installworld run (like X11 > > > tools like xterm)- and attempts to use such things yield: > > > > lrwxr-xr-x 1 root wheel 12 Feb 23 00:55 /usr/lib/libtermcap.a -> libncurses.a > > lrwxr-xr-x 1 root wheel 13 Feb 23 00:55 /usr/lib/libtermcap.so -> >libncurses.so > > -r--r--r-- 1 root wheel 15160 Apr 24 2000 /usr/lib/libtermcap.so.2 > > l > > > > Remove your stale libraries - this one went away before 4.0-REL. > > ...Which then also begs the question- if I put this all into /usr/lib/compat- > and libtermcap.so still whines about missing __stderr- is this a "we don't > care- it's too old"? You shouldn't be building new binaries which link against libtermcap (i.e. this should never happen) - it's only there for existing binaries which would be linked against libc.so.3 also (both of which are under compat/) and should continue to work. Kris PGP signature
btw - Re: whither libtermcap? (fallout of libc dance)
On Fri, 23 Feb 2001, Kris Kennaway wrote: > On Fri, Feb 23, 2001 at 11:23:23AM -0800, Matthew Jacob wrote: > > > The problem is that libtermcap.so, still hanging around, is used by things > > that don't usually get rebuilt in a buildworld/installworld run (like X11 > > tools like xterm)- and attempts to use such things yield: > > lrwxr-xr-x 1 root wheel 12 Feb 23 00:55 /usr/lib/libtermcap.a -> libncurses.a > lrwxr-xr-x 1 root wheel 13 Feb 23 00:55 /usr/lib/libtermcap.so -> libncurses.so > -r--r--r-- 1 root wheel 15160 Apr 24 2000 /usr/lib/libtermcap.so.2 > l > > Remove your stale libraries - this one went away before 4.0-REL. ...Which then also begs the question- if I put this all into /usr/lib/compat- and libtermcap.so still whines about missing __stderr- is this a "we don't care- it's too old"? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: whither libtermcap? (fallout of libc dance)
On Fri, 23 Feb 2001, Kris Kennaway wrote: > On Fri, Feb 23, 2001 at 11:23:23AM -0800, Matthew Jacob wrote: > > > The problem is that libtermcap.so, still hanging around, is used by things > > that don't usually get rebuilt in a buildworld/installworld run (like X11 > > tools like xterm)- and attempts to use such things yield: > > lrwxr-xr-x 1 root wheel 12 Feb 23 00:55 /usr/lib/libtermcap.a -> libncurses.a > lrwxr-xr-x 1 root wheel 13 Feb 23 00:55 /usr/lib/libtermcap.so -> libncurses.so > -r--r--r-- 1 root wheel 15160 Apr 24 2000 /usr/lib/libtermcap.so.2 > l > > Remove your stale libraries - this one went away before 4.0-REL. > *smack*... oh, yeah! sorry! I *do* have some 3.X stuff still there. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: whither libtermcap? (fallout of libc dance)
On Fri, Feb 23, 2001 at 11:23:23AM -0800, Matthew Jacob wrote: > The problem is that libtermcap.so, still hanging around, is used by things > that don't usually get rebuilt in a buildworld/installworld run (like X11 > tools like xterm)- and attempts to use such things yield: lrwxr-xr-x 1 root wheel 12 Feb 23 00:55 /usr/lib/libtermcap.a -> libncurses.a lrwxr-xr-x 1 root wheel 13 Feb 23 00:55 /usr/lib/libtermcap.so -> libncurses.so -r--r--r-- 1 root wheel 15160 Apr 24 2000 /usr/lib/libtermcap.so.2 l Remove your stale libraries - this one went away before 4.0-REL. Kris PGP signature
whither libtermcap? (fallout of libc dance)
It seems that libtermcap went away. Fine and dandy, okay... The problem is that libtermcap.so, still hanging around, is used by things that don't usually get rebuilt in a buildworld/installworld run (like X11 tools like xterm)- and attempts to use such things yield: farrago.feral.com > xterm /usr/libexec/ld-elf.so.1: /usr/lib/libtermcap.so.2: Undefined symbol "__stderr" (this also nukes ports like bash, etc., until they get rebuilt) d'ya suppose we can have libtermcap back, or some kind of compat thingie? Would this be a 4.X compat thingie? How is this supposed to work? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown: can't assign resources
On Fri, Feb 23, 2001 at 11:33:42AM -0500, Guillaume wrote: > Hello, > > I'm running FreeBSD 5.0-CURRENT since 2 days. > > When I boot FreeBSD I get this error: > > Feb 22 23:21:13 unix /boot/kernel/kernel: vga0: at port > 0x3c0-0x3df iomem 0xa-0xb on isa0 > Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign > resources > Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign > resources > Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign > resources > Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign > resources > Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign > resources > > What is that and how can I fix this error? Check the archives so someone doesn't have to answer this question all over again. Kris PGP signature
Re: tail -f kernel panic
In article [EMAIL PROTECTED]> you write: >I found it is quite easy to panic a -current kernel with 2 login windows. > >In window 1 do a "tail -f /tmp/world.out" >In window 2 do a "tail -f /tmp/world.out" >In window 2 do "^C" to break out of tail -f >In window 1 do "^C" to break out of tail -f >The box panic immediately. I just commited a fix for this. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tail -f kernel panic
In article [EMAIL PROTECTED]> you write: >I found it is quite easy to panic a -current kernel with 2 login windows. > >In window 1 do a "tail -f /tmp/world.out" >In window 2 do a "tail -f /tmp/world.out" >In window 2 do "^C" to break out of tail -f >In window 1 do "^C" to break out of tail -f >The box panic immediately. Hmm. I reproduced this here; the panic is in SLIST_REMOVE() when it is removing the second event. Funny enough, this does not happen on -stable. Did something change in the list macros recently that would cause this? -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dirty buffers on reboot again?'
> > No, its generically broken... > > Hmm, I must have Magic Boxes(tm) becaues none of them exhibit this problem. You might keep that in mind when you say, "oh, yes, it worked for me!" :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dirty buffers on reboot again?'
On 23-Feb-01 Soren Schmidt wrote: > It seems David O'Brien wrote: >> On Thu, Feb 22, 2001 at 03:20:10PM -0800, Matthew Jacob wrote: >> > login: (da0:ahc0:0:0:0): tagged openings now 16 >> ... >> > syncing disks... 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 >> > giving up on 3 buffers >> ... >> > I'm seeing a lot of this again. Anyone else? >> >> Yep. ahc controller also. By chance is that the commonality to this >> problem? > > No, its generically broken... Hmm, I must have Magic Boxes(tm) becaues none of them exhibit this problem. > -Søren -- 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: Release b0rked..
On 23-Feb-01 John Hay wrote:
>> ===> lib/libgssapi
>> rm -f .depend
>> mkdep -f .depend -a
> ...
>> /usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/krb5/krb5.h:43:
>> krb5_err.h: No such file or directory
>> /usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/krb5/krb5.h:44:
>> heim_err.h: No such file or directory
>
> You can get past this error with this patch, but it will just die a little
> later in another part of kerberos. You should have better luck by building
> a release with NOKERBEROS=YES. I was able to build one yesterday.
Hrm, I already got release fixed here locally with this patch which looks
more like what the other libraries do:
Index: kerberos5/lib/libgssapi//Makefile
===
RCS file: /host/ares/usr/home/ncvs/src/kerberos5/lib/libgssapi/Makefile,v
retrieving revision 1.1
diff -u -r1.1 Makefile
--- kerberos5/lib/libgssapi//Makefile 2001/02/13 16:56:50 1.1
+++ kerberos5/lib/libgssapi//Makefile 2001/02/23 02:34:46
@@ -7,7 +7,8 @@
-I${KRB5DIR}/lib/roken \
-I${KRB5DIR}/lib/des\
-I${KRB5DIR}/include\
- -I${ASN1OBJDIR}
+ -I${ASN1OBJDIR} \
+ -I${.OBJDIR}
SRCS= \
8003.c \
@@ -49,8 +50,10 @@
wrap.c \
address_to_krb5addr.c
-INCLUDES=${KRB5DIR}/lib/gssapi/gssapi.h
+INCLUDES=${KRB5DIR}/lib/gssapi/gssapi.h heim_err.h krb5_err.h
.include
.PATH: ${KRB5DIR}/lib/gssapi
+
+beforedepend all: heim_err.h krb5_err.h
Oops, and I've already committed this. I'm sure it will get backed out if it
isn't correct.
--
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
Panic with last night's -current
Gang,
I cvsup'ed last night as of green's latest update of
src/lib/libc/stdio/_flock_stub.c. I had a weird panic this morning, after
the machine was up overnight (although not really doing anything). I have
'tail -f $HOME/.xsession-errors > /dev/console &' in my .xsession file, and
when I logged out of windowmaker to replace it with the latest version, for
some reason the script that's supposed to run that kills that job on the
way out didn't run. When I started the new wm I noticed that I had two
tail's running, so I tried to kill one. As soon as I typed 'kill ' in
the xterm the system locked up, and eventually panic'ed and rebooted. To
add to the excitement I changed my kernel debugging options last night to
include WITNESS. I now have WITNESS and INVARIANTS, no DIAGNOSTIC. I have a
UP system, Celeron 300A on an Asus P2B motherboard.
Here's what I got from kgdb, I have the core and debug kernel if anyone
wants more data.
Enjoy,
Doug
--
"Pain heals. Chicks dig scars. Glory . . . lasts forever."
-- Keanu Reeves as Shane Falco in "The Replacements"
Do YOU Yahoo!?
IdlePTD 4222976
initial pcb at 361980
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02815de
stack pointer = 0x10:0xc8b28db4
frame pointer = 0x10:0xc8b28dc0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 342 (tail)
trap number = 12
panic: page fault
syncing disks... 16 16 16 16 16 16 16 16 16 16 16 fxp0: device timeout
16 16 16 16 16 16 16 16 16
giving up on 16 buffers
Uptime: 8h19m3s
dumping to dev da1s1b, offset 262168
dump 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111
110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90
89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:476
476 if (dumping++) {
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:476
#1 0xc01a6667 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:319
#2 0xc01a6a31 in panic (fmt=0xc02fcd8f "page fault")
at /usr/src/sys/kern/kern_shutdown.c:569
#3 0xc02b1756 in trap_fatal (frame=0xc8b28d74, eva=0)
at /usr/src/sys/i386/i386/trap.c:993
#4 0xc02b14a5 in trap_pfault (frame=0xc8b28d74, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:907
#5 0xc02b0af8 in trap (frame={tf_fs = 24, tf_es = -1070727152, tf_ds = 16,
tf_edi = -928237472, tf_esi = -927731776, tf_ebp = -927822400,
tf_isp = -927822432, tf_ebx = -927801408, tf_edx = 0,
tf_ecx = -928237072, tf_eax = -1056946176, tf_trapno = 12, tf_err =
0,
tf_eip = -1071114786, tf_cs = 8, tf_eflags = 66051, tf_esp =
-927731776,
tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:454
#6 0xc02815de in filt_ufsdetach (kn=0xc8b3efc0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2226
#7 0xc0194803 in kqueue_close (fp=0xc1000680, p=0xc8ac3860)
at /usr/src/sys/kern/kern_event.c:702
#8 0xc019351d in fdrop (fp=0xc1000680, p=0xc8ac3860)
at /usr/src/sys/sys/file.h:216
#9 0xc0193463 in closef (fp=0xc1000680, p=0xc8ac3860)
at /usr/src/sys/kern/kern_descrip.c:1213
#10 0xc01931d0 in fdfree (p=0xc8ac3860)
at /usr/src/sys/kern/kern_descrip.c:1052
#11 0xc0195f6d in exit1 (p=0xc8ac3860, rv=15)
at /usr/src/sys/kern/kern_exit.c:194
#12 0xc01a97ca in sigexit (p=0xc8ac3860, sig=15)
at /usr/src/sys/kern/kern_sig.c:1599
#13 0xc01a9520 in postsig (sig=15) at /usr/src/sys/kern/kern_sig.c:1500
#14 0xc02affc3 in userret (p=0xc8ac3860, frame=0xc8b28fa8, oticks=1)
at /usr/src/sys/i386/i386/trap.c:178
#15 0xc02b20dc in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 4, tf_esi = 1, tf_ebp = -1077937168, tf_isp = -927821868,
tf_ebx = 672174336, tf_edx = 0, tf_ecx = 0, tf_eax = 4, tf_trapno =
12,
tf_err = 2, tf_eip = 671772464, tf_cs = 31, tf_eflags = 663,
tf_esp = -1077937388, tf_ss = 47}) at
/usr/src/sys/i386/i386/trap.c:1239
#16 0xc02a4883 in Xint0x80_syscall ()
#17 0x8049e68 in ?? ()
#18 0x8048b8d in ?? ()
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
tail -f kernel panic
I found it is quite easy to panic a -current kernel with 2 login windows. In window 1 do a "tail -f /tmp/world.out" In window 2 do a "tail -f /tmp/world.out" In window 2 do "^C" to break out of tail -f In window 1 do "^C" to break out of tail -f The box panic immediately. I can't get a coredump at the moment because the kernel just stops while doing the "syncing disks... 7 7"... Maybe it is related to kern/25309? Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc023175a stack pointer = 0x10:0xc8fe5db4 frame pointer = 0x10:0xc8fe5dc0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 347 (tail) trap number = 12 panic: page fault cpuid = 1; lapic.id = boot() called on cpu#1 syncing disks... 7 7 c02312e8 t ufs_advlock c0231310 T ufs_vinit c02313bc t ufs_makeinode c023159c t ufs_missingop c02315b4 t ufs_kqfilter c02316d4 t filt_ufsdetach c02317dc t filt_ufsread c0231808 t filt_ufsvnode c023182c T ufs_vnoperate John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Any Ideas
:Are you aware of any recent changes that would have caused this :problem? I do not believe that the soft updates changes would :have caused this problem since they were all related to `under :stress' conditions which are not applicable here. : : ~Kirk I haven't made any commits to -current for a while, like several weeks. It's possible that the specfs fsync fixes I did few weeks ago could be involved, but the syncing problem seems to have come up recently... long after I had made those changes. It seems more likely that the problems are related to scheduler and interrupt subsystem changes in -current. If someone were to generate a core during the failing synchronization attempt I'd be happy to look at it. It can only be one of a few possibilities: (1) The buffer cannot be synced because a background write is in progress and the background write never finishes (not likely), (2) the I/O for the buffer synchronization is initiated but interrupts are winding up being disabled by the halt code due to holding Giant and not sleeping (more likely). That all I can think of. We've hit the interrupt disablement problem before in -current, it's probably something simliar. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
woo hoo! vm panic!
panic: vm_page_insert: already inserted syncing disks... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown: can't assign resources
Guillaume wrote: > > Hello, > > I'm running FreeBSD 5.0-CURRENT since 2 days. > > When I boot FreeBSD I get this error: > > Feb 22 23:21:13 unix /boot/kernel/kernel: vga0: at port > 0x3c0-0x3df iomem 0xa-0xb on isa0 > Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign > resources > Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign > resources > Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign > resources > Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign > resources > Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign > resources > > What is that and how can I fix this error? The BIOS's PNP table i sreporting devices that you are also mentionning in either your kernel config hints file, or in /boot/device.hints. (or maybe even PCI devices). In either case, the one you mention in your config gets allocated the ports and interrupts etc. so when the kernel tries to allocate them for the PNP device, it can't. Since they are refering to the same device, this doesn;t matter, in fact it's good. (Or you'd have two driver instances pointing at teh same hardware). if you remove the entries in /boot/device.hints that refer to the same device, and let the PNP table be used instead to attach drivers (for those that are recognised) you'll get less of these. Msmith mailed me a PNP device list. I include it here for your assistance in identifying these. > > Guillaume > [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v This document is the ultimate source for Windows Generic Device IDs and Plug and Play BIOS device type codes. CONTENTS: Plug and Play Vendor IDs and Device IDs Generic Device IDs Device Type Codes == PLUG AND PLAY VENDOR IDs AND DEVICE IDs All non-BIOS enumerated devices must not use "PNP" in their Vendor and Device codes. The vendor must register with EISA and have a vendor code assigned (for example, CTL for Creative Labs). The "PNP" vendor code is reserved for Microsoft and can only be used when defining a devices CompatibleID after indicating the devices HardwareID in the Plug and Play header. Use of CompatibleIDs is strongly recommended for devices that use device drivers provided with Microsoft Windows 95, such as a "Standard PC COM Port" (PNP0500) or "Sound Blaster 16 Sound Device" (PNPB003). The following example output from ISOLATE.EXE of a Plug and Play header is provided for your reference: Vendor ID: XXX Serial Number: 0001 Checksum (reported): 0x5E PNP Version: 1.0 Vendor Ver.: 10 Device Description: IDE Port Device ID: XXX0001 Doesn't Support I/O Range Checking Vendor Defined Logical Device Control Registers: None Compatible Device ID: PNP0600 Device Description: IDE Dependent Function 0 ... Dependent Function 1 ... End of Dependent Functions When the user is installing devices that use this method, a dialog box appears at the beginning of the enumeration sequence to suggest use of the default driver provided with Windows 95. Windows 95 also provides the option for using a disk from the manufacturer, in case the user wants to choose a manufacturer-supplied driver. For multifunction adapters, you should supply an INF file that chooses the appropriate drivers (including default drivers) for all the adapters devices. This prevents additional dialog boxes from again requesting the default driver or a manufactures disk for the rest of the devices on the adapter. When an INF file is used in this manner for default driver selection, it must link the HardwareID (XXX) to the appropriate compatible device driver from the Windows 95 distribution compact disc or installation disks. If this is not done, Windows 95 will continue to query the user for either the default driver or a new driver, thus defeating the purpose of using the INF file in this way. == WINDOWS GENERIC DEVICE IDs -- Many devices have no standard EISA ID, such as the interrupt controller or keyboard controller. Also, a set of compatible devices, such as VGA and Super VGA, are not actually devices, but define a compatibility hardware subset. Yet another set of IDs needs to be used to identify buses. Microsoft has reserved an EISA prefix of "PNP" to identify various devices that do not have an existing EISA ID, as well as defining compatibility devices. The IDs are defined in the following tables. DEVICE ID RANGES
Re: Release b0rked.. (libgssapi)
It looks like I was wrong. This patch fix a "make release" for me. The
other problems must have been fixed with the other krb fixes over the
past few days.
Any reason not to commit it?
John
--
John Hay -- [EMAIL PROTECTED]
> > ===> lib/libgssapi
> > rm -f .depend
> > mkdep -f .depend -a
> ...
> > /usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/krb5/krb5.h:43:
> > krb5_err.h: No such file or directory
> > /usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/krb5/krb5.h:44:
> > heim_err.h: No such file or directory
>
> You can get past this error with this patch, but it will just die a little
> later in another part of kerberos. You should have better luck by building
> a release with NOKERBEROS=YES. I was able to build one yesterday.
>
> John
> --
> John Hay -- [EMAIL PROTECTED]
>
>
> Index: kerberos5/lib/libgssapi/Makefile
> ===
> RCS file: /home/ncvs/src/kerberos5/lib/libgssapi/Makefile,v
> retrieving revision 1.1
> diff -u -r1.1 Makefile
> --- kerberos5/lib/libgssapi/Makefile 2001/02/13 16:56:50 1.1
> +++ kerberos5/lib/libgssapi/Makefile 2001/02/17 15:13:38
> @@ -7,7 +7,8 @@
> -I${KRB5DIR}/lib/roken \
> -I${KRB5DIR}/lib/des\
> -I${KRB5DIR}/include\
> - -I${ASN1OBJDIR}
> + -I${ASN1OBJDIR} \
> + -I${KRB5OBJDIR}
>
> SRCS=\
> 8003.c \
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
unknown: can't assign resources
Hello, I'm running FreeBSD 5.0-CURRENT since 2 days. When I boot FreeBSD I get this error: Feb 22 23:21:13 unix /boot/kernel/kernel: vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign resources Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign resources Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign resources Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign resources Feb 22 23:21:13 unix /boot/kernel/kernel: unknown: can't assign resources What is that and how can I fix this error? Guillaume [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dirty buffers on reboot again?
David O'Brien wrote: > > On Thu, Feb 22, 2001 at 03:20:10PM -0800, Matthew Jacob wrote: > > login: (da0:ahc0:0:0:0): tagged openings now 16 > ... > > syncing disks... 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 > > giving up on 3 buffers > ... > > I'm seeing a lot of this again. Anyone else? > > Yep. ahc controller also. By chance is that the commonality to this > problem? MMm... I have an aic, though I'm fairly certain I got unsynced buffers on ide. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Acabou o hipismo-arte. Mas a desculpa brasileira mais ouvida em Sydney e' que nao tem mais cavalo bobo por ai'. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dirty buffers on reboot again?
Not here. Just using ad and friends. On Fri, 23 Feb 2001, Matthew Jacob wrote: > > Hmm... Good question. > > On Fri, 23 Feb 2001, David O'Brien wrote: > > > On Thu, Feb 22, 2001 at 03:20:10PM -0800, Matthew Jacob wrote: > > > login: (da0:ahc0:0:0:0): tagged openings now 16 > > ... > > > syncing disks... 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 > > > giving up on 3 buffers > > ... > > > I'm seeing a lot of this again. Anyone else? > > > > Yep. ahc controller also. By chance is that the commonality to this > > problem? > > > > -- > > -- David ([EMAIL PROTECTED]) > > GNU is Not Unix / Linux Is Not UniX > > > > 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 > -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dirty buffers on reboot again?
Hmm... Good question. On Fri, 23 Feb 2001, David O'Brien wrote: > On Thu, Feb 22, 2001 at 03:20:10PM -0800, Matthew Jacob wrote: > > login: (da0:ahc0:0:0:0): tagged openings now 16 > ... > > syncing disks... 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 > > giving up on 3 buffers > ... > > I'm seeing a lot of this again. Anyone else? > > Yep. ahc controller also. By chance is that the commonality to this > problem? > > -- > -- David ([EMAIL PROTECTED]) > GNU is Not Unix / Linux Is Not UniX > > 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: How is -CURRENT?
On Fri, Feb 23, 2001 at 02:03:24PM +0700, John Indra wrote: > Is it safe to make world right now? Do KDE2 apps work flawlessly on newest > -CURRENT? If there are people that can say yes to that answer, than I am > ready to blow away all my /usr/X11R6 and /usr/local and build everything > from scratch, thank you... Define flawlessly? I haven't noticed any problems yet with KDE2, other than the usual mixing of threaded and non threaded (that glorious hack called mpeglib, and mpeglib_artsplug) bits breaking arts.. grr. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dirty buffers on reboot again?'
It seems David O'Brien wrote: > On Thu, Feb 22, 2001 at 03:20:10PM -0800, Matthew Jacob wrote: > > login: (da0:ahc0:0:0:0): tagged openings now 16 > ... > > syncing disks... 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 > > giving up on 3 buffers > ... > > I'm seeing a lot of this again. Anyone else? > > Yep. ahc controller also. By chance is that the commonality to this > problem? No, its generically broken... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dirty buffers on reboot again?
On Thu, Feb 22, 2001 at 03:20:10PM -0800, Matthew Jacob wrote: > login: (da0:ahc0:0:0:0): tagged openings now 16 ... > syncing disks... 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 > giving up on 3 buffers ... > I'm seeing a lot of this again. Anyone else? Yep. ahc controller also. By chance is that the commonality to this problem? -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[Solved] Re: -CURRENT slowdown in last 2 weeks
> > Do you have MUTEX_DEBUG in your kernel? > Sorry guys, my bad. As John and Kris reminded me, the slowdown was because of this - should have checked again the archive, I remember it had been mentioned before. Bye, Andrea -- It is easier to fix Unix than to live with NT. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems syncing disks in recent -current (since 19th)
On Wed, Feb 21, 2001 at 09:55:22PM +, Josef Karthauser wrote: > Hi Kirk, > > A number of us have problem reliably syncing disks with softupdates in > recent -current from about the 19th. Is it possible that you broke > something with your recent commit? I forgot to mention that the syncing problem is when the O/S is being shutdown; not syncing in general. We get a 'syncing buffers: 15 15 15 15 15 15 15 15 15 ', etc, until it gives up. Regards, Joe. PGP signature
Re: Building procedure of krb5 is broken
jhay> A, maybe this will also fix "make release". It has been
jhay> dying in the kerberos area the last few days.
Unfortunately, it does NOT fix "make release" breakage (already
reported by kuriyama-san). I've checked why, and make a patch to fix this.
--- src/kerberos5/lib/libgssapi/Makefile.dist Wed Feb 14 01:56:50 2001
+++ src/kerberos5/lib/libgssapi/MakefileFri Feb 23 17:32:26 2001
@@ -7,7 +7,8 @@
-I${KRB5DIR}/lib/roken \
-I${KRB5DIR}/lib/des\
-I${KRB5DIR}/include\
- -I${ASN1OBJDIR}
+ -I${ASN1OBJDIR} \
+ -I${KRB5OBJDIR}
SRCS= \
8003.c \
Some header files of libgssapi require krb5_err.h but there is no
krb5_err.h in source repository. krb5_err.h only lives under /usr/obj,
since krb5_err.h is *generated* from krb5_err.et. Adding -I${KRB5OBJDIR}
should fix the problem.
If you want to reproduce what's the problem, try:
cd /usr/src/kerberos5; make bootstrap
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
FFS snapshot with today's CURRENT freezes and reboots.
Well, I hate to do an 'as title' post. However, I did a make world about 6 hours ago. And when I execute mount snapshot -u -o /xxx/snap1 /xxx The machine always freezes for about 15 seconds and reboots without warning. This is a Sony VAIO laptop z505js with ATA disk. (if that is even of relevance). Since I discovered the problem at 1am, I really have no other debug information to be put up, just a heads up. I am wondering if this is just me, or is anybody having the same problem? If this problem is repeatable for others, I'll generate a bug report that will make Bill Paul smile. :) -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
