Re: HEADS UP: -CURRENT Feature Slush is OVER

[Hellmuth Michaelis]

From the keyboard of David O'Brien:
 On Sun, Mar 17, 2002 at 10:48:53AM +0100, Hellmuth Michaelis wrote:
  Not taking into account (good) technical reasons, i am quite a bit 
  concerned about the increasing tendency to a) use private repositories
  instead of the one and only repository every committer is able to see and
  use and b) and/or use other version control systems instead of the one
  and only every committer is able to use.
 
 Is this for the use of Perforce in this DP snapshot, or in general?

In general.

If there is a way to use the FreeBSD repository with cvs and any other tool
and each user of each tool sees everything which each user of any other tool
also sees, then i'm fine - no problem. As far as i understand, this is not
the case.

So someone or group who wants to use another tool makes a snapshot of the
cvs repository, converts it for their favorite tool and starts to hack
on the newly created tool-specific repository. But the cvs repository users
can't see anything going on there and might be told: don't touch whatever
code in the cvs repository, we are working on it in our tool specific
repository. This is - IMHO - not good for working _together_.

Once i was told hey, commit to -current, all is fine with this. If its
broken for some days thats ok. Its no problem at all, all changes can
be reversed, but at least its in the tree and everyone can see it and
work on it. If someone later finds a better solution, it will be replaced
but in the meantime we got a bit more forward and this is what i like 
in FreeBSD development.

If i had to vote on that, i'd vote for: 

1) the only thing which is relevant is FreeBSD's cvs repository. If 
person A wants to commit solution A into it, commit it; if person A
does not, has not or does not (now) want to commit it then person B
should be allowed to commit solution B in any case at any time (by 
respecting the committers guidelines, good taste and common sense).

2) cvs is FreeBSD's tool to handle the repository. It allows us to
work together on the repository to solve problems together. If there
is a better tool to do the job, either make shure users of all tools
see the same repository at all times, or make shure all developers
can use the new tool and switch tools or leave everything as it is.

I have read core's recent statement on (part) of this subject and i'm
glad about it. I have nothing against (how should i ..) private 
repositories as long as they are not used to prevent others to commit,
work, go forward and collaborate. I hope we will not divided in 
committers using tool A on repository A, tool B on repository B and/or
tool C on repository C with each group yelling at each other to wait
because group X is working on a solution which will make it shortly
into the other repositories.

Again, these are just my 0.0002 EUR ...

hellmuth
-- 
Hellmuth MichaelisTel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
D-22457 Hamburg   WWW   http://www.hcs.de

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic: bwrite: buffer is not busy???

[Dag-Erling Smorgrav]

Alfred Perlstein [EMAIL PROTECTED] writes:
 It was untested. :)  I'm sure you can fix it, I've got to get some
 sleep, let me know if it works for you.

Sure.  Turns out the patch doesn't work, because closef() needs
p-p_fd to be valid.  This is really tricky; you either need to
protect *every* access to p-p_fd with the proc lock, or figure out
some other way of handling things.

fdfree() is currently used in a handful of places:

 - in kern_exec.c, an fdcopy() / fdfree() combo is used to unshare the
   file table in case it is shared (vfork()); this is a waste of time
   unless the table actually *is* shared, which is easy to check.
   This could replaced by a single call to a new function,
   fdunshare(), which checks the reference count and does an fdcopy()
   if it is greater than 1.

 - in kern_exit.c, fdfree() is used to close all file descriptors and
   destroy the table before turning the process into a zombie (this is
   the one that's giving us trouble).  This could be handled by an
   fdclear() function, with the actual destruction of the filedesc and
   its mutex (performed by a new fddestroy() function?) left off until
   the last possible moment, after the process has been removed from
   the process table.

 - in kern_fork.c, one case where an fdcopy() / fdfree() combo is used
   to unshare the file table (see comment above about fdunshare()) and
   one case where fdfree() / fdinit() is used to completely clear the
   file table (RFCFDG case).  The latter could be handled by a new
   fdclear() function.

 - in vfs_aio.c, fdfree() is called once to destroy the aio daemon's
   file table, and twice to dereference the client's file table after
   it has been temporarily borrowed by the aio daemon.  This code
   gives me a headache, for several reasons (one of which is a
   potential race condition similar to the one we're already seeing in
   kern_exit.c; another is its rather cavalier treatment of curproc)

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic: bwrite: buffer is not busy???

[Kris Kennaway]

On Sun, Mar 17, 2002 at 11:16:23PM -0800, Alfred Perlstein wrote:
 * Dag-Erling Smorgrav [EMAIL PROTECTED] [020317 22:55] wrote:
  Alfred Perlstein [EMAIL PROTECTED] writes:
   Please let me know if this works for you.
   [...]
   + PROC_LOCK(td);
  
  *cough* *cough*
  
  :)
 
 It was untested. :)  I'm sure you can fix it, I've got to get some
 sleep, let me know if it works for you.

With the corrected version of that patch (and a patch from Tor to fix
VM deadlocks in green's commit) I got this panic.  DES has been taking
a look at it, but I'm sending it here in case anyone else has insight
too.

Kris

panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x48
fault code  = supervisor write, page not present
instruction pointer = 0x8:0xc01f833c
stack pointer   = 0x10:0xda1a8b4c
frame pointer   = 0x10:0xda1a8b74
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 = 92729 (tail)
trap number = 12
panic: page fault

syncing disks... panic: bwrite: buffer is not busy???
Uptime: 27m34s

dumping to dev ad0b, offset 1051136
dump ata0: resetting devices .. done
510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 
489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 
468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 
447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 
426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 
405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 
384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 
363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 
342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 
321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 
300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 
279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 
258 257 256 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 ../../../kern/kern_shutdown.c:505
505 ../../../kern/kern_shutdown.c: No such file or directory.
b(kgdb) bt
#0  dumpsys () at ../../../kern/kern_shutdown.c:505
#1  0xc020d4b4 in boot (howto=260) at ../../../kern/kern_shutdown.c:337
#2  0xc020d953 in panic (fmt=0xc0376d4b bwrite: buffer is not busy???)
at ../../../kern/kern_shutdown.c:647
#3  0xc0242c3b in bwrite (bp=0xce63eb88) at ../../../kern/vfs_bio.c:747
#4  0xc024404a in vfs_bio_awrite (bp=0xce63eb88) at ../../../kern/vfs_bio.c:1606
#5  0xc01e49e8 in spec_fsync (ap=0xda1a8a08) at ../../../fs/specfs/spec_vnops.c:403
#6  0xc01e45a5 in spec_vnoperate (ap=0xda1a8a08) at ../../../fs/specfs/spec_vnops.c:121
#7  0xc02e818c in ffs_sync (mp=0xc4061400, waitfor=2, cred=0xc145a980, td=0xc03b3000)
at vnode_if.h:441
#8  0xc02505e9 in sync (td=0xc03b3000, uap=0x0) at ../../../kern/vfs_syscalls.c:673
#9  0xc020d100 in boot (howto=256) at ../../../kern/kern_shutdown.c:246
#10 0xc020d953 in panic (fmt=0xc039501e %s) at ../../../kern/kern_shutdown.c:647
#11 0xc03335d0 in trap_fatal (frame=0xda1a8b0c, eva=72) at 
../../../i386/i386/trap.c:851
#12 0xc03332f9 in trap_pfault (frame=0xda1a8b0c, usermode=0, eva=72) at 
../../../i386/i386/trap.c:765
#13 0xc0332d83 in trap (frame={tf_fs = -1001521128, tf_es = -1069678576, tf_ds = 
-635830256,
  tf_edi = -1001489664, tf_esi = 0, tf_ebp = -635794572, tf_isp = -635794632,
  tf_ebx = -1002099200, tf_edx = 4, tf_ecx = -636822144, tf_eax = 4, tf_trapno = 
12, tf_err = 2,
  tf_eip = -1071676612, tf_cs = 8, tf_eflags = 66194, tf_esp = -1002099200, tf_ss 
= 4})
at ../../../i386/i386/trap.c:433
#14 0xc01f833c in kqueue_close (fp=0xc4452e00, td=0xda0add80) at machine/atomic.h:139
#15 

