Re: panic at shutdown
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: For about a week, I've been getting panics at shutdown, caused by cn_devopen() calling devsw() with a NULL dev argument. I imagine it may be related to recent changes in the console code. If it's of any interest, I have -Dh in my /boot.config. 1. A week? Why, in that time, didn't you let me know of the problem? 2. cvsup to r1.96 of tty_cons.c, which should fix this, but due to lack of testers and the inability to reproduce it here, is unverified. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make installworld failure
=== usr.bin/tip install -c -s -o root -g wheel -m 555 tip /flat/syv/usr/bin /flat/syv/usr/bin/cu - /flat/syv/usr/bin/tip ln: /flat/syv/usr/bin/cu: Operation not permitted *** Error code 1 flat# ls -l /flat/syv/usr/bin/cu -r-sr-sr-x 1 uucp dialer 124384 Oct 21 13:04 /flat/syv/usr/bin/cu flat# /flat/src/usr.bin/tip flat# cvs log Makefile | less [...] total revisions: 10;selected revisions: 10 description: revision 1.7 date: 2001/10/30 21:22:08; author: markm; state: Exp; lines: +1 -1 Make the dirty, rotten hack failsafe and quiet if cu(1) does not exist. I'm sure there is a connection somewhere... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make installworld failure
In message [EMAIL PROTECTED], Poul-Henning Kamp writes:
=== usr.bin/tip
install -c -s -o root -g wheel -m 555 tip /flat/syv/usr/bin
/flat/syv/usr/bin/cu - /flat/syv/usr/bin/tip
ln: /flat/syv/usr/bin/cu: Operation not permitted
*** Error code 1
flat# ls -l /flat/syv/usr/bin/cu
-r-sr-sr-x 1 uucp dialer 124384 Oct 21 13:04 /flat/syv/usr/bin/cu
flat# /flat/src/usr.bin/tip
flat# cvs log Makefile | less
[...]
total revisions: 10;selected revisions: 10
description:
revision 1.7
date: 2001/10/30 21:22:08; author: markm; state: Exp; lines: +1 -1
Make the dirty, rotten hack failsafe and quiet if cu(1) does not exist.
I'm sure there is a connection somewhere...
I should add for completeness:
flat# make -dl install DESTDIR=/
chflags 0 /usr/bin/cu
install -c -s -o root -g wheel -m 555 tip //usr/bin
set /usr/bin/tip /usr/bin/cu; while test $# -ge 2; do l=/$1; shift; t=/$1; shift;
echo $t -\ $l; ln -f $l $t; done; true
//usr/bin/cu - //usr/bin/tip
install -c -o root -g wheel -m 444 tip.1.gz //usr/share/man/man1
set `echo tip.1 cu.1 | sed 's/\.\([^.]*\) /.\1 \1 /g'`; while : ; do case $# in
0) break;; [123]) echo warn: empty MLINK: $1 $2 $3; break;; esac; name=$1; shift;
sect=$1; shift; l=//usr/share/man/man${sect}/$name; name=$1; shift; sect=$1; shift;
t=//usr/share/man/man${sect}/$name; echo ${t}.gz -\ ${l}.gz; rm -f ${t} ${t}.gz;
ln ${l}.gz ${t}.gz; done
//usr/share/man/man1/cu.1.gz - //usr/share/man/man1/tip.1.gz
flat# make -dl install DESTDIR=/flat/syv
chflags 0 /usr/bin/cu
install -c -s -o root -g wheel -m 555 tip /flat/syv/usr/bin
set /usr/bin/tip /usr/bin/cu; while test $# -ge 2; do l=/flat/syv$1; shift;
t=/flat/syv$1; shift; echo $t -\ $l; ln -f $l $t; done; true
/flat/syv/usr/bin/cu - /flat/syv/usr/bin/tip
ln: /flat/syv/usr/bin/cu: Operation not permitted
*** Error code 1
Stop in /flat/src/usr.bin/tip.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: broken read-only paradigm?
ah. thx On Fri, 2 Nov 2001, David O'Brien wrote: On Fri, Nov 02, 2001 at 10:10:08AM -0800, Matthew Jacob wrote: /usr/src/lib/compat/compat4x.alpha /tstsys/alpha/compile/GPLUS yorp.feral.com root make obj all install clean You cannot do this due to make(1) evaluation timming. You need to do: root (make obj make all install clean) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
awk has gone nuts!
Sources are from Saturday morning at 9 am PDT. cp loader.sym loader.bin strip -R .comment -R .note loader.bin cat /usr/src/sys/boot/i386/loader/../../common/help.common /usr/src/sys/boot/i386/loader/help.i386 | awk -f /usr/src/sys/boot/i386/loader/../../common/merge_help.awk loader.help /usr: write failed, file system is full awk: write error on stdout input record number 383, file source line number 92 *** Error code 2 Stop in /usr/src/sys/boot/i386/loader. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 root[233] pwd /usr/obj/usr/src/sys/boot/i386/loader root[234] ls -l loader* -rwxr-xr-x 1 root wheel 151084 Nov 3 09:39 loader.bin* -rw-r--r-- 1 root wheel 632520704 Nov 3 09:50 loader.help -rwxr-xr-x 1 root wheel 180222 Nov 3 09:39 loader.sym* -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
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
Now is the time for making new aquaintances
Take control of your social life and join our community. We offer a great way for busy, interesting and successful people to meet each other in our safe, secure and anonymous environment. Life should be wonderful. Find someone extraordinary to share your adventures with. STOP waiting. START living. GO meet Somebody! CLICK HERE If you have received this message in error click here to be removed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: awk has gone nuts!
On Sat, Nov 03, 2001 at 10:07:21AM -0800, Steve Kargl wrote: strip -R .comment -R .note loader.bin cat /usr/src/sys/boot/i386/loader/../../common/help.common /usr/src/sys/boot/i386/loader/help.i386 | awk -f /usr/src/sys/boot/i386/loader/../../common/merge_help.awk loader.help /usr: write failed, file system is full ^^ awk: write error on stdout input record number 383, file source line number 92 *** Error code 2 your /usr is full, not CURRENT's problem. PGP signature
Re: ouch -- the second controller on Promise-66 is not detected!
On Wed, Oct 31, 2001 at 08:54:35AM +0600, Nickolay Dudorov wrote: With the following patch I can now use all the channels on the HPT366 controller in my ABIT's BP6 mobo. Hmmm... Just a thing I was having troyuble with ... Are you saying that you can now use DMA, not PIO mode with it? I tried your patch, but I still have the same problem with BP6/HPT366: [dmesg output] Nov 3 19:07:53 vogon /boot/kernel/kernel: ata2: at 0xd000 on atapci1 Nov 3 19:07:54 vogon /boot/kernel/kernel: ad4: 19623MB IBM-DTLA-307020 [39870 /16/63] at ata2-master UDMA66 ... Nov 3 19:07:54 vogon /boot/kernel/kernel: ad4: READ command timeout tag=0 serv= 0 - resetting Nov 3 19:07:54 vogon /boot/kernel/kernel: ata2: resetting devices .. done However, if I have something like: hw.ata.ata_dma=0 in /boot/loader.conf everything is fine (except that harddrive is used in PIO mode instead of DMA). Maybe it's my IBM drive that is fooling around?... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: awk has gone nuts!
Date: Sun, 4 Nov 2001 09:43:32 +0800 From: Vanilla I. Shu [EMAIL PROTECTED] On Sat, Nov 03, 2001 at 10:07:21AM -0800, Steve Kargl wrote: strip -R .comment -R .note loader.bin cat /usr/src/sys/boot/i386/loader/../../common/help.common /usr/src/sys/boot/i386/loader/help.i386 | awk -f /usr/src/sys/boot/i386/loader/../../common/merge_help.awk loader.help /usr: write failed, file system is full ^^ awk: write error on stdout input record number 383, file source line number 92 *** Error code 2 your /usr is full, not CURRENT's problem. Actually, it is, but there is a circumvention. The scenario goes like this: * Build -CURRENT with sources from between 30 October - 02 November -- that is, get the-one-true-awk installed as /usr/bin/awk. * Some of the buildworld process uses awk. It is, however (to the best of my knowledge) not built as part of the build tools process; thus, buildworld uses /usr/bin/awk for this. Perhaps changing this is worth consideration, given the events of the past week. * Some of those awk scripts use constructs that gawk accepts and uses. (The POSIX bracket expressions are a notable example, but there appear to be others, such as empty regexes and newline characters as part of a variable's value.) The modes of failure are often such that it is not immediately apparent when a failure has occurred. (I.e., some of the failures are silent.) * The mode of failure for src/sys/boot/common/merge_help.awk, in particular, was that it would sit in a rather tight loop, repetitively outputting the same 2 (or 3, I forget now) lines because of a combination of a silent failure when using the-one-true-awk and a programming error in the script itself (such that in the case that no input records were recognized, it proceeded to enter this tight output loop). A circumvention is to make install awk (assuming the sources you are using are those for gawk) before doing the buildworld. Another is to copy over a version of gawk as /usr/bin/awk before doing the buildworld. Either of these will prevent the problems. If the goal is merely to avoid the out-of-space condition because of the programming error, it suffices to change the initialization of first at src/sys/boot/common/merge_help.awk:11 from first = 0; to first = -1; though that will not solve the other problems. (It would probably be good for that script to terminate with an error condition if, at termination, it discovers that it recognized no input lines.) Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
