Re: is dumpon/savecore broken?
According to Poul-Henning Kamp: In message [EMAIL PROTECTED], "Steven G. Kar gl" writes: During the boot process I see dumpon: crash dumps to /dev/da0s1b (4, 131073) checking for core dump...savecore: can't find device 13/131073 It seems that the the major device number is reset from 4 to 13. Yes, all dev_t's which make it out of the kernel have cmajor numbers now. Try this change to savecore: /ddname = find_dev/s/BLK/CHR/ Thanks, Poul. I forgot to mention that this is after a "make world" and new kernel from today (1000 PST). -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
According to Matthew Dillon: :dumpon: crash dumps to /dev/da0s1b (4, 131073) :checking for core dump...savecore: can't find device 13/131073 : : It seems that the the major device number is reset from 4 to 13. : : Yes, all dev_t's which make it out of the kernel have cmajor : numbers now. : : Try this change to savecore: : :/ddname = find_dev/s/BLK/CHR/ : : :Thanks, Poul. : :I forgot to mention that this is after a "make world" and new kernel :from today (1000 PST). : A checklist for people who want kernel cores: [Matt's check list deleted which I meet] /var/crash must nominally have sufficient space to hold the crash dump (a file of the same size as the amount of memory you have), *and* the kernel image. Normally you give it a lot more space so you store several crash dumps in it at once. Matt, AFAICT, the problem is due to the translation of /dev/da0s1b to major and minor numbers. dumpon takes /dev/da0s1b and translates it to (4,131073) in my case. savecore uses sysctl kern.dumpdev to determine the dump device. kern.dumpdev is set to (13,131073). Thus, dumpon uses bmajor and savecore uses cmajor device numbers. I also note that savecore grovels around in /dev/kmem which scares the heck out of me as far as my hacking abilities go ;-) -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH] note the __sF change in src/UPDATING
Could someone add the following patch to UPDATING? Change the words to whatever suits your fancy. -- Steve http://troutmask.apl.washington.edu/~kargl/ --- UPDATING.orig Wed Nov 6 16:20:05 2002 +++ UPDATINGWed Nov 6 16:27:08 2002 @@ -17,6 +17,15 @@ developers choose to disable these features on build machines to maximize performance. +20021031 + Revision 1.24 of lib/libc/stdio/findfp.c has made __sF static. + This changes the visibility of __sF to a symbol internal to + libc. All applications linked against libc or a library that + depends on libc that were compiled prior to 31 Oct 2002 will + need to be updated after a make world. An error message that + includes undefined reference to `__sF' is an indication that + that application needs to be recompiled. + 20021029: The value of IPPROTO_DIVERT has changed. Make sure to keep your kernel, netstat, natd and any third-party DIVERT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
M. Warner Losh said: In message: [EMAIL PROTECTED] Steven G. Kargl [EMAIL PROTECTED] writes: : Could someone add the following patch to UPDATING? : Change the words to whatever suits your fancy. I'm trying to devise a good way to deal with this breakage and hope it is transient. I'm not hopeful :-( I'll consider adding this to UPDATING. Any user who installed DP1 and a bunch of ports will have a unpleasant experience when they update to post 20021031 sources. All their ports will stop working and it isn't a simple matter to update those ports. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
M. Warner Losh said: In message: [EMAIL PROTECTED] Steven G. Kargl [EMAIL PROTECTED] writes: : M. Warner Losh said: : In message: [EMAIL PROTECTED] : Steven G. Kargl [EMAIL PROTECTED] writes: : : Could someone add the following patch to UPDATING? : : Change the words to whatever suits your fancy. : : I'm trying to devise a good way to deal with this breakage and hope it : is transient. I'm not hopeful :-( I'll consider adding this to UPDATING. : : : Any user who installed DP1 and a bunch of ports will : have a unpleasant experience when they update to : post 20021031 sources. All their ports will stop : working and it isn't a simple matter to update : those ports. I thought DP1 didn't generate binaries or libraries that contained __sF. http://www.freebsd.org/releases/5.0R/schedule.html DP1 was released on 5 Apr 2002. This may have occurred during Peter's last attempt at killing __sF. DP2 is in progress according to the web page and __sF should not be present. There will also be that group of -current users who lag a few weeks behind in their buildworlds. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PAM, X11, and su as a normal user? (fwd)
I sent this inquire to freebsd-question, but came up empty with respect to solutions to the problem. I have 2 accounts on my freebsd-current machine. I use startx to start X11 as user kargl. If I then su to user sgk, I cannot fire up X clients. For example, troutmask:kargl[202] su sgk Password: troutmask:sgk[201] gnuplot Terminal type set to 'x11' gnuplot plot sin(x) gnuplot gnuplot: unable to open display 'troutmask.apl.washington.edu:0' gnuplot: X11 aborted. I've tried using xhost sgk@, but this doesn't work. I have also used xauth to ensore that both user kargl and user sgk have the same key in .Xauthority. The only thing I can think of that may need to be configured is PAM, but the documentation is rather incomplete. So, anyone know how to setup su to permit sgk to use X clients? -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAM, X11, and su as a normal user? (fwd)
Pat Lashley wrote: --On Friday, September 05, 2003 23:13:29 -0700 Steven G. Kargl [EMAIL PROTECTED] wrote: I have 2 accounts on my freebsd-current machine. I use startx to start X11 as user kargl. If I then su to user sgk, I cannot fire up X clients. For example, Try 'ssh -X [EMAIL PROTECTED]' instead of 'su kargl'. You shouldn't notice the overhead of the ssh protocol; and its a lot easier than messing around with the X11 authentication cruft. I don't quite understand your suggestion. I login as user kargl. I fire up X11 as user kargl with startx. I use su in a xterm to connect to my alter ego (su sgk). Now, as user sgk I want to use a X11 client such as nedit. AFAICT, it can't be done. If as user kargl, I do ssh -X [EMAIL PROTECTED] to login into the sgk account, I still can not use a X11 client. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAM, X11, and su as a normal user? (fwd)
Brandon S. Allbery KF8NH wrote: On Sat, 2003-09-06 at 02:13, Steven G. Kargl wrote: I have 2 accounts on my freebsd-current machine. I use startx to start X11 as user kargl. If I then su to user sgk, I cannot fire up X clients. For example, Is $XAUTHORITY still set in the subshell? Can both users read the Xauthority file? $XAUTHORITY is not set. Both users use their defaults $HOME/.Xauthority. I used xauth to ensure the key for troutmask is the same for both users. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAM, X11, and su as a normal user? (fwd)
Pat Lashley wrote: --On Saturday, September 06, 2003 00:31:17 -0700 Steven G. Kargl [EMAIL PROTECTED] wrote: I don't quite understand your suggestion. I login as user kargl. I fire up X11 as user kargl with startx. I use su in a xterm to connect to my alter ego (su sgk). Now, as user sgk I want to use a X11 client such as nedit. AFAICT, it can't be done. If as user kargl, I do ssh -X [EMAIL PROTECTED] to login into the sgk account, I still can not use a X11 client. Hmm. That should work fine. I do it all the time. Check the log messages to see if the SSH daemon had any non-fatal complaints. This appears to work now, but I had to delete sgk/.Xauthority and then merge user kargl/.Xauthority into sgk/.Xauthority. Perhaps, the old sgk/.Xauthority was somehow corrupt although xauth appeared to have no problems with it. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAM, X11, and su as a normal user? (fwd)
Brandon S. Allbery KF8NH wrote: On Sat, 2003-09-06 at 03:41, Steven G. Kargl wrote: Brandon S. Allbery KF8NH wrote: On Sat, 2003-09-06 at 02:13, Steven G. Kargl wrote: I have 2 accounts on my freebsd-current machine. I use startx to start X11 as user kargl. If I then su to user sgk, I cannot fire up X clients. For example, Is $XAUTHORITY still set in the subshell? Can both users read the Xauthority file? $XAUTHORITY is not set. Both users use I take this back. $XAUTHORITY was pointing at the wrong .Xauthority file. their defaults $HOME/.Xauthority. I used xauth to ensure the key for troutmask is the same for both users. Then it ought to work. It works now that I that I fixed .cshrc to properly set $XAUTHORITY. Thanks for your help. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] workaround for kern/56869
--- /usr/src/sys/modules/Makefile.orig Tue Sep 16 10:42:38 2003 +++ /usr/src/sys/modules/Makefile Tue Sep 16 10:42:54 2003 @@ -126,7 +126,6 @@ twe \ tx \ txp \ - uart \ ubsa \ ubsec \ ucom \ -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
linux-mozilla not exiting properly (KSE signal fallout?)
David, Julian, I updated my system today after David's KSE signal changes. I'm sure if this is the cause of my problem, but linux-mozilla no longer exits. % linux-mozilla ... browse ... crtl-q % ps | grep mozilla 6032 v0 SL 0:00.02 /bin/sh ./run-mozilla.sh ./mozilla-bin 6037 v0 SL 0:12.16 ./mozilla-bin 6038 v0 SL 0:00.01 ./mozilla-bin % linux-mozilla ... browse ... crtl-q % ps | grep mozilla 6060 p1 SL+0:00.02 /bin/sh ./run-mozilla.sh ./mozilla-bin 6065 p1 SL+0:09.67 ./mozilla-bin 6066 p1 SL+0:00.03 ./mozilla-bin 6032 v0 SL 0:00.02 /bin/sh ./run-mozilla.sh ./mozilla-bin 6037 v0 SL 0:12.16 ./mozilla-bin 6038 v0 SL 0:00.04 ./mozilla-bin % linux-mozilla ... browse ... crtl-q % killall mozilla-bin % ps | grep mozilla 6060 p1 SL+0:00.02 /bin/sh ./run-mozilla.sh ./mozilla-bin 6065 p1 SL+0:09.67 ./mozilla-bin 6066 p1 SL+0:00.04 ./mozilla-bin 6136 p2 RL+0:00.01 grep mozilla 6032 v0 SL 0:00.02 /bin/sh ./run-mozilla.sh ./mozilla-bin 6037 v0 SL 0:12.16 ./mozilla-bin 6038 v0 SL 0:00.05 ./mozilla-bin 6114 v0 SL 0:00.02 /bin/sh ./run-mozilla.sh ./mozilla-bin 6119 v0 SL 0:04.83 ./mozilla-bin 6120 v0 SL 0:00.01 ./mozilla-bin % kill -9 6114 6032 6060 6065 6037 6119 Finally, kills the processes. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel panic in ufs_getattr
I have the core file, kernel, and kernel.debug if
some one needs access let me know. Source is from
9 am PST.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
Script started on Sat Nov 3 12:25:23 2001
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.
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file kernel.0
(kgdb) core-file vmcore.0
IdlePTD 3743744
initial pcb at 29c960
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x78
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01fbaa8
stack pointer = 0x10:0xcea25b78
frame pointer = 0x10:0xcea25b8c
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 = 427 (cvsup)
panic: from debugger
panic: from debugger
Uptime: 9m20s
pfs_vncache_unload(): 1 entries remaining
dumping to dev da0s2b, offset 204960
dump 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236
235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215
214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194
193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173
172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152
151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131
130 129 128 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:492
492 if (!dodump)
(kgdb) where
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:492
#1 0xc0184e63 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:335
#2 0xc0185295 in panic (fmt=0xc0246926 from debugger)
at /usr/src/sys/kern/kern_shutdown.c:634
#3 0xc0134c01 in db_panic (addr=-1071662424, have_addr=0, count=-1,
modif=0xcea259ec ) at /usr/src/sys/ddb/db_command.c:445
#4 0xc0134b9f in db_command (last_cmdp=0xc0271014, cmd_table=0xc0270e44,
aux_cmd_tablep=0xc026a8cc, aux_cmd_tablep_end=0xc026a8d0)
at /usr/src/sys/ddb/db_command.c:342
#5 0xc0134c6b in db_command_loop () at /usr/src/sys/ddb/db_command.c:467
#6 0xc0136f0f in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc0224aaa in kdb_trap (type=12, code=0, regs=0xcea25b38)
at /usr/src/sys/i386/i386/db_interface.c:167
#8 0xc02316e8 in trap_fatal (frame=0xcea25b38, eva=120)
at /usr/src/sys/i386/i386/trap.c:934
#9 0xc0231455 in trap_pfault (frame=0xcea25b38, usermode=0, eva=120)
at /usr/src/sys/i386/i386/trap.c:853
#10 0xc0230e67 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
tf_edi = -827301888, tf_esi = -828220476, tf_ebp = -828220532,
tf_isp = -828220572, tf_ebx = -1052217856, tf_edx = -828220496,
tf_ecx = 6, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1071662424, tf_cs = 8, tf_eflags = 66050,
tf_esp = -1054058240, tf_ss = -827301888})
at /usr/src/sys/i386/i386/trap.c:405
#11 0xc01fbaa8 in ufs_getattr (ap=0xcea25bb0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:425
#12 0xc01fe3d9 in ufs_vnoperate (ap=0xcea25bb0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2658
#13 0xc01c87cf in vn_stat (vp=0xceb06000, sb=0xcea25c8c, td=0xcdfc4304)
at vnode_if.h:231
#14 0xc01c4b5f in lstat (td=0xcdfc4304, uap=0xcea25d20)
at /usr/src/sys/kern/vfs_syscalls.c:2020
#15 0xc0231b94 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 22, tf_esi = 134877984, tf_ebp = 136510260,
tf_isp = -828220044, tf_ebx = 135978460, tf_edx = 136510292,
tf_ecx = 135048721, tf_eax = 190, tf_trapno = 12, tf_err = 2,
tf_eip = 672468493, tf_cs = 31, tf_eflags = 535, tf_esp = 136510236,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1129
#16 0xc0225b0d in syscall_with_err_pushed ()
#17 0x807a90d in ?? ()
#18 0x80606b6 in ?? ()
#19 0x805decc in ?? ()
#20 0x805b8a4 in ?? ()
#21 0x805b443 in ?? ()
#22 0x80cf48d in ?? ()
#23 0x80cf346 in ?? ()
#24 0x80c6f70 in ?? ()
#25 0xe77efb39 in ?? ()
Cannot access memory at address 0x4304c683.
(kgdb) up 10
#10 0xc0230e67 in trap (frame={tf_fs
endless loop with gettimeofday in mozilla
I suspect that this a mozilla problem, but I only recently have run into this. Rebuilt world and kernel from -current sources from Dec 13 16:15 PDT. If I open the mail/news component of mozilla, and try to change the view to only unread messages X11 freezes. Switching to a vty and running truss -p mozilla's pid yields the following endless stream. gettimeofday(0x28254b6c,0x0) = 0 (0x0) sigprocmask(0x3,0x28254bfc,0x0) = 0 (0x0) sigaltstack(0x2825a5e0,0x0) = 0 (0x0) poll(0x8065000,0x2,0x0) = 0 (0x0) sigreturn(0x8058068) = -1077952316 (0xbfbfc0c4) SIGNAL 27 SIGNAL 27 gettimeofday(0x28254b6c,0x0) = 0 (0x0) sigprocmask(0x3,0x28254bfc,0x0) = 0 (0x0) sigaltstack(0x2825a5e0,0x0) = 0 (0x0) poll(0x8065000,0x2,0x0) = 0 (0x0) sigreturn(0x8058068) = -1077952316 (0xbfbfc0c4) SIGNAL 27 SIGNAL 27 Note, this is mozilla built for FreeBSD, not the linux version of mozilla. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
more endian.h breakage; patch included.
There is another patch needed in libdialog. Steve *** /usr/src/lib/libc_r/uthread/uthread_wait4.c.origSun Oct 15 11:16:02 2000 --- /usr/src/lib/libc_r/uthread/uthread_wait4.c Sun Oct 15 11:16:45 2000 *** *** 32,37 --- 32,38 * $FreeBSD: src/lib/libc_r/uthread/uthread_wait4.c,v 1.10 2000/01/29 22:53:54 jasone Exp $ */ #include errno.h + #include sys/types.h #include sys/wait.h #ifdef _THREAD_SAFE #include pthread.h To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
another endian.h causality; patch included
*** /usr/src/gnu/lib/libdialog/prgbox.c.origSun Oct 15 12:44:15 2000 --- /usr/src/gnu/lib/libdialog/prgbox.c Sun Oct 15 12:44:36 2000 *** *** 21,26 --- 21,27 #include dialog.h #include errno.h + #include sys/types.h #include sys/wait.h #include "dialog.priv.h" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
binutils breaks world
This looks like a causality of David's removal of gdb.291.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
makeinfo --no-validate -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/
binutils/gas/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binuti
ls/ld -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/bfd/doc
-I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/binutils -I /u
sr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb.291/gdb/doc -I /usr/src/
gnu/usr.bin/binutils/doc/../../../../contrib/libreadline/doc --no-split -I /usr/
src/gnu/usr.bin/binutils/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../co
ntrib/binutils /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/ld
/ld.texinfo -o ld.info
/usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/ld/ld.texinfo:320
2: warning: Info cannot handle `:' in index entry `:@var{phdr}'.
gzip -cn ld.info ld.info.gz
make: don't know how to make annotate.info. Stop
*** Error code 2
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
post-KSE III kernel panic
I'm not sure this is related to Julian's commit,
but the kernel sources are post-kse III commit.
I have the kernel and core file if more info
or access is needed.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
Script started on Sat Jun 29 18:36:22 2002
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 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-undermydesk-freebsd...
IdlePTD at physical address 0x00474000
initial pcb at physical address 0x0030d5e0
panicstr: bremfree: bp 0xc42aa170 not locked
panic messages:
---
panic: blockable sleep lock (sleep mutex) process lock @
/usr/src/sys/i386/i386/trap.c:726
syncing disks... panic: bremfree: bp 0xc42aa170 not locked
Uptime: 3h48m12s
pfs_vncache_unload(): 3 entries remaining
Dumping 128 MB
16 32 48 64 80 96 112
---
#0 0xc019e78b in doadump ()
(kgdb) bt
#0 0xc019e78b in doadump ()
#1 0xc019ecf0 in boot (howto=260)
#2 0xc019eefb in panic ()
#3 0xc01deb47 in bremfree (bp=0xc42aa170)
#4 0xc01e0906 in vfs_bio_awrite (bp=0xc42aa170)
#5 0xc016f065 in spec_fsync (ap=0xcc2486ec)
#6 0xc016eb58 in spec_vnoperate (ap=0xcc2486ec)
at /usr/src/sys/fs/specfs/spec_vnops.c:837
#7 0xc02354c6 in ffs_sync (mp=0xc0e41400, waitfor=2, cred=0xc0e3c380,
td=0xc02db2c0)
#8 0xc01f0c94 in sync (td=0xc02db2c0, uap=0x0)
#9 0xc019e88f in boot (howto=256)
#10 0xc019eefb in panic ()
#11 0xc01beb57 in witness_lock (lock=0xc1ea8958, flags=8,
file=0xc02c9e49 /usr/src/sys/i386/i386/trap.c, line=726)
#12 0xc0194ef3 in _mtx_lock_flags (m=0xc1ea8958, opts=0,
file=0xc02c9e49 /usr/src/sys/i386/i386/trap.c, line=726)
#13 0xc0284f43 in trap_pfault (frame=0xcc24887c, usermode=0, eva=172)
#14 0xc0284ba3 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1043814600, tf_esi = 0, tf_ebp =
-870020888, tf_isp = -870020952, tf_ebx = -870020860, tf_edx = -870716816, tf_ecx = 0,
tf_eax = -1043814600, tf_trapno = 12, tf_err = 0, tf_eip = -1072069444, tf_cs = 8,
tf_eflags = 66054, tf_esp = -1070728192, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:667
---Type return to continue, or q return to quit---
#15 0xc01984bc in fill_kinfo_proc (p=0xc1c8a738, kp=0xcc248904)
#16 0xc0198a5c in sysctl_out_proc (p=0xc1c8a738, req=0xcc248c10, doingzomb=1)
#17 0xc0198f1e in sysctl_kern_proc (oidp=0xc02e0100, arg1=0x0, arg2=0,
req=0xcc248c10)
#18 0xc01a7f93 in sysctl_root (oidp=0x0, arg1=0xcc248cac, arg2=3,
req=0xcc248c10)
#19 0xc01a820d in userland_sysctl (td=0xc1c77000, name=0xcc248cac, namelen=3,
old=0x0, oldlenp=0xbfbff34c, inkernel=0, new=0x0, newlen=0,
retval=0xcc248ca8)
#20 0xc01a8060 in __sysctl (td=0xc1c77000, uap=0xcc248d14)
#21 0xc02856ba in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = -1077939380, tf_ebp =
-1077939432, tf_isp = -870019724, tf_ebx = 672654268, tf_edx = -1077939328, tf_ecx =
3, tf_eax = 202, tf_trapno = 12, tf_err = 2, tf_eip = 672221579, tf_cs = 31, tf_eflags
= 663, tf_esp = -1077939476, tf_ss = 47})
#22 0xc027691d in syscall_with_err_pushed () at {standard input}:128
#23 0x280d2451 in ?? ()
#24 0x0804b83e in ?? ()
#25 0x0804d346 in ?? ()
#26 0x080492f9 in ?? ()
(kgdb) quit
Script done on Sat Jun 29 18:36:44 2002
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
panic: vm_page_free: freeing wired page
Julian,
You may have fixed over the last few, but I haven't
had a chance to cvsup new sources.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
panic: vm_page_free: freeing wired page
panic: from debugger
Uptime: 39m56s
Dumping 128 MB
16 32 48 64 80 96 112
---
#0 0xc019c5cb in doadump ()
(kgdb) bt
#0 0xc019c5cb in doadump ()
#1 0xc019caa8 in boot (howto=260)
#2 0xc019ccab in panic ()
#3 0xc01369e2 in db_panic ()
#4 0xc0136971 in db_command (last_cmdp=0xc02cc800, cmd_table=0xc02cc620,
aux_cmd_tablep=0xc02c5ff4, aux_cmd_tablep_end=0xc02c5ff8)
#5 0xc0136a68 in db_command_loop ()
#6 0xc01394b8 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:76
#7 0xc026d2a0 in kdb_trap (type=3, code=0, regs=0xcaeefb18)
at /usr/src/sys/i386/i386/db_interface.c:214
#8 0xc027cb34 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -880287744, tf_esi = 256, tf_ebp =
-890307740, tf_isp = -890307772, tf_ebx = 0, tf_edx = 0, tf_ecx = -890308068, tf_eax =
18, tf_trapno = 3, tf_err = 0, tf_eip = -1071196883, tf_cs = 8, tf_eflags = 662,
tf_esp = -1070861153, tf_ss = -1070963908})
at /usr/src/sys/i386/i386/trap.c:667
#9 0xc026d52d in Debugger (msg=0xc02a633c panic)
#10 0xc019cc94 in panic (fmt=0xc02b8ba0 vm_page_free: freeing wired page\n)
#11 0xc024a5e1 in vm_page_free_toq (m=0xc09eb7c0)
#12 0xc0249c34 in vm_page_free (m=0xc09eb7c0)
#13 0xc0278885 in pmap_dispose_thread (td=0xc1e1)
#14 0xc01a6be3 in thread_fini (mem=0xc1e1, size=184)
#15 0xc024f985 in zone_drain (zone=0xc0bb9000)
#16 0xc02504b5 in zone_foreach (zfunc=0xc024f6b0 zone_drain)
#17 0xc02517a7 in uma_reclaim ()
#18 0xc024cc41 in vm_pageout_scan (pass=0)
#19 0xc024da52 in vm_pageout ()
#20 0xc01897dc in fork_exit (callout=0xc024d7f0 vm_pageout, arg=0x0,
frame=0xcaeefd48)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
close PR bin/37795
Can someone close PR bin/37795? I am the originator of the PR, and it no longer applies to current version xinstall. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic from _mutex_assert in kern_lock.c
The source tree was retrieved by cvsup
at 21:47 (PST) on Oct 4.
This is a non-GEOM and non-acpi kernel.
I have the core and kernel.debug, so any
further postmortem is possible.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
panic: from debugger
panic messages:
---
panic: mutex vnode interlock not owned at /usr/src/sys/kern/kern_lock.c:229
panic: from debugger
Uptime: 1m57s
pfs_vncache_unload(): 2 entries remaining
Dumping 128 MB
16 32 48 64 80 96 112
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:223
223 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:223
#1 0xc01ab96a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:355
#2 0xc01abbb3 in panic () at /usr/src/sys/kern/kern_shutdown.c:508
#3 0xc013c3c2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc013c342 in db_command (last_cmdp=0xc02e7d80, cmd_table=0xc02e7ba0,
aux_cmd_tablep=0xc02e04d0, aux_cmd_tablep_end=0xc02e04d4)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc013c456 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc013f0ba in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc028c1a2 in kdb_trap (type=3, code=0, regs=0xc8e6d7b4)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc029c8f7 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1048044496, tf_esi = 256, tf_ebp
= -924395520, tf_isp = -924395552, tf_ebx = 0, tf_edx = 0, tf_ecx = 126, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1071070140, tf_cs = 8, tf_eflags = 658, tf_esp =
-1070749825, tf_ss = -1070840167}) at /usr/src/sys/i386/i386/trap.c:605
#9 0xc028d958 in calltrap () at {standard input}:98
#10 0xc01abb9b in panic (fmt=0xc02c39f4 mutex %s not owned at %s:%d)
at /usr/src/sys/kern/kern_shutdown.c:494
#11 0xc01a226c in _mtx_assert (m=0xc18c0de0, what=9,
file=0xc02c28a0 /usr/src/sys/kern/kern_lock.c, line=229)
at /usr/src/sys/kern/kern_mutex.c:835
#12 0xc019e88b in lockmgr (lkp=0xc18c0ea4, flags=16842754, interlkp=0xc18c0de0,
td=0xc1881c30) at /usr/src/sys/kern/kern_lock.c:229
#13 0xc01f53cc in vop_stdlock (ap=0xc8e6d8c0)
at /usr/src/sys/kern/vfs_default.c:279
#14 0xc0257118 in ufs_vnoperate (ap=0xc8e6d8c0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2715
#15 0xc020965b in vn_lock (vp=0xc18c0de0, flags=65538, td=0xc1881c30)
at vnode_if.h:990
#16 0xc023a555 in ffs_snapshot (mp=0xc1921600, snapfile=---Can't read userspace from
dump, or kernel process---
)
at /usr/src/sys/ufs/ffs/ffs_snapshot.c:409
#17 0xc0247cf8 in ffs_mount (mp=0xc1921600, path=0xc1b31000 /var, data=---Can't read
userspace from dump, or kernel process---
)
at /usr/src/sys/ufs/ffs/ffs_vfsops.c:291
#18 0xc01f97d4 in vfs_mount (td=0xc1881c30, fstype=0xc1929c20 ffs,
fspath=0xc1b31000 /var, fsflags=18944000, fsdata=0xbfbffcc0)
at /usr/src/sys/kern/vfs_mount.c:1062
#19 0xc01f8f98 in mount (td=0xc1881c30, uap=0xc8e6dd10)
at /usr/src/sys/kern/vfs_mount.c:818
#20 0xc029d20e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = -1077936672, tf_ebp =
-1077936824, tf_isp = -924394124, tf_ebx = 135000998, tf_edx = 19, tf_ecx = 135000832,
tf_eax = 21, tf_trapno = 12, tf_err = 2, tf_eip = 134568967, tf_cs = 31, tf_---Type
return to continue, or q return to quit---
eflags = 518, tf_esp = -1077937140, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1050
#21 0xc028d9ad in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
(kgdb) quit
Script done on Sat Oct 5 08:28:03 2002
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic from _mutex_assert in kern_lock.c
Brian F. Feldman said: Steven G. Kargl [EMAIL PROTECTED] wrote: The source tree was retrieved by cvsup at 21:47 (PST) on Oct 4. This is a non-GEOM and non-acpi kernel. I have the core and kernel.debug, so any further postmortem is possible. I think the problem is that in src/sys/ufs/ffs/ ffs_snapshot.c:ffs_snapshot(), as the mnt vnode list is traversed none of the vnodes (xvp) would actually GET VI_LOCK()ed in the first place, and so the LK_INTERLOCK is bogus in the vn_lock() call. Kirk would know for sure what to do about this... I came to the same conclusion after I sent the original email. What I don't understand is how I ended up in ffs_snapshot(), because I don't have a snapshot of /var. I tried snapshots when Kirk first introduced the feature, but I removed all of the snapshots a long time ago. Is there a flag in the superblock that I need to clear? One other point, the machine was doing a background fsck on /var. Does a background fsck go through ffs_snapshot()? -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic from _mutex_assert in kern_lock.c
Robert Watson said: On Sat, 5 Oct 2002, Steven G. Kargl wrote: One other point, the machine was doing a background fsck on /var. Does a background fsck go through ffs_snapshot()? Yes -- the background file system checker creates a snapshot of the file system in the un-checked state, then performs the check against the snapshot. It trickles the changes generated against the snapshot into the live file system. Because of the conservative nature of failures with soft updates, the only theoretical inconsistencies relate either to marked as non-free yet unreferenced resources, and referenece counts that are high. The snapshot allows fsck a consistent view of the file system as it was so that it doesn't get confused by the live file system. Thanks, Brian and Robert. Of course, the above makes sense when someone explains it to you. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic from _mutex_assert in kern_lock.c
Jeff Roberson said: On Sat, 5 Oct 2002, Brian F. Feldman wrote: Steven G. Kargl [EMAIL PROTECTED] wrote: The source tree was retrieved by cvsup at 21:47 (PST) on Oct 4. This is a non-GEOM and non-acpi kernel. I have the core and kernel.debug, so any further postmortem is possible. I think the problem is that in src/sys/ufs/ffs/ ffs_snapshot.c:ffs_snapshot(), as the mnt vnode list is traversed none of the vnodes (xvp) would actually GET VI_LOCK()ed in the first place, and so the LK_INTERLOCK is bogus in the vn_lock() call. Kirk would know for sure what to do about this... Yeah, I broke this. I didn't see the LK_INTERLOCK near by when I removed the interlocking around usecount. I will fix this. I sent Kirk a private email, but I haven't heard back from him. Hopefully, he is watching the freebsd-current mailing list. I'm actually surprise that more people haven't reported this problem. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Rev. 1.48 of stdio.h breaks 3rd part software
This commit by Peter breaks 3rd party software: Revision 1.48 / (download) - annotate - [select for diffs], \ Fri Oct 11 22:38:17 2002 UTC (18 hours, 14 minutes ago) by peter Branch: MAIN Changes since 1.47: +0 -8 lines Diff to previous 1.47 (colored) Zap the early-adopter transition aid before we get into serious 5.0-R territory, as threatened. This only affects antique 5.0 systems that have not had a 'make world' done for well over a year. In particular, NAG's Fortran 95 compiler on longer works. kargl[203] make f95 -O -C=all -o testchkder chkdrv.f90 -L. -lminpack /usr/local/lib/NAGWare/libf96.so: undefined reference to `__sF' collect2: ld returned 1 exit status *** Error code 1 I've tried passing numerous combinations of flags directly to gcc with the -Wc (compiler options) and -Wl (linker options) to f95 (including -L/usr/lib/compat, -nostdlib, and -v). See below for two examples. No amount of gymnastics has worked around this problem. Finally, the NAG compiler was released for 4.x, and it may be difficult to convince 3rd party software vendors to support both 4.x and 5.0. -- Steve http://troutmask.apl.washington.edu/~kargl/ cript started on Sat Oct 12 10:25:53 2002 f95 -O -C=all -o testchkder -Wc,-v -Wl,-v -Wc,-nostdlib -Wl,-nostdlib chkdrv.f90 -L. -L/usr/lib/c ompat -lminpack -lm -lc Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021009 (prerelease) /usr/libexec/cc1 -lang-c -v -I/usr/local/lib/NAGWare -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PA TCHLEVEL__=1 -D__GXX_ABI_VERSION=102 -D__FreeBSD__=5 -D__FreeBSD_cc_version=54 -Dunix -D__KPR INTF_ATTRIBUTE__ -D__FreeBSD__=5 -D__FreeBSD_cc_version=54 -D__unix__ -D__KPRINTF_ATTRIBUTE__ -D__unix -Asystem=unix -Asystem=bsd -Asystem=FreeBSD -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -Acpu=i3 86 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__ -D__ELF__ -D_LONGLONG -DBSD -DANSI_C -DINT64=long long -DPOW_IS_INACCURATE /var/tmp/chkdrv.026087.c -quiet -dumpbase chkdrv.026087.c -O -version -fsigned-char -funroll-loops -o /var/tmp/cc9AAdTR.s GNU CPP version 3.2.1 [FreeBSD] 20021009 (prerelease) (cpplib) (i386 FreeBSD/ELF) GNU C version 3.2.1 [FreeBSD] 20021009 (prerelease) (i386-undermydesk-freebsd) compiled by GNU C version 3.2.1 [FreeBSD] 20021009 (prerelease). ignoring duplicate directory /usr/include #include ... search starts here: #include ... search starts here: /usr/local/lib/NAGWare /usr/include End of search list. /usr/libexec/elf/as -v -o chkdrv.o /var/tmp/cc9AAdTR.s GNU assembler version 2.12.1 [FreeBSD] 2002-07-20 (i386-obrien-freebsd5.0) using BFD version 2.12 .1 [FreeBSD] 2002-07-20 Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021009 (prerelease) /usr/libexec/collect2 -V -dynamic-linker /usr/libexec/ld-elf.so.1 -o testchkder -L. -L/usr/lib/c ompat -L/usr/lib /usr/local/lib/NAGWare/quickfit.o chkdrv.o -lminpack -lm -lc -rpath /usr/local/l ib/NAGWare /usr/local/lib/NAGWare/libf96.so /usr/local/lib/NAGWare/libf96.a -lm /usr/libexec/elf/ld: warning: cannot find entry symbol _start; defaulting to 08048d1c /usr/lib/libc.so: undefined reference to `environ' /usr/lib/libc.so: undefined reference to `__progname' /usr/local/lib/NAGWare/libf96.so: undefined reference to `__sF' GNU ld version 2.12.1 [FreeBSD] 2002-07-20 Supported emulations: elf_i386 collect2: ld returned 1 exit status To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
USER_LDT gone?
With the great libc debacle of 2001, I have not tried
to update my system for about 2 weeks. In that time I
may have missed the commit message that said that USER_LDT, which was needed
for at least wine, was removed.
root[221] cd /usr/src/
root[222] setenv KERNCONF `hostname -s`
root[223] make buildkernel
--
Kernel build for C456086-A started on Thu Feb 22 21:28:18 GMT 2001
--
=== C456086-A
mkdir -p /usr/obj/usr/src/sys
cd /usr/src/sys/i386/conf;
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
config -d /usr/obj/usr/src/sys/C456086-A C456086-A
C456086-A: unknown option "USER_LDT"
*** Error code 1
root[224 find /sys/ -type f | xargs grep USER_LDT
/sys/i386/conf/C456086-A:optionsUSER_LDT#allow user-level
control of i386 ldt
/sys/i386/i386/swtch.s.orig:#ifdef USER_LDT
/sys/i386/linux/linux_machdep.c:printf("linux: modify_ldt needs kernel
option USER_LDT\n");
/sys/i386/svr4/svr4_machdep.c:#if 0 /* USER_LDT */
/sys/i386/svr4/svr4_machdep.c:#if 0 /* USER_LDT */
/sys/i386/svr4/svr4_machdep.c:#warning "USER_LDT doesn't work - are you sure you want
this?"
/sys/modules/svr4/TO-DO: * VM86 and USER_LDT are currently disabled (low-priority)
So, is USER_LDT no longer needed, and will wine work?
--
steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
top, MAXMEM, sysctl, and missing memory?
I've recently upgraded a system to 384 MB of memory, which the system detects during boot. Dmesg reports real memory = 402587648 (393152K bytes) avail memory = 387903488 (378812K bytes) with or without 'options MAXMEM "(384*1024)"' and "sysctl -a | grep hw" reports hw.physmem: 399212544 hw.usermem: 368316416 hw.pagesize: 4096 hw.availpages: 97298 However, if I fire up top(1), she reports Mem: 5390K Active, 5322K Inact, 7627K Wired, 13K Cache, 48M Buf, 76M Free Simply addition of the numbers from top(1) comes to about 141 MB. Looking at top(1) sourcesi shows that she uses the following syctl variables: vm.stats.vm.v_active_count: 5169 vm.stats.vm.v_inactive_count: 5116 vm.stats.vm.v_wire_count: 7550 vm.stats.vm.v_cache_count: 24 vm.stats.vm.v_free_count: 77901 and the total page_count is vm.stats.vm.v_page_count: 95760 which nearly agrees with hw.availpages. It appears that the recent changes to top(1) to use sysctl may have gotten the page size, but I haven't determined where to fix her. So, is the system using all 384 MB of memory or is there another kernel config option to set besides MAXMEM. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
linux module or linux_devtools problem?
The Portland Group's linux Fortran compiler used to work without a problem, but something has changed that I haven't track down. The script(1) log below suggests two possibilities: (1) the translation of linux syscalls to FreeBSD syscalls isn't working; or (2) the linux ld command (see log) needs some additional options. Any suggestions? -- Steve http://troutmask.apl.washington.edu/~kargl/ Script started on Thu Mar 8 12:57:59 2001 /usr/pgi/linux86/bin/pgftn shell.f -x 124 0x1400 -x 122 0x40 -x 119 0x1\ -x 123 0x1000 -x 119 0x80 -x 127 4 -x 124 1 -astype 0 -stdinc /usr/pgi/\ linux86/include:/compat/linux/usr/include:/compat/linux/usr/lib/gcc-lib/\ i386-redhat-linux/egcs-2.91.66//include -opt 1 -x 80 0x300 -y 80 0x1000\ -asm /var/tmp/pgf7737423aaa PGFTN/x86 Linux/x86 Rel 1.7-6.3: compilation successful pgf77: /usr/pgi/linux86/bin/pgftn completed with exit code 0 /compat/linux/usr/bin/as -o shell.o /var/tmp/pgf7737423aaa pgf77: /compat/linux/usr/bin/as completed with exit code 0 Unlinking /var/tmp/pgf7737423aaa Linking: /compat/linux/usr/bin/ld -m elf_i386 -dynamic-linker /compat/linux/lib/\ ld-linux.so.2 -o shell /usr/pgi/linux86/lib/crt1.o /usr/pgi/linux86/lib/\ crti.o /usr/pgi/linux86/lib/pgfmain.o -L/usr/pgi/linux86/lib -L/compat/\ linux/lib -L/compat/linux/usr/lib -L/compat/linux/usr/lib/gcc-lib/\ i386-redhat-linux/egcs-2.91.66/ shell.o -lpgftnrtl -lm -lpgc -lgcc -lc\ -lgcc /usr/pgi/linux86/lib/crtn.o /usr/pgi/linux86/lib/crt1.o: In function `_start': /usr/pgi/linux86/lib/crt1.o(.text+0x40): undefined reference to `__setfpucw' /usr/pgi/linux86/lib/crt1.o(.text+0x48): undefined reference to `__libc_init' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `__stat': stdinit.o(.text+0x2c): undefined reference to `_xstat' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `stat': stdinit.o(.text+0x5c): undefined reference to `_xstat' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `__lstat': stdinit.o(.text+0x8c): undefined reference to `_lxstat' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `lstat': stdinit.o(.text+0xbc): undefined reference to `_lxstat' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `__fstat': stdinit.o(.text+0xec): undefined reference to `_fxstat' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `fstat': stdinit.o(.text+0x11c): undefined reference to `_fxstat' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `__mknod': stdinit.o(.text+0x156): undefined reference to `_xmknod' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `mknod': stdinit.o(.text+0x196): undefined reference to `_xmknod' pgf77: /compat/linux/usr/bin/ld completed with exit code 1 Unlinking Unlinking Unlinking /var/tmp/pgf7737423aaa Unlinking shell Script done on Thu Mar 8 12:58:01 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
diskcheckd goes nuts on /dev/cd0
I'm sure this is pilot error, but ... I updated a pre june 13th current to a july 3 current. Ran mergemaster and installed /etc/diskcheckd.conf without modification. Upon reboot I saw 1000s of the following message streaming up the console: dscheck(cd0): bio_bcount 512 is not on a sector boundary (ssize 2048) Checking /var/log/messages I find (note date and machine name removed): diskcheckd[213]: /dev/cd0 has 2048 byte sectors, may cause minor problems /boot/kernel/kernel: dscheck(cd0): bio_bcount 512 is not on a sector boun dary (ssize 2048) last message repeated 3 times diskcheckd[213]: error reading 512 bytes from sector 0 on /dev/cd0 Variations on the above 5 line fill that last 700 lines of /var/log/messages. I checked src/UPDATING for a diskcheckd HEADS_UP. Nada. Read the diskcheckd and the diskcheckd.conf man pages. So, I'll fix the problem. However, it seems that default settings in diskcheckd.conf that tell diskcheckd to check all kern.disks in system and setting diskcheckd_enable=YES in /etc/defaults/rc.conf without a HEAD-UPS is somewhat alarming. As a side question, why is diskcheckd even looking at at /dev/cd0? From reading the man pages, one would infer that diskcheckd is intended to check for read errors on /dev/daYADA and /dev/adYADA and maybe /dev/fd0. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: diskcheckd goes nuts on /dev/cd0
Ben Smithurst said: Steven G. Kargl wrote: last message repeated 3 times diskcheckd[213]: error reading 512 bytes from sector 0 on /dev/cd0 I was gonna commit a fix for this, but after reporting the problem DES never tested the patch I supplied. :-( I'll commit it later hopefully; se@ did test it and it worked for him... Ah, okay. I checked GNATS and freebsd-current mailing list archive, but I could not locate any relevant PR's or posts. As a side question, why is diskcheckd even looking at at /dev/cd0? Because my only current system when I was writing diskcheckd didn't have a CD drive so I didn't think to tell it not to check them. Sorry... I'll commit a patch soon that allows you to specify drives to exclude, and the default config file will exclude cd*, acd*, and md*. Do you need to special case tape drives, floppies, zip, etc? If so, you might want to exclude all devices except those that start with da and ad. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
modules/joy breaks make world
FYI. The recent commit to move sys/sys/lkm.h to the attic breaks make world is sys/module/joy. 1.19 Mon Apr 19 14:19:52 1999 UTC by peter CVS Tags: HEAD Diffs to 1.18 FILE REMOVED Zap LKM option and support. Farewell old friend. -- Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
panic: mtx_lock() of spin mutex in ip_output.c
I have a Dell 4150 laptop using dhcp and ntpd on the xl0 interface. I did ifconfig xl0 down and received the following panic (hand transcribed :-( ). panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/netinet/ip_output.c:266 Stack backtrace: backtrace() panic() panic: process 414(ntpd):2 Giant but isn't blocked on a mutex In ddb I get, Debugger() panic() propagate_priority() _mtx_lock_sleep() _mtx_lock_flags() softclock() ithread_loop() fork_exit() fork_trampoline() I have a crash dump and kernel.debug if further info is need -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mtx_lock() of spin mutex in ip_output.c
Sam Leffler wrote: On Friday 07 November 2003 12:54 pm, Steve Kargl wrote: On Fri, Nov 07, 2003 at 11:31:45AM -0800, Steven G. Kargl wrote: I have a Dell 4150 laptop using dhcp and ntpd on the xl0 interface. I did ifconfig xl0 down and received the following panic (hand transcribed :-( ). panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/netinet/ip_output.c:266 Stack backtrace: backtrace() panic() panic: process 414(ntpd):2 Giant but isn't blocked on a mutex Make sure you have rev 1.250 of ip_input.c. Okay. I'll update my source tree. This panic occurred for sources circa 31 Oct 03. I'm going to be offline for the next week, so I won't be able to pursue this until then. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
two lock order reversals
lock order reversal 1st 0xc02d9b40 eventhandler @ /usr/src/sys/kern/subr_eventhandler.c:163 2nd 0xc4050008 shutdown_post_sync @ /usr/src/sys/kern/subr_eventhandler.c:116 lock order reversal 1st 0xc882cd00 ithread @ /usr/src/sys/kern/kern_intr.c:187 2nd 0xc02aa0e0 allproc @ /usr/src/sys/kern/kern_fork.c:352 I believe the second is known, but the first appears to be related to the recent eventhandler locking. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
UMA lock order reversal
This is probably a known lock order reversals, but I haven't seen it reported on the mailing list. lock order reversal 1st 0xc403d720 PCPU 4096 (UMA cpu) @ /usr/src/sys/vm/uma_core.c:1179 2nd 0xc403d664 4096 (UMA zone) @ /usr/src/sys/vm/uma_core.c:614 3rd 0xc082a720 PCPU KMAP ENTRY (UMA cpu) @ /usr/src/sys/vm/uma_core.c:1179 -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
savecore: parity error ?
The recent changes to savecore/dumpsys are generating the following message at boot: Checking for core dump: Mediasize = 373293056 Sectorsize = 512 savecore: Parity error on last dump header on /dev/da0s2b -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
bin/cp breaks world
=== bin/cp cc -O -pipe -march=k6 -DVM_AND_BUFFER_CACHE_SYNCHRONIZED -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wformat=2 -Wno-format-extra-args -Werror -c /home/src/bin/cp/cp.c cc1: warnings being treated as errors /home/src/bin/cp/cp.c: In function `copy': /home/src/bin/cp/cp.c:275: warning: deprecated use of label at end of compound statement -- Steve http://troutmask.apl.washington.edu/~kargl/ --- /home/src/bin/cp/cp.c.orig Fri May 10 10:56:22 2002 +++ /home/src/bin/cp/cp.c Fri May 10 10:57:10 2002 @@ -272,6 +272,7 @@ badcp = rval = 1; continue; default: + ; } /* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
fatal trap 21 panic in today's current
I get the following panic (hand transribed): Fatal trap 21: FPU bounds check fault while in kernel mode instruction pointer = 0x8:0xc02433f5 stack pointer= 0x10:c040fc60 frame pointer= 0x10:c040fc7c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 0 (swapper) kernel: type 21 trap, code=0 stopped at bios16+0x1b1: movl $0x16,%edx A trace at the DB prompt gives bios16 pnpbios_identity bus_generic_probe isa_probe_children configure mi_startup begin I did not get a dump because a continue at DB actually permitted the machine to complete the boot process. Note, this panic occurs if I have hint.acpi.0.disable=1 set in /boot/loader.conf. The machine would not boot with ACPI enabled in the May 2002 time frame. If I comment out hint.acpi.0.disable the machine boots fine, so it appears that ACPI can no longer be disabled. dmesg included below. Finally, yes I updated world, kernel, and kernel modules with the new gcc. -- Steve http://troutmask.apl.washington.edu/~kargl/ Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Wed May 1 16:49:56 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TROUTMASK Preloaded elf kernel /boot/kernel/kernel at 0xc03d7000. Preloaded elf module /boot/kernel/linux.ko at 0xc03d70a8. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc03d7154. Preloaded elf module /boot/kernel/snd_ds1.ko at 0xc03d7200. Preloaded elf module /boot/kernel/acpi.ko at 0xc03d72ac. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 141190 Hz CPU: AMD Athlon(tm) Processor (1000.04-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x642 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044RSVD,AMIE,DSP,3DNow! real memory = 402587648 (393152K bytes) avail memory = 386912256 (377844K bytes) Pentium Pro MTRR support enabled VESA: v1.2, 4096k memory, flags:0x0, mode table:0xc00c1bdf (c0001bdf) VESA: S3 Incorporated. 86C325 Using $PIR table, 9 entries at 0xc00fddd0 npx0: math processor on motherboard npx0: INT 16 interface acpi0: VT8371 AWRDACPI on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 acpi_pcib0: Host-PCI bridge port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 xl0: 3Com 3c905-TX Fast Etherlink XL port 0xdc00-0xdc3f irq 11 at device 8.0 on pci0 xl0: Ethernet address: 00:60:97:98:38:65 miibus0: MII bus on xl0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Yamaha DS-1E (YMF724F) mem 0xd900-0xd9007fff irq 11 at device 11.0 on pci0 ahc0: Adaptec 2940 Ultra SCSI adapter port 0xe000-0xe0ff mem 0xd9008000-0xd9008fff irq 15 at device 13.0 on pci0 aic7880: Ultra Single Channel A, SCSI Id=7, 16/253 SCBs pci0: display, VGA at device 17.0 (no driver attached) atspeaker0 port 0x61 on acpi0 fdc0: enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: Option ROMs at iomem 0xc8000-0xcc7ff,0xc-0xc7fff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 8 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec Waiting 15 seconds for SCSI devices to settle acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% sa0 at ahc0 bus 0 target 5 lun 0 sa0: DEC DLT2000 8B37 Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 15) cd0 at ahc0 bus 0 target 4 lun 0 cd0: DEC RRD45 (C) DEC 1645 Removable CD-ROM SCSI-2 device cd0: 4.237MB/s transfers (4.237MHz, offset 15) cd0: cd present [785028 x 512 byte records] da2 at ahc0 bus 0
patch to add athlon to bsd.cpu.mk
This applies to post gcc 3.1 upgrades.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
--- bsd.cpu.mk.orig Sat May 11 11:57:01 2002
+++ bsd.cpu.mk Sat May 11 12:00:49 2002
@@ -22,7 +22,7 @@
. elif ${CPUTYPE} == pentium
CPUTYPE = i586
. elif ${CPUTYPE} == athlon
-CPUTYPE = k7
+CPUTYPE = athlon
. endif
.endif
@@ -32,8 +32,8 @@
.if !defined(NO_CPU_CFLAGS) || !defined(NO_CPU_COPTFLAGS)
. if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
-_CPUCFLAGS = -march=k6 # gcc doesn't support athlon yet, but it will
+. if ${CPUTYPE} == athlon
+_CPUCFLAGS = -march=athlon
. elif ${CPUTYPE} == k6-2
_CPUCFLAGS = -march=k6
. elif ${CPUTYPE} == k6
@@ -83,8 +83,8 @@
# presence of a CPU feature.
.if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
-MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. if ${CPUTYPE} == athlon
+MACHINE_CPU = athlon 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6-2
MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
patches for [x]install
The first patch fixes install(1). The reamining patches
correctly document the breakage of rev 1.55 of xinstall.c
--
Steve
http://troutmask.apl.washington.edu/~kargl/
--- usr.bin/xinstall/xinstall.c.origThu Jun 6 22:45:29 2002
+++ usr.bin/xinstall/xinstall.c Fri Jun 7 17:55:44 2002
@@ -173,8 +173,11 @@
argv += optind;
/* some options make no sense when creating directories */
- if ((safecopy || docompare || dostrip) dodir)
- usage();
+ if (dodir) {
+ safecopy = 0;
+ docompare = 0;
+ dostrip = 0;
+ }
/* must have at least two arguments, except when creating directories */
if (argc 2 !dodir)
--- share/examples/etc/make.conf.orig Fri Jun 7 18:01:36 2002
+++ share/examples/etc/make.confFri Jun 7 18:01:58 2002
@@ -73,9 +73,6 @@
# be the highest optimization value used.
#WANT_FORCE_OPTIMIZATION_DOWNGRADE=1
#
-# Compare before install
-#INSTALL=install -C
-#
# Mtree will follow symlinks
#MTREE_FOLLOWS_SYMLINKS= -L
#
--- share/man/man5/make.conf.5.orig Fri Jun 7 18:02:30 2002
+++ share/man/man5/make.conf.5 Fri Jun 7 18:03:46 2002
@@ -130,14 +130,6 @@
.Dq Li +=
instead of
.Dq Li = .
-.It Va INSTALL
-.Pq Vt str
-the default install command.
-To have commands compared before doing
-the install, use
-.Bd -literal -offset indent
-INSTALL=install -C
-.Ed
.It Va LOCAL_DIRS
.Pq Vt str
List any directories that should be entered when doing
--- share/mk/sys.mk.origFri Jun 7 18:05:26 2002
+++ share/mk/sys.mk Fri Jun 7 18:06:13 2002
@@ -67,7 +67,7 @@
.endif
EFLAGS ?=
-INSTALL?= install
+INSTALL= install
LEX?= lex
LFLAGS ?=
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: patches for [x]install
J. Mallett said: * From Steven G. Kargl [EMAIL PROTECTED] The first patch fixes install(1). The reamining patches correctly document the breakage of rev 1.55 of xinstall.c I should have stated that if the first patch isn't acceptable, then the remaining patches should be applied. The last patch is wrong, the others are good, though a warning about the overriding of flags might be nice until this is ACCEPTED behaviour by the user community. The third patch is wrong because there are things other than -C that one might want to override INSTALL with, for example an INSTALL that uses a replacement program that static relinks an executable being installed to a partition where its dynamic dependencies are not satisfied. No. The third patch is correct (see below); otherwise I could set INSTALL to install -C QED. I've known people to do similar. --- share/mk/sys.mk.origFri Jun 7 18:05:26 2002 +++ share/mk/sys.mk Fri Jun 7 18:06:13 2002 @@ -67,7 +67,7 @@ .endif EFLAGS ?= -INSTALL?= install +INSTALL= install LEX?= lex LFLAGS ?= -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: patches for [x]install
J. Mallett said: * From Steven G. Kargl [EMAIL PROTECTED] J. Mallett said: No. The third patch is correct (see below); otherwise I could set INSTALL to install -C QED. And I could set BINOWN to something bogus. Don't protect the user by removing functionality. Well, if the first patch is acceptable, then we would be restoring documented functionality; otherwise, rev 1.55 of xinstall.c will remove functionality. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in g_vfs_strategy()
On Wed, Jun 22, 2016 at 11:15:27AM +0300, Andriy Gapon wrote: > On 22/06/2016 01:04, Steve Kargl wrote: > > After a forced umount of a msdos filesystem, I received > > a panic. I have the kernel and vmcore. The first hundred > > or so lines of core.txt.4 follow my .sig. > > > > It seems that this problem might have the same root cause as this bug > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210316 > so it could be worth while following up there. > > BTW, some mail user agents render signatures (and, by extension, > anything that follows them) in a much less readable way than a regular > message text. > Thanks for the pointer to the bug. Yes, I think my panic is the same as yours. Checking /var/log/messages I find errors of the form Jun 21 14:14:39 troutmask kernel: g_vfs_done():da1s1[WRITE(\ offset=-1099375943680, length=32768)]error = 5 Inspection of the FAT32 msdosfs showed about 1 TB of disk space used. I suspect, but can't prove, I hit a filesystem limit. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Who broke world and how to fix?
On Thu, Jul 21, 2016 at 03:50:48PM -0400, Michael Butler wrote:
> On 07/21/16 14:32, Steve Kargl wrote:
> > Updating uname -a
> > FreeBSD 11.0-ALPHA5 FreeBSD 11.0-ALPHA5
> > #3 r302248: Tue Jun 28 10:11:31 PDT 2016
> > data/obj/usr/src/sys/SPEW amd64
> >
> > to top-of-tree
> >
> > ===> lib/libsbuf (obj,all,install)
> > cc -O2 -pipe -MD -MF.depend.subr_prf.o -MTsubr_prf.o -std=gnu99 \
> > -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k \
> > -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes \
> > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch \
> > -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline \
> > -Wnested-externs -Wredundant-decls -Wold-style-definition \
> > -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety \
> > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable \
> > -Qunused-arguments -c /usr/src/lib/libsbuf/../../sys/kern/subr_prf.c \
> > -o subr_prf.o
> > /usr/src/lib/libsbuf/../../sys/kern/subr_prf.c:1209:7: error: implicit
> > declaration of function 'atomic_cmpset_int' is invalid in C99
> > [-Werror,-Wimplicit-function-declaration]
> > if (atomic_cmpset_int(counter, c, c - 1)) {
> > ^
> >
>
> It's fixed at and after SVN r303155,
>
Thanks. I found r303155 about 5 minutes ago after scurry to
the svn-src-head mailing list.
Now, if only the guilty party would fix 'make buildkernel'.
--- kernel.full ---
linking kernel.full
cam_xpt.o: In function `xpt_announce_periph':
/usr/src/sys/cam/cam_xpt.c:1037: undefined reference to `nvme_print_ident'
cam_xpt.o: In function `xpt_denounce_periph':
/usr/src/sys/cam/cam_xpt.c:1092: undefined reference to `nvme_print_ident'
cam_xpt.o: In function `xpt_run_devq':
/usr/src/sys/cam/cam_xpt.c:3331: undefined reference to `nvme_op_string'
/usr/src/sys/cam/cam_xpt.c:3331: undefined reference to `nvme_cmd_string'
cam_xpt.o: In function `xpt_bus_register':
/usr/src/sys/cam/cam_xpt.c:3927: undefined reference to `nvme_get_xport'
*** [kernel.full] Error code 1
Two-for-two today.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD12-RC2 and bluetooth?
On Thu, Sep 15, 2016 at 06:20:06PM -0700, Adrian Chadd wrote: > hi, > > bluetooth uses netgraph. > Yeah, I figured that much out. I do not need bluetooth nor netgraph. How does one explicitly disable this (other than through the BIOS)? -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD12-RC2 and bluetooth?
On Fri, Sep 16, 2016 at 02:07:38PM +0900, Takanori Watanabe wrote: > On Thu, Sep 15, 2016 at 07:20:39PM -0700, Steven G. Kargl wrote: > > On Thu, Sep 15, 2016 at 06:20:06PM -0700, Adrian Chadd wrote: > > > hi, > > > > > > bluetooth uses netgraph. > > > > Yeah, I figured that much out. I do not > > need bluetooth nor netgraph. How does > > one explicitly disable this (other than > > through the BIOS)? > > > devd(8) automatically load them. > Remove /etc/devd/usb.conf . > (I really hate the behavior .:-P) Ah, that's one *.conf file that I did not read through. Thanks for the pointer. I'll see if I can disable bluetooth in that file. -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System hangs at boot in xhci0
On Fri, Dec 09, 2016 at 11:58:21PM +0100, Hans Petter Selasky wrote: > On 12/09/16 22:09, Steve Kargl wrote: > > I updated my system to > > > > % svn info /usr/src > > Revision: 309748 > > > > Built a shiny new kernel, which hangs during boot. > > There is no panic. Using the dmesg from kernel.old/kernel, > > the last few reported are > > > > > > pci2: on pcib2 > > xhci0: mem 0xfe90-0xfe900fff > > irq 48 at device 0.0 on pci2 > > xhci0: 32 bytes context size, 64-bit DMA > > > > At this point, the system is completely unresponse and > > needs to be power cycled. > > > > Hi, > > What is the next message in the old kernel which is printed? There has > been zero changes in the XHCI driver recently. > > Can you copy /boot/kernel.old to /boot/kernel.works > > Then add this option to the GENERIC kernel config: > > options VERBOSE_SYSINIT > > What are the last few messages in dmesg when you boot with the above flag? > With a boot_verbose of the new kernel I get the following output: xhci0: 32 bytes context size, 64-bit DMA xhci0: attempting to allocate 1 MSI vectors (4 supported) msi: routing MSI IRQ 260 to local APIC 16 vector 55 xhci0: using IRQ 260 for MSI xhci0: MSI enabled usbus0 on xhci0 xhci0: usbpf: Attached random: harvesting attach, 8 bytes (4 bits) from usbus0 random: harvesting attach, 8 bytes (4 bits) from xhci0 random: harvesting attach, 8 bytes (4 bits) from pci2 random: harvesting attach, 8 bytes (4 bits) from pcib2 and then the system locks up. With the old kernel (circa Oct 10th sources), next few lines from dmesg are pcib3: irq 54 at device 10.0 on pci0 pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib3 pcib0: allocated type 3 (0xfe80-0xfe8f) for rid 20 of pcib3 pcib3: domain0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode0xd000-0xdfff pcib3: memory decode 0xfe80-0xfe8f pci3: on pcib3 I think that hang isn't caused by xhci, but rather is a victim on being the last successfully probed device. In the last weeks there have been a few commits (309588, 309400, and 308953) that touched ACPI. I'm currently reverting these changes to test if one is causing the problem. I did see that one of these revisions specific mentions the ALASKA AMI bios, which I happen to have. However, that commit also mentions a skylake processor while I have an AMD FX-8350. -- Steve http://troutmask.apl.washington.edu/~kargl/ https://www.youtube.com/watch?v=6hwgPfCcpyQ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System hangs at boot in xhci0
On Fri, Dec 09, 2016 at 03:45:30PM -0800, Steven G. Kargl wrote: > On Fri, Dec 09, 2016 at 11:58:21PM +0100, Hans Petter Selasky wrote: > > On 12/09/16 22:09, Steve Kargl wrote: > > > I updated my system to > > > > > > % svn info /usr/src > > > Revision: 309748 > > > > > > Built a shiny new kernel, which hangs during boot. > > > There is no panic. Using the dmesg from kernel.old/kernel, > > > the last few reported are > > > > > > > > > pci2: on pcib2 > > > xhci0: mem 0xfe90-0xfe900fff > > > irq 48 at device 0.0 on pci2 > > > xhci0: 32 bytes context size, 64-bit DMA > > > > > > At this point, the system is completely unresponse and > > > needs to be power cycled. > > > > > > > Hi, > > > > What is the next message in the old kernel which is printed? There has > > been zero changes in the XHCI driver recently. > > > > Can you copy /boot/kernel.old to /boot/kernel.works > > > > Then add this option to the GENERIC kernel config: > > > > options VERBOSE_SYSINIT > > > > What are the last few messages in dmesg when you boot with the above flag? > > > > With a boot_verbose of the new kernel I get the following output: > > xhci0: 32 bytes context size, 64-bit DMA > xhci0: attempting to allocate 1 MSI vectors (4 supported) > msi: routing MSI IRQ 260 to local APIC 16 vector 55 > xhci0: using IRQ 260 for MSI > xhci0: MSI enabled > usbus0 on xhci0 > xhci0: usbpf: Attached > random: harvesting attach, 8 bytes (4 bits) from usbus0 > random: harvesting attach, 8 bytes (4 bits) from xhci0 > random: harvesting attach, 8 bytes (4 bits) from pci2 > random: harvesting attach, 8 bytes (4 bits) from pcib2 > > and then the system locks up. With the old kernel (circa > Oct 10th sources), next few lines from dmesg are > > pcib3: irq 54 at device 10.0 on pci0 > pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib3 > pcib0: allocated type 3 (0xfe80-0xfe8f) for rid 20 of pcib3 > pcib3: domain0 > pcib3: secondary bus 3 > pcib3: subordinate bus 3 > pcib3: I/O decode0xd000-0xdfff > pcib3: memory decode 0xfe80-0xfe8f > pci3: on pcib3 > > I think that hang isn't caused by xhci, but rather is a > victim on being the last successfully probed device. In the last > weeks there have been a few commits (309588, 309400, and 308953) > that touched ACPI. I'm currently reverting these changes to test > if one is causing the problem. > > I did see that one of these revisions specific mentions the > ALASKA AMI bios, which I happen to have. However, that commit > also mentions a skylake processor while I have an AMD FX-8350. > Well, I reverted each of the above indicated revisions. No luck. New kernel still locks up. I guess it's time to do a bisection. Unfortunately, this cross a llvm 3.8 to 3.9 boundary. :( -- Steve http://troutmask.apl.washington.edu/~kargl/ https://www.youtube.com/watch?v=6hwgPfCcpyQ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Revision 309657 to stack_machdep.c renders unbootable system
On Wed, Dec 14, 2016 at 02:10:48PM -0800, Mark Johnston wrote: > On Wed, Dec 14, 2016 at 12:14:16PM -0800, Mark Johnston wrote: > > On Wed, Dec 14, 2016 at 11:49:26AM -0800, Steven G. Kargl wrote: > > > Well, after 3 days of bisection, I finally found the commit > > > that renders my system unbootable. The system does not panic. > > > It simply gets stuck in some state. Nonfunctional keyboard, > > > so can't break into debugger. No serial console available. > > > The verbose dmesg.boot for a working kernel from revision > > > 309656 is at > > > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/dmesg.309656.txt > > > > > > The kernel config file is at > > > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/SPEW.txt > > > > > > In looking at /usr/src/UPDATING, there is no warning that one > > > can create a boat anchor by upgrading to 309657. If compiling > > > a kernel with 'options DDB' is no longer supported, this should > > > be stated in UPDATING. Or, UPDATING should state that 'options > > > DDB' requires 'options STACK'. Or, 'options DDB' should simply > > > to the right thing and pull in whatever 'option STACK' does. > > > > It is supported though - the point of that change was to fix a problem > > that occurred when DDB is configured but STACK isn't. While testing I > > tried every combination of the two options, and I just tried and > > successfully booted a kernel with DDB and !STACK. > > > > Does the kernel boot successfully if STACK is added to your > > configuration? > > I tried your config (plus virtio drivers) and was able to reproduce the > hang in bhyve. Adding STACK "fixed" the hang, as did reverting part of > my change to re-add dead code into the kernel. My VM was always hanging > after printing > > 000.50 [ 426] vtnet_netmap_attach virtio attached txq=1, txd=1024 > rxq=1, rxd=1024 > > Sure enough, removing "device netmap" from your config also fixes the > hang. When the hang occurs, I can see with "bhyvectl --get-rip" that > we're stuck in DELAY(), but I can't get a stack at that point. I think > my change is an innocent bystander - it just happened to expose a latent > issue elsewhere. > > I don't have much more time to look at this right now, but I'll look > into it more tonight. Yes, adding STACK got me to a booting kernel. I can't remember why I added netmap to my config file. Re-adding dead code seems to point to some memory corruption issue or a rogue pointer. :( BTW, I think it would be prudent to add something like 20161206: At revision 309657, 'options STACK' was introduced into sys/x86/x86/mstack_machdep.c. Old kernel configuration files that included 'options DDB' are now required to include also 'options STACK'. to UPDATING or some such wording. I was jumping from circ Oct 10th world to top of tree, and got caught by ~3000 commits. Oh, and thanks for the work you've done on FreeBSD. -- Steve http://troutmask.apl.washington.edu/~kargl/ https://www.youtube.com/watch?v=6hwgPfCcpyQ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Revision 309657 to stack_machdep.c renders unbootable system
Well, after 3 days of bisection, I finally found the commit that renders my system unbootable. The system does not panic. It simply gets stuck in some state. Nonfunctional keyboard, so can't break into debugger. No serial console available. The verbose dmesg.boot for a working kernel from revision 309656 is at http://troutmask.apl.washington.edu/~kargl/freebsd/dmesg.309656.txt The kernel config file is at http://troutmask.apl.washington.edu/~kargl/freebsd/SPEW.txt In looking at /usr/src/UPDATING, there is no warning that one can create a boat anchor by upgrading to 309657. If compiling a kernel with 'options DDB' is no longer supported, this should be stated in UPDATING. Or, UPDATING should state that 'options DDB' requires 'options STACK'. Or, 'options DDB' should simply to the right thing and pull in whatever 'option STACK' does. -- Steve http://troutmask.apl.washington.edu/~kargl/ https://www.youtube.com/watch?v=6hwgPfCcpyQ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Revision 309657 to stack_machdep.c renders unbootable system
On Wed, Dec 14, 2016 at 04:50:21PM -0800, Mark Johnston wrote: > On Wed, Dec 14, 2016 at 03:48:04PM -0800, Steven G. Kargl wrote: > > On Wed, Dec 14, 2016 at 02:10:48PM -0800, Mark Johnston wrote: > > > On Wed, Dec 14, 2016 at 12:14:16PM -0800, Mark Johnston wrote: > > > > On Wed, Dec 14, 2016 at 11:49:26AM -0800, Steven G. Kargl wrote: > > > > > Well, after 3 days of bisection, I finally found the commit > > > > > that renders my system unbootable. The system does not panic. > > > > > It simply gets stuck in some state. Nonfunctional keyboard, > > > > > so can't break into debugger. No serial console available. > > > > > The verbose dmesg.boot for a working kernel from revision > > > > > 309656 is at > > > > > > > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/dmesg.309656.txt > > > > > > > > > > The kernel config file is at > > > > > > > > > > http://troutmask.apl.washington.edu/~kargl/freebsd/SPEW.txt > > > > > > > > > > In looking at /usr/src/UPDATING, there is no warning that one > > > > > can create a boat anchor by upgrading to 309657. If compiling > > > > > a kernel with 'options DDB' is no longer supported, this should > > > > > be stated in UPDATING. Or, UPDATING should state that 'options > > > > > DDB' requires 'options STACK'. Or, 'options DDB' should simply > > > > > to the right thing and pull in whatever 'option STACK' does. > > > > > > > > It is supported though - the point of that change was to fix a problem > > > > that occurred when DDB is configured but STACK isn't. While testing I > > > > tried every combination of the two options, and I just tried and > > > > successfully booted a kernel with DDB and !STACK. > > > > > > > > Does the kernel boot successfully if STACK is added to your > > > > configuration? > > > > > > I tried your config (plus virtio drivers) and was able to reproduce the > > > hang in bhyve. Adding STACK "fixed" the hang, as did reverting part of > > > my change to re-add dead code into the kernel. My VM was always hanging > > > after printing > > > > > > 000.50 [ 426] vtnet_netmap_attach virtio attached txq=1, > > > txd=1024 rxq=1, rxd=1024 > > > > > > Sure enough, removing "device netmap" from your config also fixes the > > > hang. When the hang occurs, I can see with "bhyvectl --get-rip" that > > > we're stuck in DELAY(), but I can't get a stack at that point. I think > > > my change is an innocent bystander - it just happened to expose a latent > > > issue elsewhere. > > > > > > I don't have much more time to look at this right now, but I'll look > > > into it more tonight. > > > > Yes, adding STACK got me to a booting kernel. I can't remember > > why I added netmap to my config file. Re-adding dead code seems to > > point to some memory corruption issue or a rogue pointer. :( > > It's not quite that bad, as it turns out. The key is that > adding/removing the dead code changes the ordering of the items in the > sysinit linker set. I discovered that if the ctl(4) module is > initialized before the vtnet driver attaches, the hang occurs, and > reverting my commit results in a sysinit order where vtnet comes > _before_ ctl(4). So my change triggers the problem just because it > happens to perturb something in the compile-time linker. Thanks for the explanation. > The issue actually seems to be in 4BSD, and more specifically in r308564 > and r308565. Switching to ULE or reverting either of those two commits > fixes the hang. Oh, this is bad. The last time I checked (and it has been awhile ago), ULE has/had some very bad performance issues for numerical computations that use OpenMPI (or likely any MPI implementation) if a node becomes oversubscribed. 4BSD at least manages to recover. Thanks for the pointer to r308564 and 65. I'll take a look later tonight as I've managed to break both firefox and chrome during the upgrade. -- Steve http://troutmask.apl.washington.edu/~kargl/ https://www.youtube.com/watch?v=6hwgPfCcpyQ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Revision 309657 to stack_machdep.c renders unbootable system
On Fri, Dec 16, 2016 at 03:19:09PM -0800, John Baldwin wrote:
>
> So the hack in pause() is probably not as necessary now. In particular, I
> think we only need it for thread0, not for other threads. The patch below
> worked for me with SPEW's config:
>
> Index: kern_synch.c
> ===
> --- kern_synch.c (revision 310128)
> +++ kern_synch.c (working copy)
> @@ -321,7 +321,8 @@ pause_sbt(const char *wmesg, sbintime_t sbt, sbint
> if (sbt == 0)
> sbt = tick_sbt;
>
> - if (cold || kdb_active || SCHEDULER_STOPPED()) {
> + if ((cold && curthread == ) || kdb_active ||
> + SCHEDULER_STOPPED()) {
> /*
>* We delay one second at a time to avoid overflowing the
>* system specific DELAY() function(s):
>
>
John,
The above patch fixes the boot issue for me. Thanks for the
quick response.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
2. https://www.youtube.com/watch?v=Py6d6o2jbaE
1. https://www.youtube.com/watch?v=6hwgPfCcpyQ
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Revision 309657 to stack_machdep.c renders unbootable system
On Fri, Dec 16, 2016 at 03:19:09PM -0800, John Baldwin wrote:
>
> So the hack in pause() is probably not as necessary now. In particular, I
> think we only need it for thread0, not for other threads. The patch below
> worked for me with SPEW's config:
>
> Index: kern_synch.c
> ===
> --- kern_synch.c (revision 310128)
> +++ kern_synch.c (working copy)
> @@ -321,7 +321,8 @@ pause_sbt(const char *wmesg, sbintime_t sbt, sbint
> if (sbt == 0)
> sbt = tick_sbt;
>
> - if (cold || kdb_active || SCHEDULER_STOPPED()) {
> + if ((cold && curthread == ) || kdb_active ||
> + SCHEDULER_STOPPED()) {
> /*
>* We delay one second at a time to avoid overflowing the
>* system specific DELAY() function(s):
>
I'll give your patch a try on Monday. I'm heading out the door
for the weekend, and the system that has problems sits in my office.
System is currently rebuilding firefox-50, which seems to have
a penchant for becoming wedged. An unkillable program consuming
~1 GB of memory. :(
--
Steve
http://troutmask.apl.washington.edu/~kargl/
2. https://www.youtube.com/watch?v=Py6d6o2jbaE
1. https://www.youtube.com/watch?v=6hwgPfCcpyQ
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