Re: panic: bwrite: buffer is not busy???

[Dag-Erling Smorgrav]

Kris Kennaway [EMAIL PROTECTED] writes:
 With the corrected version of that patch (and a patch from Tor to fix
 VM deadlocks in green's commit) I got this panic.

...which is completely uninteresting, actually, except as proof that
the patch (and my initial analysis) is incorrect.  With the patch
applied, tail(1) will *always* cause this panic; it is a direct and
inevitable consequence of the patch clearing p-p_fd before calling
closef().

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Bad fix for -current breakage

[Ruslan Ermilov]

On Mon, Mar 18, 2002 at 01:02:00AM -0700, M. Warner Losh wrote:
 Note, a real fix would be applied to all the config.* files, and would
 depend on the BOOTSTRAP symbol that we define during the early stages
 of the build.  This is my wimpy fix for people that want a quick fix
 to the problem of building -current on -stable.
 
 Now, to the next breakage in the tree :-)
 
Here's a good one:

%%%
Index: Makefile.inc
===
RCS file: /home/ncvs/src/gnu/usr.bin/perl/Makefile.inc,v
retrieving revision 1.29
diff -u -r1.29 Makefile.inc
--- Makefile.inc16 Mar 2002 21:36:07 -  1.29
+++ Makefile.inc18 Mar 2002 09:19:07 -
@@ -60,8 +60,14 @@
@ln -sf ${PERL5SRC}/writemain.SH writemain.sh
@ln -sf ${PERL5SRC}/regcomp.c regcomp.c
@ln -sf ${PERL5SRC}/regexec.c regexec.c
+.if defined(BOOTSTRAPPING)
+   @sed '/^d_eaccess=/s;define;undef;' \
+   ${PERL5LIBSRC}/config.SH-${OBJFORMAT}.${MACHINE_ARCH} \
+config.sh
+.else
@ln -sf ${PERL5LIBSRC}/config.SH-${OBJFORMAT}.${MACHINE_ARCH} \
config.sh
+.endif
@touch ${.TARGET}
 
 scripts: links
%%%


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic: bwrite: buffer is not busy???

[Dag-Erling Smorgrav]

BTW, I actually ran across a related bug (or possibly the exact same)
about a week ago, but didn't post a stack trace because I thought the
panic might be a consequence of some other patches I was testing.  The
kernel debugging tutorial mwlucas is preparing is based on this stack
trace, though :)

(kgdb) where
#0  dumpsys () at ../../../kern/kern_shutdown.c:505
#1  0xc0143119 in db_fncall (dummy1=0, dummy2=0, dummy3=0,
dummy4=0xe0b749a4  \0048\200%) at ../../../ddb/db_command.c:551
#2  0xc0142f33 in db_command (last_cmdp=0xc0313724, cmd_table=0xc0313544,
aux_cmd_tablep=0xc030df2c, aux_cmd_tablep_end=0xc030df30)
at ../../../ddb/db_command.c:348
#3  0xc0142fff in db_command_loop () at ../../../ddb/db_command.c:474
#4  0xc0145393 in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:72
#5  0xc02ad0f6 in kdb_trap (type=12, code=0, regs=0xe0b74af4)
at ../../../i386/i386/db_interface.c:161
#6  0xc02ba004 in trap_fatal (frame=0xe0b74af4, eva=40)
at ../../../i386/i386/trap.c:846
#7  0xc02b9d71 in trap_pfault (frame=0xe0b74af4, usermode=0, eva=40)
at ../../../i386/i386/trap.c:765
#8  0xc02b9907 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0,
  tf_esi = 0, tf_ebp = -524858548, tf_isp = -524858592,
  tf_ebx = -525288192, tf_edx = 0, tf_ecx = 10, tf_eax = 0,
  tf_trapno = 12, tf_err = 0, tf_eip = -1071645917, tf_cs = 8,
  tf_eflags = 66182, tf_esp = -1070136512, tf_ss = 0})
at ../../../i386/i386/trap.c:433
#9  0xc01ffb23 in vcount (vp=0xe0b0bd00) at ../../../kern/vfs_subr.c:2301
#10 0xc01a5e58 in spec_close (ap=0xe0b74b94)
at ../../../fs/specfs/spec_vnops.c:591
#11 0xc01a55f1 in spec_vnoperate (ap=0xe0b74b94)
at ../../../fs/specfs/spec_vnops.c:121
#12 0xc0207454 in vn_close (vp=0xe0b0bd00, flags=3, cred=0xc32cce00,
td=0xe0a8d360) at vnode_if.h:183
#13 0xc0207fab in vn_closefile (fp=0xc3369080, td=0xe0a8d360)
at ../../../kern/vfs_vnops.c:757
#14 0xc01b1d50 in fdrop_locked (fp=0xc3369080, td=0xe0a8d360)
at ../../../sys/file.h:230
#15 0xc01b155a in fdrop (fp=0xc3369080, td=0xe0a8d360)
at ../../../kern/kern_descrip.c:1538
#16 0xc01b152d in closef (fp=0xc3369080, td=0xe0a8d360)
at ../../../kern/kern_descrip.c:1524
#17 0xc01b114e in fdfree (td=0xe0a8d360) at ../../../kern/kern_descrip.c:1345
#18 0xc01b5173 in exit1 (td=0xe0a8d360, rv=256)
at ../../../kern/kern_exit.c:199
#19 0xc01b4ec2 in sys_exit (td=0xe0a8d360, uap=0xe0b74d20)
at ../../../kern/kern_exit.c:109
#20 0xc02ba2b7 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
  tf_edi = 135227560, tf_esi = 0, tf_ebp = -1077941020,
  tf_isp = -524857996, tf_ebx = -1, tf_edx = 135044144,
  tf_ecx = -1077942116, tf_eax = 1, tf_trapno = 12, tf_err = 2,
  tf_eip = 134865696, tf_cs = 31, tf_eflags = 663, tf_esp = -1077941064,
  tf_ss = 47}) at ../../../i386/i386/trap.c:1049
#21 0xc02ae06d in syscall_with_err_pushed ()
#22 0x80503a5 in ?? ()
#23 0x807024a in ?? ()
#24 0xbfbfffb4 in ?? ()
#25 0x807daaf in ?? ()
#26 0x807d6eb in ?? ()
#27 0x80630c1 in ?? ()
#28 0x8062fed in ?? ()
#29 0x805ea4c in ?? ()
#30 0x8065949 in ?? ()
#31 0x806544d in ?? ()
#32 0x806dc17 in ?? ()
#33 0x80616b7 in ?? ()
#34 0x80613f0 in ?? ()
#35 0x8048135 in ?? ()
(kgdb) up 9
#9  0xc01ffb23 in vcount (vp=0xe0b0bd00) at ../../../kern/vfs_subr.c:2301
2301SLIST_FOREACH(vq, vp-v_rdev-si_hlist, v_specnext)
(kgdb) p *vp
$1 = {v_flag = 8, v_usecount = 2, v_writecount = 1, v_holdcnt = 0,
  v_id = 6985, v_mount = 0x0, v_op = 0xc2d52a00, v_freelist = {tqe_next = 0x0,
tqe_prev = 0xe083de1c}, v_nmntvnodes = {tqe_next = 0xe0b0b700,
tqe_prev = 0xe0b0c024}, v_cleanblkhd = {tqh_first = 0x0,
tqh_last = 0xe0b0bd2c}, v_dirtyblkhd = {tqh_first = 0x0,
tqh_last = 0xe0b0bd34}, v_synclist = {le_next = 0x0, le_prev = 0x0},
  v_numoutput = 0, v_type = VBAD, v_un = {vu_mountedhere = 0x0,
vu_socket = 0x0, vu_spec = {vu_specinfo = 0x0, vu_specnext = {
sle_next = 0x0}}, vu_fifoinfo = 0x0}, v_lastw = 0, v_cstart = 0,
  v_lasta = 0, v_clen = 0, v_object = 0x0, v_interlock = {mtx_object = {
  lo_class = 0xc0335c60, lo_name = 0xc02ef5c1 vnode interlock,
  lo_flags = 196608, lo_list = {stqe_next = 0x0}, lo_witness = 0x0},
mtx_lock = 4, mtx_recurse = 0, mtx_blocked = {tqh_first = 0x0,
  tqh_last = 0xe0b0bd84}, mtx_contested = {le_next = 0x0, le_prev = 0x0},
tsp = {tv_sec = 3584, tv_nsec = 101067509},
file = 0xc02ef50a ../../../kern/vfs_subr.c, line = 1726,
has_trace_time = 0}, v_lock = {lk_interlock = 0xc036e320,
lk_flags = 16777216, lk_sharecount = 0, lk_waitcount = 0,
lk_exclusivecount = 0, lk_prio = 80, lk_wmesg = 0xc02ef5d1 vnlock,
lk_timo = 6, lk_lockholder = -1}, v_vnlock = 0x0, v_tag = VT_NON,
  v_data = 0x0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {
tqh_first = 0x0, tqh_last = 0xe0b0bdd8}, v_dd = 0xe0b0bd00, v_ddid = 0,
  v_pollinfo = 0x0, v_vxproc = 0x0}
(kgdb) up 8
#17 0xc01b114e in fdfree (td=0xe0a8d360) at 

Re: World on -stable is busted

[Mark Murray]

Hi

I put up a patch to test this yesterday.

Go to src/gnu/usr.bin/libperl, and in appropriate config*, find the
d_eaccess= line, and change it to 'undef'.

Please let me know if that works.

M

 cc -O -pipe  -I/usr/obj/home/imp/FreeBSD/src/gnu/usr.bin/perl/miniperl 
-I/home/imp/FreeBSD/src/gnu/usr.bin/perl/miniperl/../../../../contrib/perl5 
-DPERL_EXTERNAL_GLOB -DPERL_CORE -DAPPLLIB_EXP=\/usr/libdata/perl/BSDPAN\ 
-L/usr/obj/home/imp/FreeBSD/src/gnu/usr.bin/perl/miniperl/../libperl -static -o 
miniperl miniperlmain.o perl.o gv.o toke.o perly.o op.o regcomp.o dump.o util.o mg.o 
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o 
utf8.o taint.o universal.o xsutils.o globals.o perlio.o  -lm -lcrypt -lutil
 pp_sys.o: In function `Perl_pp_fteread':
 pp_sys.o(.text+0x5f57): undefined reference to `eaccess'
 pp_sys.o: In function `Perl_pp_ftewrite':
 pp_sys.o(.text+0x6023): undefined reference to `eaccess'
 pp_sys.o: In function `Perl_pp_fteexec':
 pp_sys.o(.text+0x60ef): undefined reference to `eaccess'
 *** Error code 1
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Bad fix for -current breakage

[Mark Murray]

  Now, to the next breakage in the tree :-)
  
 Here's a good one:

YES!! Excellent! Please commit this.

M

 %%%
 Index: Makefile.inc
 ===
 RCS file: /home/ncvs/src/gnu/usr.bin/perl/Makefile.inc,v
 retrieving revision 1.29
 diff -u -r1.29 Makefile.inc
 --- Makefile.inc  16 Mar 2002 21:36:07 -  1.29
 +++ Makefile.inc  18 Mar 2002 09:19:07 -
 @@ -60,8 +60,14 @@
   @ln -sf ${PERL5SRC}/writemain.SH writemain.sh
   @ln -sf ${PERL5SRC}/regcomp.c regcomp.c
   @ln -sf ${PERL5SRC}/regexec.c regexec.c
 +.if defined(BOOTSTRAPPING)
 + @sed '/^d_eaccess=/s;define;undef;' \
 + ${PERL5LIBSRC}/config.SH-${OBJFORMAT}.${MACHINE_ARCH} \
 +  config.sh
 +.else
   @ln -sf ${PERL5LIBSRC}/config.SH-${OBJFORMAT}.${MACHINE_ARCH} \
   config.sh
 +.endif
   @touch ${.TARGET}
  
  scripts: links
 %%%
 
 
 Cheers,
 -- 
 Ruslan ErmilovSysadmin and DBA,
 [EMAIL PROTECTED] Sunbay Software AG,
 [EMAIL PROTECTED]FreeBSD committer,
 +380.652.512.251  Simferopol, Ukraine
 
 http://www.FreeBSD.orgThe Power To Serve
 http://www.oracle.com Enabling The Information Age
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

$B7HBS5a?M>pJs%5!<%S%9!!(B

[$B7HBS5a?M>pJs%5!<%S%9(B]

$B7HBS5a?M>pJs%5!<%S%9!!L5NA%-%c%s%Z!<%s$N$*CN$i$;(B

$B$46=L#$N$J$$>pJs$G$7$?$i@?$K$*!W$K!!G[?.ITMW!!$H=q$-$4JV?.2<$5$$!#(B
ML$B$+$i:o=|$5$l$^$9!#$b$7$b%a!<%k$,=EJ#$7$?(B
$B>l9g$O$4MFpJs$rC5$;$^$9!#(B
$BJXMx$5$r0lEYpJs%5!<%S%9!JM-!K(B
$BEl5~ET3k>~6h>.4d#1CzL\#2#2HV#1#09f(B
e-mail [EMAIL PROTECTED]
HP http://www.kkjs.com/




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

HEADS UP: OpenSSH 3.1 imported

[Dag-Erling Smorgrav]

I just imported OpenSSH 3.1.  It seems to build and work right, but it
was a bitch to merge, and I'm bound to have botched something royally
somewhere.  Drop me a note if something breaks.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Patch to fix the build of the smbfs.ko kernel module

[Maxime Henrion]

Hajimu UMEMOTO wrote:
 Hi,
 
  On Sun, 17 Mar 2002 15:38:48 -0800
  Maxime Henrion [EMAIL PROTECTED] said:
 
 mux Actually, this patch is wrong because it won't ever compile des_enc.S.
 mux Whatever I do, des_enc.c gets compiled and I can't figure out how to
 mux compile a .S file with bsd.kmod.mk.  If someone with more make(1) clue
 mux than me could help out, that would be appreciated.
 
 Did you make sure to do make depend after changing your Makefile?
 I tried it and I could reproduce your problem with `make buildkernel
 NOCLEAN=YES NO_KERNELDEPEND=YES'.  Then, I tried with `make
 buildkernel NOCLEAN=YES', and the problem was gone.

Oops.  You are entirely right :-)  Do you agree with the attached patch ?
I just changed ${.CURDIR}/../../crypto/des/arch/i386 to
${.CURDIR}/../../crypto/des/arch/${MACHINE_ARCH} in the .PATH directive
since make(1) is not whining about non-existing directories, and this
will allow to only modify the Makefile in one place when adding new
assembly des_enc.S files.  I'll commit it if it's fine with you.

Maxime


Index: Makefile
===
RCS file: /home/ncvs/src/sys/modules/smbfs/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- Makefile11 Jan 2002 15:48:57 -  1.4
+++ Makefile18 Mar 2002 11:11:59 -
@@ -1,6 +1,7 @@
 # $FreeBSD: src/sys/modules/smbfs/Makefile,v 1.4 2002/01/11 15:48:57 ru Exp $
 
 .PATH: ${.CURDIR}/../../crypto/des \
+   ${.CURDIR}/../../crypto/des/arch/${MACHINE_ARCH} \
${.CURDIR}/../../kern \
${.CURDIR}/../../libkern \
${.CURDIR}/../../netsmb \
@@ -22,6 +23,11 @@
 
 .if defined(NETSMBCRYPTO)
 SRCS+= des_ecb.c des_setkey.c
+.if ${MACHINE_ARCH} == i386
+SRCS+= des_enc.S
+.else
+SRCS+= des_enc.c
+.endif
 .endif
 
 # Build with IPX support (1|0)

dev/usb/uhci.c is messed up again

[Joel M. Baldwin]

/usr/src/sys/dev/usb/uhci.c is messed up again for those
of us that have the kernel compiled with UHCI_DEBUG.  The
following patch appears to get it to at least compile.

problem summary:

1.) uhci_dump_ii is defined twice,
 starting at lines 805 and 920.

2.) a missing ; at the end of line 2764.



805,841d804
 void
 uhci_dump_ii(uhci_intr_info_t *ii)
 {
   usbd_pipe_handle pipe;
   usb_endpoint_descriptor_t *ed;
   usbd_device_handle dev;

 #ifdef DIAGNOSTIC
 #define DONE ii-isdone
 #else
 #define DONE 0
 #endif
   if (ii == NULL) {
   printf(ii NULL\n);
   return;
   }
   if (ii-xfer == NULL) {
   printf(ii %p: done=%d xfer=NULL\n,
  ii, DONE);
   return;
   }
   pipe = ii-xfer-pipe;
   if (pipe == NULL) {
   printf(ii %p: done=%d xfer=%p pipe=NULL\n,
  ii, DONE, ii-xfer);
   return;
   }
   ed = pipe-endpoint-edesc;
   dev = pipe-device;
   printf(ii %p: done=%d xfer=%p dev=%p vid=0x%04x pid=0x%04x 
addr=%d pipe=%p ep=0x%02x attr=0x%02x\n,
  ii, DONE, ii-xfer, dev,
   UGETW(dev-ddesc.idVendor),
   UGETW(dev-ddesc.idProduct),
  dev-address, pipe,
  ed-bEndpointAddress, ed-bmAttributes);
 #undef DONE
 }
2764c2727
   splx(s)
---
   splx(s);


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Patch to fix the build of the smbfs.ko kernel module

[Sheldon Hearn]

On Mon, 18 Mar 2002 03:18:46 PST, Maxime Henrion wrote:

 Oops.  You are entirely right :-)  Do you agree with the attached patch ?

Yes, please go ahead.

Thanks for looking after this.

Ciao,
Sheldon.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: zlib breakage(was cvs commit: src/share/man/man4 ng_pptpgre.4)

[Munehiro Matsuda]

This problem also affects the ports/archivers/rpm, which dumps core 
while trying to install ports/emulators/linux_base.
If it's not fixed, we'd loose linux emulation and mose linux based
applications from 5-CURRENT-DP1.

I reported this problem last week with:
  Message-Id: [EMAIL PROTECTED]
  Subject: problem with libz 1.1.4 when installing linux_base ports
  Date: Sat, 16 Mar 2002 16:21:35 +0900

From: Bruce Evans [EMAIL PROTECTED]
Date: Mon, 18 Mar 2002 13:49:55 +1100 (EST)
::
::This bug affects everything that uses libz of course.  It also breaks
::zgrep.  Try cd /home/ncvs/C*/*logs; zgrep foo *.
::
::On Sun, 17 Mar 2002, Bruce Evans wrote:
::
:: On Sun, 17 Mar 2002, I wrote:
::
::  That may be, but ispell is not man's best friend:
:: 
::  $ man ispell
::  Segmentation fault (core dumped)
:: 
::  The bug seems to be in libz.  Upgrading to the previous version of libz
::  fixes it.
::
:: The following patch (obtained from the upgrade) fixes man ispell
:: (but may break libz).
::
:: %%%
:: Index: infcodes.c
:: ===
:: RCS file: /home/ncvs/src/lib/libz/infcodes.c,v
:: retrieving revision 1.3
:: diff -u -2 -r1.3 infcodes.c
:: --- infcodes.c  11 Mar 2002 22:36:26 -  1.3
:: +++ infcodes.c  17 Mar 2002 02:41:53 -
:: @@ -201,5 +201,5 @@
::  case COPY:  /* o: copying bytes in window, waiting for space */
::f = q - c-sub.copy.dist;
:: -  while (f  s-window) /* modulo window size-while instead */
:: +  if (f  s-window)/* modulo window size-while instead */
::  f += s-end - s-window;/* of if handles invalid distances */
::while (c-len)
:: %%%
::
:: The while loop caused some pointer to become invalid.  I think the bug
:: is really in gcc.  The register hildng 's' seemed to get clobbered to
:: (s-end - s-window) so 's' was invalid after 1 iteration.  With an
:: if instead of a while, gcc generates simpler code with line numbers
:: that are actually correct and without the register clobber.  Compiling
:: the unpatched version with -O0 also unbreaks man ispell.
::
:: Bruce
::
::Bruce
::
::
::To Unsubscribe: send mail to [EMAIL PROTECTED]
::with unsubscribe freebsd-current in the body of the message
::
::

Haro
=--
   _ _Munehiro (haro) Matsuda
 -|- /_\  |_|_|   Business Incubation Dept., Kubota Corp.
 /|\ |_|  |_|_|   1-3 Nihonbashi-Muromachi 3-Chome
  Chuo-ku Tokyo 103-8310, Japan
  Tel: +81-3-3245-3318  Fax: +81-3-3245-3315
  Email: [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: cvs commit: src/sys/kern kern_mtxpool.c src/sys/sys kernel.h src/sys/vm vm_fault.c vm_glue.c vm_map.c vm_map.h vm_pageout.c vm_zone.c

[Brian F. Feldman]

Matthew Dillon [EMAIL PROTECTED] wrote:
 
 :
 :Hi,
 :
 :Sorry to unwantedly butt in, but the patch supplied by Seigo actually
 :solved the vm_map.c locking problems which used to come up on my system.
 :Just some info. :)
 :
 :Regards,
 :
 :  -- Hiten Pandya
 :  -- [EMAIL PROTECTED]
 
 It fixed some things, it broke some things.  Pretty much standard
 fare for anyone who has ever done work on the vm_map lock, including
 yours truely.  John Dyson couldn't get it right, David Greenman couldn't
 get it right, I couldn't get it completely right... getting it to do 
 the right thing even under -stable is difficult, which is why I am
 suggesting that it simply be made into an exclusive lock in -current.

In addition to the fact it doesn't actually serialize the general 
modification of the vm_map {} structure itself, just certain kinds of 
changes, so is easily a primary reason that the VM system as it stands now 
is inherently single-threaded.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
   [EMAIL PROTECTED]   [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: cvs commit: src/sys/kern kern_mtxpool.c src/sys/sys kernel.h

[John Baldwin]

On 17-Mar-2002 Matthew Dillon wrote:
 I have no idea what the frig you guys are doing in vm_map.c.  I would
 recommend that all the changes be backed out.  Then I would recommend
 that the following be done:
 
   * change the lockmgr vm_map lock to be exclusive-only
   * test  commit
   * change the lockmgr vm_map lock to an exclusive SX lock 
   * test  commit
   * Then work on re-optimizing the vm_map locks
 
 You guys are trying to bite off too much all at once.

Sounds good to me.

   -Matt

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic: bwrite: buffer is not busy???

[Dag-Erling Smorgrav]

Alfred Perlstein [EMAIL PROTECTED] writes:
 I think you're right, I'm pretty sure the fix is basically moving
 the p-p_fd = NULL to after the closef will fix things [...]

There will still be a race...

 Sorry for taking so long to look at this.

No problem, really.  It showed up less than 24 hours ago, your
response time is pretty good in my book :)

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Bad fix for -current breakage

[M. Warner Losh]

In message: [EMAIL PROTECTED]
Ruslan Ermilov [EMAIL PROTECTED] writes:
: Here's a good one:

I see this has already been fixed, but to my eye it looks good.
Certainly a lot better than my kludge-o-matic :-)

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Bad fix for -current breakage

[Ruslan Ermilov]

On Mon, Mar 18, 2002 at 09:32:15AM -0700, M. Warner Losh wrote:
 In message: [EMAIL PROTECTED]
 Ruslan Ermilov [EMAIL PROTECTED] writes:
 : Here's a good one:
 
 I see this has already been fixed, but to my eye it looks good.
 Certainly a lot better than my kludge-o-matic :-)
 
I just implemented your right fix version.  :-)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: -current lock warning...

[John Baldwin]

On 17-Mar-2002 Robert Watson wrote:
 
 On Sun, 17 Mar 2002, Alfred Perlstein wrote:
 
 * Munehiro Matsuda [EMAIL PROTECTED] [020317 06:36] wrote:
  
  PS. I got another message that happend when I ^C'ed a buildworld earlier, 
  with same kernel. May be it should go to Alfred Perlstein?
  
  lock order reversal
   1st 0xc198eec0 pipe mutex @ ../../../kern/sys_pipe.c:779
   2nd 0xc0367fe0 Giant @ ../../../i386/i386/trap.c:716
 
 I think there's a place where the pipe can fault on an address while
 copying, I'll take a look at this. 
 
 Are there any assertions that should be in place for copyin/copyout
 requring fault handling?  It sounds like somewhere we need to assert that
 Giant is held...

More correct is that probably no locks other than Giant should be held for
copyin/copyout.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: -current lock warning...

[Alfred Perlstein]

* John Baldwin [EMAIL PROTECTED] [020318 10:24] wrote:
 
 On 17-Mar-2002 Robert Watson wrote:
  
  On Sun, 17 Mar 2002, Alfred Perlstein wrote:
  
  * Munehiro Matsuda [EMAIL PROTECTED] [020317 06:36] wrote:
   
   PS. I got another message that happend when I ^C'ed a buildworld earlier, 
   with same kernel. May be it should go to Alfred Perlstein?
   
   lock order reversal
1st 0xc198eec0 pipe mutex @ ../../../kern/sys_pipe.c:779
2nd 0xc0367fe0 Giant @ ../../../i386/i386/trap.c:716
  
  I think there's a place where the pipe can fault on an address while
  copying, I'll take a look at this. 
  
  Are there any assertions that should be in place for copyin/copyout
  requring fault handling?  It sounds like somewhere we need to assert that
  Giant is held...
 
 More correct is that probably no locks other than Giant should be held for
 copyin/copyout.

s/probably/definetly.

Can you please provide a blessed API for raising and lowering a
can't block count in the thread?  This can be used in copyout,
copyin, and a bunch of vm and buffer ops to make sure we aren't calling
them with mutexes held.

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using 1970s technology,
 start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: -current lock warning...

[John Baldwin]

On 18-Mar-2002 Alfred Perlstein wrote:
 * John Baldwin [EMAIL PROTECTED] [020318 10:24] wrote:
 
 On 17-Mar-2002 Robert Watson wrote:
  
  On Sun, 17 Mar 2002, Alfred Perlstein wrote:
  
  * Munehiro Matsuda [EMAIL PROTECTED] [020317 06:36] wrote:
   
   PS. I got another message that happend when I ^C'ed a buildworld
   earlier, 
   with same kernel. May be it should go to Alfred Perlstein?
   
   lock order reversal
1st 0xc198eec0 pipe mutex @ ../../../kern/sys_pipe.c:779
2nd 0xc0367fe0 Giant @ ../../../i386/i386/trap.c:716
  
  I think there's a place where the pipe can fault on an address while
  copying, I'll take a look at this. 
  
  Are there any assertions that should be in place for copyin/copyout
  requring fault handling?  It sounds like somewhere we need to assert that
  Giant is held...
 
 More correct is that probably no locks other than Giant should be held for
 copyin/copyout.
 
 s/probably/definetly.
 
 Can you please provide a blessed API for raising and lowering a
 can't block count in the thread?  This can be used in copyout,
 copyin, and a bunch of vm and buffer ops to make sure we aren't calling
 them with mutexes held.

*sigh*  I've never objected to it and even provided you with tips on how to
implement it.  What more do you want?   I'm not really sure we need it though
to be honest as the implicit checks done by witness will probably ensure this
for us.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Yet another build failure

[M. Warner Losh]

On my -stable box:
=== usr.bin/xlint/llib
/usr/obj/home/imp/FreeBSD/src/usr.bin/xlint/llib/../xlint/xlint -cghapbx -L 
/usr/libdata/lint -Cposix /home/imp/FreeBSD/src/usr.bin/xlint/llib/llib-lposix
/usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found
*** Error code 1

/usr/obj/home/imp/FreeBSD/src/usr.bin/xlint/llib/../xlint/xlint isn't
a legal file to run in the compile phase, since it is built with the
TARGET environment, not the HOST environment.

Geeze, doesn't anybody build world anymore :-(

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rtld messing up?

[John Polstra]

In article [EMAIL PROTECTED],
Mark Murray  [EMAIL PROTECTED] wrote:
 
 Here is kaffe (from ports) post mortem after an at-load blowup.
 
 #0  0x280520ee in reloc_non_plt (obj=0x28064500, obj_rtld=0x280604a0)
 at /usr/src/libexec/rtld-elf/i386/reloc.c:196
 196 *where += (Elf_Addr) obj-relocbase;
 (gdb) where
 #0  0x280520ee in reloc_non_plt (obj=0x28064500, obj_rtld=0x280604a0)
 at /usr/src/libexec/rtld-elf/i386/reloc.c:196
 #1  0x2804fb30 in relocate_objects (first=0x28064000, bind_now=0 '\000')
 at /usr/src/libexec/rtld-elf/rtld.c:1398
 #2  0x2804e663 in _rtld (sp=0xbfbffa58, exit_proc=0xbfbffa50, objp=0xbfbffa54)
 at /usr/src/libexec/rtld-elf/rtld.c:380
 
 Other ports (like QT2) are also doing this.
 
 Any ideas?

All I know is this:  The dynamic linker was working just fine for
years.  Then we got a new version of binutils, and lots of problems
started happening.  The dynamic linker wasn't changed -- binutils
was.  I have no idea what got broken, but I kind of doubt that the
bug is in the dynamic linker.

John
-- 
  John Polstra
  John D. Polstra  Co., Inc.Seattle, Washington USA
  Disappointment is a good sign of basic intelligence.  -- Chögyam Trungpa


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Success story - was Re: HEADS UP: OpenSSH 3.1 imported

[Szilveszter Adam]

Hello,

On Mon, Mar 18, 2002 at 11:27:48AM -0800, David Wolfskill wrote:
 I generally try to avoid chattering too much on the lists, but given the
 eventfulness of the normally-rather-routine -CURRENT build this
 morning, I thought it would be appropriate to announce a measure of
 success.

Heh. I did my routine build yesterday and so far I can report success
too. Needless to say, I do not yet have the new OpenSSH, but I did the
Perl upgrade and the rest. (including the splitfs support in the boot2.
Now I get interesting output at boot telling me how it looks for
components.)

And, watch this, I have no problems so far with the new zlib, even the
dreaded man ispell works fine for me. In addition, it feels that I am
getting increased I/O performance on my ATA disk with a softupdates-less
filesystem. Something like: Erasing the /usr/obj/* directory strucutre
took about 20 mins before, yesterday it was done in 2 mins? In the
next moment I heard the sound of my jaw slamming onto my desk...:-)

Keep up the good work!
-- 
Regards:

Szilveszter ADAM
Szombathely Hungary

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: HEADS UP: OpenSSH 3.1 imported

[David Wolfskill]

From: Dag-Erling Smorgrav [EMAIL PROTECTED]
Date: 18 Mar 2002 12:12:34 +0100

I just imported OpenSSH 3.1.  It seems to build and work right, but it
was a bitch to merge, and I'm bound to have botched something royally
somewhere.  Drop me a note if something breaks.

I generally try to avoid chattering too much on the lists, but given the
eventfulness of the normally-rather-routine -CURRENT build this
morning, I thought it would be appropriate to announce a measure of
success.  Not only can I report that today's -CURRENT built (finally --
see cvs-all for the details -- mostly patches provided by
[EMAIL PROTECTED]):

freebeast(5.0-C)[2] uname -a
FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #20: Mon Mar 18 
11:00:31 PST 2002 
[EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST  i386
freebeast(5.0-C)[3] 

But ssh into and out from the box works Just Fine (so far, anyway).

Now I'm about to try bootiing the just-built  -installed -CURRENT
on my laptop.  :-}

Cheers,
david   (links to my resume at http://www.catwhisker.org/~david)
-- 
David H. Wolfskill  [EMAIL PROTECTED]
I believe it would be irresponsible (and thus, unethical) for me to advise,
recommend, or support the use of any product that is or depends on any
Microsoft product for any purpose other than personal amusement.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

buildkernel breakage from -stable - -current

[M. Warner Losh]

cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -ansi 
-g -nostdinc -I-  -I. -I/home/imp/FreeBSD/src/sys -I/home/imp/FreeBSD/src/sys/dev 
-I/home/imp/FreeBSD/src/sys/contrib/dev/acpica 
-I/home/imp/FreeBSD/src/sys/contrib/ipfilter -I/home/imp/FreeBSD/src/sys/../include  
-D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf  
-mpreferred-stack-boundary=2 -Werror  /home/imp/FreeBSD/src/sys/dev/amr/amr.c
cc1: warnings being treated as errors
/home/imp/FreeBSD/src/sys/dev/amr/amr.c: In function `amr_bio_command':
/home/imp/FreeBSD/src/sys/dev/amr/amr.c:817: warning: unsigned int format, different 
type arg (arg 3)

I'll try to fix this...

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Yet another build failure

[Hiten Pandya]

--- M. Warner Losh [EMAIL PROTECTED] wrote:
 On my -stable box:
 === usr.bin/xlint/llib
 /usr/obj/home/imp/FreeBSD/src/usr.bin/xlint/llib/../xlint/xlint -cghapbx -L
 /usr/libdata/lint -Cposix
 /home/imp/FreeBSD/src/usr.bin/xlint/llib/llib-lposix
 /usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found
 *** Error code 1
 
 /usr/obj/home/imp/FreeBSD/src/usr.bin/xlint/llib/../xlint/xlint isn't
 a legal file to run in the compile phase, since it is built with the
 TARGET environment, not the HOST environment.
 
 Geeze, doesn't anybody build world anymore :-(

I do... In fact, I was planning to do this today.   Does this only apply
-stable?

__
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

buildkernel broken

[Munish Chopra]

cvsup about three hours ago, buildkernel fails with:

=== uplcom
cc -O -pipe -march=k6  -D_KERNEL -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -ansi
-DKLD_MODULE -nostdinc -I-   -I. -I@ -I@/dev -I@/../include -fno-common
-mpreferred-stack-boundary=2 -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual  -fformat-extensions -ansi -c
/usr/src/sys/modules/uplcom/../../dev/usb/uplcom.c
/usr/src/sys/modules/uplcom/../../dev/usb/uplcom.c:206:
`USB_PRODUCT_RATOC_REXUSB60' undeclared here (not in a function)
/usr/src/sys/modules/uplcom/../../dev/usb/uplcom.c:206: initializer
element is not constant
/usr/src/sys/modules/uplcom/../../dev/usb/uplcom.c:206: (near
initialization for `uplcom_products[5].product')
*** Error code 1

Stop in /usr/src/sys/modules/uplcom.
*** Error code 1


uname of current system:
FreeBSD rn-re116a13.uwaterloo.ca 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu
Feb 28 18:44:28 EST 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARCADIA  i386

-- 
Munish Chopra The FreeBSD NVIDIA Driver Initiative
  http://nvidia.netexplorer.org

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Yet another build failure

[M. Warner Losh]

In message: [EMAIL PROTECTED]
Hiten Pandya [EMAIL PROTECTED] writes:
: --- M. Warner Losh [EMAIL PROTECTED] wrote:
:  On my -stable box:
:  === usr.bin/xlint/llib
:  /usr/obj/home/imp/FreeBSD/src/usr.bin/xlint/llib/../xlint/xlint -cghapbx -L
:  /usr/libdata/lint -Cposix
:  /home/imp/FreeBSD/src/usr.bin/xlint/llib/llib-lposix
:  /usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found
:  *** Error code 1
:  
:  /usr/obj/home/imp/FreeBSD/src/usr.bin/xlint/llib/../xlint/xlint isn't
:  a legal file to run in the compile phase, since it is built with the
:  TARGET environment, not the HOST environment.
:  
:  Geeze, doesn't anybody build world anymore :-(
: 
: I do... In fact, I was planning to do this today.   Does this only apply
: -stable?

Yes.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

installworld broken on pre eaccess changes

[M. Warner Losh]

=== usr.bin/chflags
install -c -s -o root -g wheel -m 555   chflags /bin
install -c -o root -g wheel -m 444 chflags.1.gz  /usr/share/man/man1
=== usr.bin/chpass
[ ! -e /usr/bin/chpass ] ||  chflags noschg /usr/bin/chpass || true
*** Signal 12

Sigh.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: installworld broken on pre eaccess changes

[Warner Losh]

In message [EMAIL PROTECTED] M. Warner Losh writes:
: === usr.bin/chflags
: install -c -s -o root -g wheel -m 555   chflags /bin
: install -c -o root -g wheel -m 444 chflags.1.gz  /usr/share/man/man1
: === usr.bin/chpass
: [ ! -e /usr/bin/chpass ] ||  chflags noschg /usr/bin/chpass || true
: *** Signal 12
: 
: Sigh.

Actually, I think this is my bad.  I didn't reboot with the new kernel
first.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic: bwrite: buffer is not busy???

[Alfred Perlstein]

* Dag-Erling Smorgrav [EMAIL PROTECTED] [020318 08:23] wrote:
 Alfred Perlstein [EMAIL PROTECTED] writes:
  I think you're right, I'm pretty sure the fix is basically moving
  the p-p_fd = NULL to after the closef will fix things [...]
 
 There will still be a race...

Are you sure? :)

Btw, is there a way to easily reproduce this bug?

Index: kern/kern_descrip.c
===
RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.128
diff -u -r1.128 kern_descrip.c
--- kern/kern_descrip.c 15 Mar 2002 08:03:46 -  1.128
+++ kern/kern_descrip.c 18 Mar 2002 19:04:24 -
@@ -1321,10 +1321,11 @@
 fdfree(td)
struct thread *td;
 {
-   register struct filedesc *fdp = td-td_proc-p_fd;
+   register struct filedesc *fdp;
struct file **fpp;
register int i;
 
+   fdp = td-td_proc-p_fd;
/* Certain daemons might not have file descriptors. */
if (fdp == NULL)
return;
@@ -1344,6 +1345,11 @@
if (*fpp)
(void) closef(*fpp, td);
}
+
+   PROC_LOCK(td-td_proc);
+   td-td_proc-p_fd = NULL;
+   PROC_UNLOCK(td-td_proc);
+
if (fdp-fd_nfiles  NDFILE)
FREE(fdp-fd_ofiles, M_FILEDESC);
if (fdp-fd_cdir)
Index: kern/vfs_syscalls.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.231
diff -u -r1.231 vfs_syscalls.c
--- kern/vfs_syscalls.c 12 Mar 2002 04:00:10 -  1.231
+++ kern/vfs_syscalls.c 18 Mar 2002 19:05:23 -
@@ -451,9 +451,12 @@
return;
sx_slock(allproc_lock);
LIST_FOREACH(p, allproc, p_list) {
+   PROC_LOCK(p);
fdp = p-p_fd;
-   if (fdp == NULL)
+   if (fdp == NULL) {
+   PROC_UNLOCK(p);
continue;
+   }
FILEDESC_LOCK(fdp);
if (fdp-fd_cdir == olddp) {
VREF(newdp);
@@ -469,6 +472,7 @@
vrele(olddp);
} else
FILEDESC_UNLOCK(fdp);
+   PROC_UNLOCK(p);
}
sx_sunlock(allproc_lock);
if (rootvnode == olddp) {

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using 1970s technology,
 start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic: bwrite: buffer is not busy???

[Dag-Erling Smorgrav]

Alfred Perlstein [EMAIL PROTECTED] writes:
 * Dag-Erling Smorgrav [EMAIL PROTECTED] [020318 08:23] wrote:
  Alfred Perlstein [EMAIL PROTECTED] writes:
   I think you're right, I'm pretty sure the fix is basically moving
   the p-p_fd = NULL to after the closef will fix things [...]
  There will still be a race...
 Are you sure? :)

Almost, though I think the window will be much smaller than it is now.
The only way I see of avoiding it alltogether is to protect p-p_fd
and its mutex with allproc_lock (IOW, destroy the table as the last
thing you do before zombifying the process)

 Btw, is there a way to easily reproduce this bug?

No, it's a race condition, which makes it hard to trigger on purpose.

The problem with your patch is that *every* place in the kernel that
calls FILEDESC_LOCK needs to first acquire the proc lock and check if
p-p_fd is NULL.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rtld messing up?

[Terry Lambert]

John Polstra wrote:
 All I know is this:  The dynamic linker was working just fine for
 years.  Then we got a new version of binutils, and lots of problems
 started happening.  The dynamic linker wasn't changed -- binutils
 was.  I have no idea what got broken, but I kind of doubt that the
 bug is in the dynamic linker.

The new binutils screws over some basic long-standing assumptions
about field ordering and associativity in the object files, which
are no longer maintained (for whatever reason) in the new version
of the tools.

Some of them have been identified and repaired (e.g. the Alpha
code changes for the section/segment order assumption), but it
is going to probably be a long battle.

Technically, the ELF spec permits the ordering, so the assumptions
are really broken, even though they code for what's really a
defacto-standard of many years, now.  8-(.

I hate the new binutils, but they are required for support
for the 64 bit architectures, so they are not going to just
go away.  I think retrofitting support for these architectures
into the old binutils would be a mistake.

It's a little sad, since with the assumptions, the code would
have been faster on initial execution, than without them.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic: bwrite: buffer is not busy???

[Kris Kennaway]

On Mon, Mar 18, 2002 at 02:36:31PM -0800, Alfred Perlstein wrote:
 * Dag-Erling Smorgrav [EMAIL PROTECTED] [020318 08:23] wrote:
  Alfred Perlstein [EMAIL PROTECTED] writes:
   I think you're right, I'm pretty sure the fix is basically moving
   the p-p_fd = NULL to after the closef will fix things [...]
  
  There will still be a race...
 
 Are you sure? :)
 
 Btw, is there a way to easily reproduce this bug?

The panic in tail was triggered by using -f (i.e. kqueue), but it's
only happened once on the cluster..err..twice now (just happened
again).  Without your previous patch several cluster machines were
failing several times per hour, in umount.  You could probably trigger
it by stressing these two code paths.

I'll test your latest patch a bit later on.

Kris



msg36321/pgp0.pgp
Description: PGP signature

Re: panic: bwrite: buffer is not busy???

[Dag-Erling Smorgrav]

Kris Kennaway [EMAIL PROTECTED] writes:
 The panic in tail was triggered by using -f (i.e. kqueue),

Like I said, that panic was irrelevant since it was a consequence of
an incorrect patch.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic: bwrite: buffer is not busy???

[Alfred Perlstein]

* Dag-Erling Smorgrav [EMAIL PROTECTED] [020318 15:03] wrote:
 Alfred Perlstein [EMAIL PROTECTED] writes:
  * Dag-Erling Smorgrav [EMAIL PROTECTED] [020318 08:23] wrote:
   Alfred Perlstein [EMAIL PROTECTED] writes:
I think you're right, I'm pretty sure the fix is basically moving
the p-p_fd = NULL to after the closef will fix things [...]
   There will still be a race...
  Are you sure? :)
 
 Almost, though I think the window will be much smaller than it is now.
 The only way I see of avoiding it alltogether is to protect p-p_fd
 and its mutex with allproc_lock (IOW, destroy the table as the last
 thing you do before zombifying the process)

Actually...

if checkdirs wins the race for proc lock it will do its magic and
fdfree will wait while it does that.

if fdfree wins, then checkdirs will see a NULL p_fd pointer.

  Btw, is there a way to easily reproduce this bug?
 
 No, it's a race condition, which makes it hard to trigger on purpose.
 
 The problem with your patch is that *every* place in the kernel that
 calls FILEDESC_LOCK needs to first acquire the proc lock and check if
 p-p_fd is NULL.

No, only when a sideways access occurs, like in checkdirs().

I think this ought to fix it.

Index: kern/vfs_syscalls.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.231
diff -u -r1.231 vfs_syscalls.c
--- kern/vfs_syscalls.c 12 Mar 2002 04:00:10 -  1.231
+++ kern/vfs_syscalls.c 18 Mar 2002 23:18:34 -
@@ -446,29 +446,34 @@
 {
struct filedesc *fdp;
struct proc *p;
+   int nrele;
 
if (olddp-v_usecount == 1)
return;
sx_slock(allproc_lock);
LIST_FOREACH(p, allproc, p_list) {
+   PROC_LOCK(p);
fdp = p-p_fd;
-   if (fdp == NULL)
+   if (fdp == NULL) {
+   PROC_UNLOCK(p);
continue;
+   }
+   nrele = 0;
FILEDESC_LOCK(fdp);
if (fdp-fd_cdir == olddp) {
VREF(newdp);
fdp-fd_cdir = newdp;
-   FILEDESC_UNLOCK(fdp);
-   vrele(olddp);
-   FILEDESC_LOCK(fdp);
+   nrele++;
}
if (fdp-fd_rdir == olddp) {
VREF(newdp);
fdp-fd_rdir = newdp;
-   FILEDESC_UNLOCK(fdp);
+   nrele++;
+   }
+   FILEDESC_UNLOCK(fdp);
+   PROC_UNLOCK(p);
+   while (nrele--)
vrele(olddp);
-   } else
-   FILEDESC_UNLOCK(fdp);
}
sx_sunlock(allproc_lock);
if (rootvnode == olddp) {
Index: kern/kern_descrip.c
===
RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.128
diff -u -r1.128 kern_descrip.c
--- kern/kern_descrip.c 15 Mar 2002 08:03:46 -  1.128
+++ kern/kern_descrip.c 18 Mar 2002 19:04:24 -
@@ -1321,10 +1321,11 @@
 fdfree(td)
struct thread *td;
 {
-   register struct filedesc *fdp = td-td_proc-p_fd;
+   register struct filedesc *fdp;
struct file **fpp;
register int i;
 
+   fdp = td-td_proc-p_fd;
/* Certain daemons might not have file descriptors. */
if (fdp == NULL)
return;
@@ -1344,6 +1345,11 @@
if (*fpp)
(void) closef(*fpp, td);
}
+
+   PROC_LOCK(td-td_proc);
+   td-td_proc-p_fd = NULL;
+   PROC_UNLOCK(td-td_proc);
+
if (fdp-fd_nfiles  NDFILE)
FREE(fdp-fd_ofiles, M_FILEDESC);
if (fdp-fd_cdir)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic: bwrite: buffer is not busy???

[Dag-Erling Smorgrav]

Alfred Perlstein [EMAIL PROTECTED] writes:
 if checkdirs wins the race for proc lock it will do its magic and
 fdfree will wait while it does that.
 
 if fdfree wins, then checkdirs will see a NULL p_fd pointer.

You're right.  I'm still worried about other fdfree() callers, though,
but this patch is definitely better than the current state of affairs,
so you might as well commit it :)

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: utmp and current

[Garance A Drosihn]

At 10:36 PM -0800 3/17/02, whoever wrote:
Hi,
   I updated to current 5.0
several weeks back and just noticed that
the utmp logging for people users logged
in is missing. [...]  All the listings in
last are also incomplete.
The last login entry for any ttyv* is the
last day I ran 4.4 stable..
What gives?
Have you guys have had any experience
similar to this

This will not help you much, but all the
wtmp and utmp records seem fine on my
5.0-current system.  I am running a
snapshot from March 13th.  'who', 'last',
etc all seem to be producing reasonable-
looking and probably-accurate information.

-- 
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

make kernel breakage - src/sys/dev/usb/uplcom.c

[Jeff Kletsky]

Compiling from today's cvsup results in a failure to compile
src/sys/dev/usb/uplcom.c due to USB_PRODUCT_RATOC_REXUSB60 being
undefined.

It appears that usbdevs.h needs to be regenerated and checked in to the
repository. 

As a temporary fix:

  cd .../src/sys/dev/usb/
  awk -f devlist2h.awk  usbdevs

seems to resolve the issue.

Is there a reason this is (apparently) not run during the make process?

Jeff




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message