Re: WARNING /dev/wd compat hack removed...
In message [EMAIL PROTECTED], "Daniel O'Connor" write s: On 15-Jun-00 Poul-Henning Kamp wrote: Remove the "wd" compatibility name from the "ad" driver. WARNING: If you have not updated to use /dev/wd* in your /etc/fstab You mean 'If you have not updated to use /dev/ad* in your /etc/fstab...' right? Yes, I got that reversed [sigh...] -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: fatal trap 12 after lastest kernel build
did you follow Peter Wemm's instructions on the new config changes? Muchos thanks to Warner Losh for his src/UPDATE service. It really saved my butt a couple of times. :) Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: bioops patch.
Background: The bioops operation vector is a list of OO-like operations which can be performed on struct buf. They are used by the softupdates code to handle dependencies. Ideally struct buf should have had a real OO like operations vector like vnodes have it, and struct bioops is the first step towards that. struct buf will eventually become merely an iocmd structure, so why do we want to complicate things here? One of the reasons we should have OO-like struct buf, is that as long as bwrite(bp) "knows" that the buffer is backed by a disk device, we cannot use the UFS layer on top of a storage manager which isn't based on disk-devices: When UFS modifies a directory inode, it will call bwrite(bp) on the buffer with the data. This would not work if the backing were based on malloc(9) or anonymous swap-backed VM objects for instance. We already have an OO method for bwrite: VOP_BWRITE(), the problem is most of the code are still calling bwrite() directly. Will it solve your problem if we change every bwrite() into a VOP_BWRITE()? -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel broken?
oops, sorry ... I wasn't even getting a page fault, it was just
hanging. Hrmmm, maybe I'll try a newer kernel and see if it still
exhibits the same problem ... my luck, I got my sources part way through
someone's update :)
On Fri, 16 Jun 2000, Donn Miller wrote:
The Hermit Hacker wrote:
On Thu, 15 Jun 2000, Wes Morgan wrote:
As of about 7pm EDT I can't boot a -current kernel. I _can_ boot a kernel
from the 13th I snagged from a snapshot kernel disk, and I can boot the
snapshot from the 15th (but since userconfig does not work the lnc device
spams so many error messages the system never reaches a prompt).
Already did the make clean depend all install for /sys/boot/i386 and that
was no help. The kernel just freezes _right_ after trying to boot... I'm
not sure how far its getting, I'll have to play around with a debug kernel
and see what I can get from it (if anything).
okay, I see the same thing, but *believe* that this has to do with the
whole thread on ttyv0 that just passed through here, so am just waiting
and watching the commit logs for something that "looks" appropriate ...
Well, I don't think that ttyv0 would be the problem in this case.
See, the machine just hangs with a fatal trap immediately after the
boot loader attempts to boot the kernel. The whole thread with ttyv0
seems to be an issue only when /etc/rc.conf is read. So, basically
the page fault is occuring way at the beginning of the boot process
long before the console driver is even loaded. 8-(
- Donn
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: bioops patch.
In message [EMAIL PROTECTED], Luoqi Chen write s: Background: Ideally struct buf should have had a real OO like operations vector like vnodes have it, and struct bioops is the first step towards that. struct buf will eventually become merely an iocmd structure, so why do we want to complicate things here? No, struct buf will remain the cache-handle. the iocmd is called struct bio. We already have an OO method for bwrite: VOP_BWRITE(), the problem is most of the code are still calling bwrite() directly. Will it solve your problem if we change every bwrite() into a VOP_BWRITE()? Well, I'm not sure it is correct to go the detour around Vnodes, if we do, we need to add VOP_BAWRITE, VOP_BDWRITE and all those other operations as well. But what vnode would you use for a buffer associated with a freeblock bitmap ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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
question regarding current
I just install snap 61200 for 5 on my laptop and so far things are smooth...this was the easiest time I've have configuring xe (xircom nics) so far...anyway since I am new to the world of current I have a few questions... I am just curious maybe there's an webpage that describes the direction of current (you know a mission statement , sort of road map thingie)? Or is that a secret type thing we don't know until it's out? If there isn't a page is one wanted? On that note is the scaled down /etc the direction we are going in, or is it just the way current is arrange and it will grow to be more like 3.0 4.0? Seems the install CD I made missed compat2.0 but the install seems to have gone ok...should I worry about it being missing?, is installing it after the fact a problem if it's required? -- Cheers, Mikel +~+ | Optimized Computer Solutions, Inchttp://www.ocsny.com | 39 W14th Street, Suite 203 212 727 2238 x132 | New York, NY 10011 +~+ begin:vcard n:King;Mikel tel;fax:2124638402 tel;home:http://www.upan.org tel;work:2127272100 x-mozilla-html:TRUE org:Optimized Computer Solutions version:2.1 email;internet:[EMAIL PROTECTED] title:Director of Network Operations Technology adr;quoted-printable:;;39 W14th St.=0D=0ASte 203;New York;NY;10011;US note;quoted-printable:fBSD, PHP, MySql and OCS Rule!!!=0D=0A=0D=0AGoal is to be MS free by the end of 2k. x-mozilla-cpt:;7312 fn:Mikel King end:vcard
Re: HEADSUP: bioops patch.
What about using uppercase names for buf_complete - BUF_COMPLETE and friends to make it apparent that an indirect call is being made and that the function might not be supported on that struct buf. Much like newbus, kobj, and vnode ops. Nick On Wed, 14 Jun 2000, Poul-Henning Kamp wrote: This patch virtualizes untangles the bioops operations vector. Background: The bioops operation vector is a list of OO-like operations which can be performed on struct buf. They are used by the softupdates code to handle dependencies. Ideally struct buf should have had a real OO like operations vector like vnodes have it, and struct bioops is the first step towards that. One of the reasons we should have OO-like struct buf, is that as long as bwrite(bp) "knows" that the buffer is backed by a disk device, we cannot use the UFS layer on top of a storage manager which isn't based on disk-devices: When UFS modifies a directory inode, it will call bwrite(bp) on the buffer with the data. This would not work if the backing were based on malloc(9) or anonymous swap-backed VM objects for instance. In other words: this is the main reason why we don't have a decent tmpfs in FreeBSD. Instead of just assuming that it works on a disk, bwrite(bp) should do a "bp-b_ops-bwrite(bp)" so that each buffer could have its own private idea of how to write itself, depending on what backing it has. So in order to move bioops closer to become a bp-b_ops, this patch takes two entries out of bioops: the "sync" and the "fsync" items and virtualizes the rest of the elements a bit. The "sync" item is called only from the syncer, and is a call to the softupdates code to do what it needs to do for periodic syncing. The real way of doing that would be to have an event-handler for this since other code could need to be part of the sync trafic, raid5 private parity caches could be one example. I have not done this yet, since currently softupdates is the only client. The fsync item really doesn't belong in the fsync system call, it belongs in ffs_fsync, and has been moved there. To give the right behaviour when SOFTUPDATES is not compiled in, stubs for both of these functions have been added to ffs_softdep_stub.c Finally all the checks to see if the bioops vector is populated has been centralized in in-line functions in sys/buf.h thereby paving the road for the global bioops to become bp-b_ops. Comments, reviews, tests please Poul-Henning Index: contrib/softupdates/ffs_softdep.c === RCS file: /home/ncvs/src/sys/contrib/softupdates/ffs_softdep.c,v retrieving revision 1.64 diff -u -r1.64 ffs_softdep.c --- contrib/softupdates/ffs_softdep.c 2000/05/26 02:01:59 1.64 +++ contrib/softupdates/ffs_softdep.c 2000/06/14 19:26:46 @@ -222,8 +222,6 @@ softdep_disk_io_initiation, /* io_start */ softdep_disk_write_complete,/* io_complete */ softdep_deallocate_dependencies,/* io_deallocate */ - softdep_fsync, /* io_fsync */ - softdep_process_worklist, /* io_sync */ softdep_move_dependencies, /* io_movedeps */ softdep_count_dependencies, /* io_countdeps */ }; Index: kern/vfs_bio.c === RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.258 diff -u -r1.258 vfs_bio.c --- kern/vfs_bio.c2000/05/26 02:04:39 1.258 +++ kern/vfs_bio.c2000/06/14 19:00:56 @@ -616,8 +616,8 @@ newbp-b_flags = ~B_INVAL; /* move over the dependencies */ - if (LIST_FIRST(bp-b_dep) != NULL bioops.io_movedeps) - (*bioops.io_movedeps)(bp, newbp); + if (LIST_FIRST(bp-b_dep) != NULL) + buf_movedeps(bp, newbp); /* * Initiate write on the copy, release the original to @@ -673,10 +673,10 @@ /* * Process dependencies then return any unfinished ones. */ - if (LIST_FIRST(bp-b_dep) != NULL bioops.io_complete) - (*bioops.io_complete)(bp); - if (LIST_FIRST(bp-b_dep) != NULL bioops.io_movedeps) - (*bioops.io_movedeps)(bp, origbp); + if (LIST_FIRST(bp-b_dep) != NULL) + buf_complete(bp); + if (LIST_FIRST(bp-b_dep) != NULL) + buf_movedeps(bp, origbp); /* * Clear the BX_BKGRDINPROG flag in the original buffer * and awaken it if it is waiting for the write to complete. @@ -939,8 +939,8 @@ * cache the buffer. */ bp-b_flags |= B_INVAL; - if (LIST_FIRST(bp-b_dep) != NULL bioops.io_deallocate) - (*bioops.io_deallocate)(bp); + if (LIST_FIRST(bp-b_dep) != NULL) +
GENERIC from today does not detect system console on my box
I tried booting a kernel this morning, just to see Peter's new "lean-n-mean" kernel config format in action, and I turned my workstation into a headless server in the process. :-) Most notably, these former entries were now missing from my dmesg output when I logged in remotely and poked around: atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 JFYI... - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CFR: xdr.h fix for xdrproc_t
I would like to apply this patch: Index: xdr.h === RCS file: /home/ncvs/src/include/rpc/xdr.h,v retrieving revision 1.14 diff -u -r1.14 xdr.h --- xdr.h 1999/12/29 05:00:44 1.14 +++ xdr.h 2000/06/16 17:05:09 @@ -128,14 +128,14 @@ * The opaque pointer generally points to a structure of the data type * to be decoded. If this pointer is 0, then the type routines should * allocate dynamic storage of the appropriate size and return it. + * + * Sometimes there is a third argument, sometimes not. So for correct + * prototyping, ... is required. */ #ifdef _KERNEL typedefbool_t (*xdrproc_t) __P((XDR *, void *, u_int)); #else -/* - * XXX can't actually prototype it, because some take two args!!! - */ -typedefbool_t (*xdrproc_t) __P((/* XDR *, void *, u_int */)); +typedefbool_t (*xdrproc_t) __P((XDR *, ...)); #endif /* Does anyone forsee any difficulties? Not doing this prevents a product I work on from compiling. gcc complains about the number of arguments because in C++ () prototypes a function that takes NO arguments. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC from today does not detect system console on my box
I had a wierder problem yesterday... I followed the new changes to the kernel config file, and included everything that belonged there, and yet for some reason, my kernel paniced while probing vga0 with an error number 6. I had to use a fixit floppy to get back into the system and compile a generic kernel, and from there make a new config file. The wierd part is I the panicing config and the non-panicing config both looked the same... (diff showed only differences in whitespace and comments as far as I could tell. Wierd... = | Kenneth Culver | FreeBSD: The best NT upgrade| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Fri, 16 Jun 2000, Jordan K. Hubbard wrote: I tried booting a kernel this morning, just to see Peter's new "lean-n-mean" kernel config format in action, and I turned my workstation into a headless server in the process. :-) Most notably, these former entries were now missing from my dmesg output when I logged in remotely and poked around: atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 JFYI... - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons scrolling broken
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Also sprach Marc van Woerkom ([EMAIL PROTECTED]): Anyone else? Yes, but it only applies to ttyv0. Same behaviour here. Jup, here too. Unfortunately, that's the only one where I want it :) Uncommenting out the following part gives me back the ttyv0 back scrolling and vidcontrol 80x30, but maybe leaking memory. Why pay for Internet Service when you can get it for FREE? http://www.nettaxi.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons scrolling broken
Uncommenting out the following part gives me back the ttyv0 back scrolling and
vidcontrol 80x30, but maybe leaking memory.
Sorry, actually it was commenting out, and forgot attaching the diff.
--- scvtb.c.orig Sat Jun 17 03:39:00 2000
+++ scvtb.c Sat Jun 17 03:39:00 2000
@@ -93,8 +93,10 @@
switch (vtb-vtb_type) {
case VTB_MEMORY:
case VTB_RINGBUFFER:
+#if 0
if (p != NULL)
free((void *)p, M_DEVBUF);
+#endif
break;
default:
break;
Why pay for Internet Service when you can get it for FREE?
http://www.nettaxi.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!: config changes...
Hi, Is there anyway to put the device.hint stuff into kernel nevertheless? My diskless box fetches the kernel would know nothing about things reside in device.hint. Cheers, CLK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC from today does not detect system console on my box
Did you ran the Perl skript to create the hints file and then change your KERNEL config like this? Yep! The Perl script generates no output and my kernel config file matches the requirements perfectly. Though, if you'll read the subject line again, you'll see I used GENERIC for my test anyway. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC from today does not detect system console on my box
"Jordan K. Hubbard" wrote: I tried booting a kernel this morning, just to see Peter's new "lean-n-mean" kernel config format in action, and I turned my workstation into a headless server in the process. :-) Most notably, these former entries were now missing from my dmesg output when I logged in remotely and poked around: atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 I was just wondering what happens if no device.hints exists. It seems it isn't installed by installkernel target, and the above are all part of it. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic with userquota(softupdates?)
I keep getting panics in dqget(ufs_quota.c), with a -current from a couple
of days ago. I think this might be softupdates related, since I can't make
it happen with softupdates turned off, although it's quite possible that it
has nothing to do with it. Does anyone have any idea what might be causing
this?
Any other information that might be useful here?
-- Kevin
SMP 2 cpus
IdlePTD 3813376
initial pcb at 3178c0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0002; cpuid = 0; lapic.id =
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc023d3d2
stack pointer = 0x10:0xd9176d28
frame pointer = 0x10:0xd9176d78
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 = 3384 (smbd)
interrupt mask = none - SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0002; cpuid = 0; lapic.id =
boot() called on cpu#0
syncing disks...
done
Uptime: 5h9m37s
dumping to dev #da/0x20001, offset 1735462
dump 511 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 26!
5 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 boot (howto=256) at ../../kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
#1 0xc016a2d9 in panic (fmt=0xc02c532f "page fault") at ../../kern/kern_shutdown.c:553
#2 0xc0282190 in trap_fatal (frame=0xd9176ce8, eva=0) at ../../i386/i386/trap.c:927
#3 0xc0281e01 in trap_pfault (frame=0xd9176ce8, usermode=0, eva=0) at
../../i386/i386/trap.c:820
#4 0xc028196b in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = -652804080, tf_edi =
-653726848,
tf_esi = -1041411164, tf_ebp = -652776072, tf_isp = -652776172, tf_ebx =
-1038103936,
tf_edx = 0, tf_ecx = -1012515072, tf_eax = 0, tf_trapno = 12, tf_err = 2,
tf_eip = -1071393838, tf_cs = 8, tf_eflags = 66118, tf_esp = -1012515072, tf_ss
= -633865984})
at ../../i386/i386/trap.c:426
#5 0xc023d3d2 in dqget (vp=0xda37f900, id=65534, ump=0xc1f76200, type=0,
dqp=0xc3a63f44)
at ../../ufs/ufs/ufs_quota.c:763
#6 0xc023c796 in getinoquota (ip=0xc3a63f00) at ../../ufs/ufs/ufs_quota.c:95
#7 0xc023ddb5 in ufs_access (ap=0xd9176dfc) at ../../ufs/ufs/ufs_vnops.c:324
#8 0xc02408e9 in ufs_vnoperate (ap=0xd9176dfc) at ../../ufs/ufs/ufs_vnops.c:2287
#9 0xc019fc4b in vn_open (ndp=0xd9176ec8, fmode=3, cmode=484) at vnode_if.h:247
#10 0xc019bd8d in open (p=0xd916eac0, uap=0xd9176f80) at ../../kern/vfs_syscalls.c:995
#11 0xc02824c1 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = -1078001617,
tf_edi = -1077940192, tf_esi = 144677504, tf_ebp = -1077939168, tf_isp =
-652775468,
tf_ebx = 484, tf_edx = 2, tf_ecx = 135418240, tf_eax = 5, tf_trapno = 7, tf_err
= 2,
tf_eip = 673002960, tf_cs = 31, tf_eflags = 663, tf_esp = -1077941548, tf_ss =
47})
at ../../i386/i386/trap.c:1126
#12
çíàêîìñòâî
ß íèêîãäà íå ïûòàëàñü ïîçíàêîìèòüñß â èíòåðíåòå, íî ðåøèëàñü ïîïðîáûâàòü. Æèâó â Ìîñêâå, ó÷óñü. Ìíå 19 ëåò. Íå çíàþ, ÷åãî ìíå íå õâàòàåò, ìîæåò ïðîñòî îáùåíèß , à ìîæåò ëàñêè è âíèìàíèß. ß äàæå íå çíàþ, ÷òî î ñåáå íàïèñàòü, âðîäå íå äóðà, à íå ìîãó. ß äîñòàòî÷íî êðèòè÷íî (òî åñòü ñåáå íå íðàâëþñü) îòíîøóñü ê ñâîåé âíåøíîñòè, íî ïðåäîñòàâëþ òåáå îöåíèòü åå.(åõå- ýòî ñëàéä øîó) slshow.exe
Re: -current kernel broken?
Wes Morgan wrote: As of about 7pm EDT I can't boot a -current kernel. I _can_ boot a kernel from the 13th I snagged from a snapshot kernel disk, and I can boot the snapshot from the 15th (but since userconfig does not work the lnc device spams so many error messages the system never reaches a prompt). Already did the make clean depend all install for /sys/boot/i386 and that was no help. The kernel just freezes _right_ after trying to boot... I'm not sure how far its getting, I'll have to play around with a debug kernel and see what I can get from it (if anything). I saw this as well. It turns out the optimizations I was using when building my kernel was causing it. I was using -march=pentium -Os -pipe. Falling back to -O -pipe solved this. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!: config changes...
Chia-liang Kao wrote: Hi, Is there anyway to put the device.hint stuff into kernel nevertheless? My diskless box fetches the kernel would know nothing about things reside in device.hint. That is what the hints directive is for. you could create a file "diskless.hints" and add the line to your config file: hints "/wherever/diskless.hints" and the contents of that file would be statically compiled in. You can still override them at boot time if you wish, but the basic set will be there. This is what GENERIC does right now. It compiles GENERIC.hints straight in. (see hints.c in compile/YOURKERNEL) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bioops
To: [EMAIL PROTECTED] Subject: HEADSUP: bioops patch. From: Poul-Henning Kamp [EMAIL PROTECTED] Date: Wed, 14 Jun 2000 22:29:32 +0200 This patch virtualizes untangles the bioops operations vector. Background: The bioops operation vector is a list of OO-like operations which can be performed on struct buf. They are used by the softupdates code to handle dependencies. Ideally struct buf should have had a real OO like operations vector like vnodes have it, and struct bioops is the first step towards that. One of the reasons we should have OO-like struct buf, is that as long as bwrite(bp) "knows" that the buffer is backed by a disk device, we cannot use the UFS layer on top of a storage manager which isn't based on disk-devices: When UFS modifies a directory inode, it will call bwrite(bp) on the buffer with the data. This would not work if the backing were based on malloc(9) or anonymous swap-backed VM objects for instance. In other words: this is the main reason why we don't have a decent tmpfs in FreeBSD. Instead of just assuming that it works on a disk, bwrite(bp) should do a "bp-b_ops-bwrite(bp)" so that each buffer could have its own private idea of how to write itself, depending on what backing it has. So in order to move bioops closer to become a bp-b_ops, this patch takes two entries out of bioops: the "sync" and the "fsync" items and virtualizes the rest of the elements a bit. The "sync" item is called only from the syncer, and is a call to the softupdates code to do what it needs to do for periodic syncing. The real way of doing that would be to have an event-handler for this since other code could need to be part of the sync trafic, raid5 private parity caches could be one example. I have not done this yet, since currently softupdates is the only client. The fsync item really doesn't belong in the fsync system call, it belongs in ffs_fsync, and has been moved there. If it had been possible to put the fsync call in ffs_fsync, I would have done that. Unfortunately, it is not possible and will hang or panic the kernel if you put it there. The problem is that ffs_fsync syncs out the data blocks of the associated file. The bioops call to soft updates requests that any names associated with the file being sync'ed be sync'ed to disk as well. That is a necessary semantic of the system call fsync. However, it is not needed by most clients of VOP_FSYNC. Because the sync'ing of the name requires a walk up the filesystem tree from the inode in question to the root of the filesystem, the locking protocol requires that the nodes lower in the tree be unlocked before locking nodes that are higher. This means that the vnode being fsync'ed must be briefly unlocked while its containing parent is locked. If the vnode being fsync'ed is a directory, this creates a window where another process can sneak in and make changes which leads to the panics, two entries with the same name, etc. This window is not a problem for the fsync call because it is not creating a new name, but it is a problem if VOP_FSYNC is called in the open, link, mkdir, etc paths (as it will be in for example if a block allocation fails due to the filesystem being full. Thus there are two choices: put the code back as it was or chance the VOP_FSYNC call interface to add a flags value that indicates whether the name needs to be syned out as well as the data. I chose the former as I did not want to disrupt a widely used interface. To give the right behaviour when SOFTUPDATES is not compiled in, stubs for both of these functions have been added to ffs_softdep_stub.c Finally all the checks to see if the bioops vector is populated has been centralized in in-line functions in sys/buf.h thereby paving the road for the global bioops to become bp-b_ops. Comments, reviews, tests please Poul-Henning Index: contrib/softupdates/ffs_softdep.c === RCS file: /home/ncvs/src/sys/contrib/softupdates/ffs_softdep.c,v retrieving revision 1.64 diff -u -r1.64 ffs_softdep.c --- contrib/softupdates/ffs_softdep.c 2000/05/26 02:01:59 1.64 +++ contrib/softupdates/ffs_softdep.c 2000/06/14 19:26:46 @@ -222,8 +222,6 @@ softdep_disk_io_initiation, /* io_start */ softdep_disk_write_complete,/* io_complete */ softdep_deallocate_dependencies,/* io_deallocate */ - softdep_fsync, /* io_fsync */ - softdep_process_worklist, /* io_sync */ softdep_move_dependencies, /* io_movedeps */ softdep_count_dependencies, /* io_countdeps */
Re: GENERIC from today does not detect system console on my box
"Daniel C. Sobral" wrote: "Jordan K. Hubbard" wrote: I tried booting a kernel this morning, just to see Peter's new "lean-n-mean" kernel config format in action, and I turned my workstation into a headless server in the process. :-) Most notably, these former entries were now missing from my dmesg output when I logged in remotely and poked around: atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 I was just wondering what happens if no device.hints exists. It seems it isn't installed by installkernel target, and the above are all part of it. IMHO, the hints are a machine property, not a per-kernel property. Setting up a /boot/device.hints is (IMHO) a one-time task that never needs to be done more than once, and (again IMHO) the 'make install' had damn well better not mess with. This is especially important once kget(8) becomes the equivalent of 'kenv | grep '^hint' /boot/device.hints' or something so that the userconfig.4th changes get saved for next time. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC from today does not detect system console on my box
"Jordan K. Hubbard" wrote: Did you ran the Perl skript to create the hints file and then change your KERNEL config like this? Yep! The Perl script generates no output and my kernel config file matches the requirements perfectly. Though, if you'll read the subject line again, you'll see I used GENERIC for my test anyway. :) Err.. how did you run it? 'perl MYKERNEL'? If you run 'perl MYKERNEL' it will generate nothing because I was kinda lame and didn't know how to do argument parsing. :-] To be sure, next time you boot, press space to get into the loader and do a 'show' - you should see your hints in the environment. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC from today does not detect system console on my box
On Friday, June 16, 2000, Peter Wemm wrote:
Err.. how did you run it? 'perl MYKERNEL'? If you run 'perl MYKERNEL'
it will generate nothing because I was kinda lame and didn't know how to do
argument parsing. :-]
Couldn't have hurt to ask.
while (defined($ARGV[0])) {
# ... parse ...
shift;
}
It'd work as perl script.pl arg1 arg2 ... or as ./script.pl
arg1 arg2 ... (if +x).
--
|Chris Costello [EMAIL PROTECTED]
|Computers are not intelligent. They only think they are.
`-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Crashs with vidcontrol...
I already sent a mail about this problem a while ago, but it has not been solved yet. I mail again because I've made a mistake describing the problem. So, the problem was that when i type "vidcontrol VESA_800x600", it makes my box crash. I first thought that this was making my box reboot, but it is a crash because the system is waiting for me to press a key before rebooting. As it is a problem dealing with graphic modes, i unfortunately can't see anything that is surely written For those who want more details on my hardware and software configuration, please look to the "vidcontrol VESA_800x600 makes my box reboot" mails. You will found information on my hardware configuration and output of dmesg, vidcontrol -i adapter, vidcontrol -i mode and my kernel configuration file. If i can do anything to help and fix this problem, please let me know. I do intend to fix console problems in both -STABLE and -CURRENT. But, I am on business trip this weekend and will not be able to work on the problems before Sunday evening ;- Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ports /work/ directory.
Is there any plans to move the ports' working directory out of the /usr/ports/ tree? Let me explain why i ask. I have 10 FreeBSD servers that are a mix of FreeBSD 2.2.8-STABLE, 3-STABLE, and 4-STABLE. In the interests of saving disk space and bandwith, i have one central file archive of ports, and the three stable branches, and i mount those directories on all servers as required via amd. When i'm working in src at the same time as someone else, i have no problems, since all work is not done in that tree. However, if i were to be working in ports att the same time as someone else, some pretty nasty things happen. If this is not being worked on, but people think that it might be a good idea to move the ports' working directories somewhere else, i'd be willing to take a look and see what i could come up with based on suggestions from whomever wanted to put their two cents in. Regards, Mit [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ports /work/ directory.
On Fri, Jun 16, 2000 at 11:59:18AM -0400, Will Mitayai Keeso Rowe wrote: Is there any plans to move the ports' working directory out of the /usr/ports/ tree? Look at /usr/ports/Mk/bsd.port.mk; in particular WRKDIRPREFIX. Setting it in /etc/make.conf seems sensible, perhaps WRKDIRPREFIX=/usr/ports/`hostname` or WRKDIRPREFIX=/disks/big-fast-disk/ports-build as approprate -- Mike Bristow, seebitwopie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
Mitsuru IWASAKI wrote: - support S2, S3, S4 (hibernation) sleeping transition. S4 sleep require some hack in boot loader needs help. I thought hibernation was entirely controlled by kernel? What do you need? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC from today does not detect system console on my box
Chris Costello wrote:
On Friday, June 16, 2000, Peter Wemm wrote:
Err.. how did you run it? 'perl MYKERNEL'? If you run 'perl MYKERNEL'
it will generate nothing because I was kinda lame and didn't know how to do
argument parsing. :-]
Couldn't have hurt to ask.
while (defined($ARGV[0])) {
# ... parse ...
shift;
}
It'd work as perl script.pl arg1 arg2 ... or as ./script.pl
arg1 arg2 ... (if +x).
How about that and as a stdin pipe as well if no args are specified?
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: question regarding current
On Friday, June 16, 2000, Mikel wrote: I just install snap 61200 for 5 on my laptop and so far things are smooth...this was the easiest time I've have configuring xe (xircom nics) so far...anyway since I am new to the world of current I have a few questions... I am just curious maybe there's an webpage that describes the direction of current (you know a mission statement , sort of road map thingie)? Or is that a secret type thing we don't know until it's out? If there isn't a page is one wanted? There's no specific "direction of current" other than what the developers are working on. Subscribing to this very list can get you that information, and it is recommended that you also subscribe to [EMAIL PROTECTED] On that note is the scaled down /etc the direction we are going in, or is it just the way current is arrange and it will grow to be more like 3.0 4.0? I'm not sure what you mean here. -- |Chris Costello [EMAIL PROTECTED] |QUASIMOTO - 4 wheeled hard-top moped made in France. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install of new kernel fails (bad /modules)
On Tuesday, June 13, 2000, John DeBoskey wrote:
modules-install modules-install.debug:
.if !defined(NO_MODULES_OLD)
mkdir -p ${DESTDIR}/modules.old
cp -p ${DESTDIR}/modules/* ${DESTDIR}/modules.old
I'd suggest changing the above line to:
test -f ${DESTDIR}/modules/* \
cp -p ${DESTDIR}/modules/* ${DESTDIR}/modules.old
I haven't tested it, but it should work.
.endif
cd $S/modules env MAKEOBJDIRPREFIX=${.OBJDIR}/modules ${MAKE}
install
--
|Chris Costello [EMAIL PROTECTED]
|Programmers do it bit by bit.
`--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC from today does not detect system console on my box
On Friday, June 16, 2000, Chris Costello wrote:
while (defined($arguments[0])) {
system("ls -l " . $arguments[0]);
shift @arguments;
}
Actually, just for style purposes:
for (; defined($arguments[0]); shift @arguments) {
# ... parse arguments ...
}
--
|Chris Costello [EMAIL PROTECTED]
|This time it will surely run.
`--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ports /work/ directory.
On Friday, June 16, 2000, Will Mitayai Keeso Rowe wrote: I have 10 FreeBSD servers that are a mix of FreeBSD 2.2.8-STABLE, 3-STABLE, and 4-STABLE. In the interests of saving disk space and bandwith, i have one central file archive of ports, and the three stable branches, and i mount those directories on all servers as required via amd. See this answer from the FreeBSD-Hackers archives. http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=395447+398377+/usr/local/www/db/text/1999/freebsd-hackers/19991226.freebsd-hackers -- |Chris Costello [EMAIL PROTECTED] |To iterate is human; to recurse, divine. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
ab 15.6.2000 auf CD-ROM: blackbook 2000 ch - die 1.Datenbank zum leichten und umfassenden Aufbau von** Newslettern** Kundeninformationsbriefen** Produktankuendigungen** Marketingaktionen** Offerten einholen/stellen** konzipiert für den Business to Business-Einsatz Schweiz- die Informationsdatenbank mit+ 450'000 Business-Emails der Schweiz+ 170'000 Business-Websites der Schweiz (Registrar, weitere Domains des Registrars, Kontaktinfo)+ 160'000 Kontaktadressen mit Telefon, Fax, Homepage, Email, Beruf- Suchmoeglichkeiten Homepage/Adressen nach Kanton - Beruf - Stichworten Alle Daten exportierbar in Outlook 2000 oder Textfiles zur Weiterverarbeitung.Eigene Daten importieren aus Outlook 2000 oder Textfiles. Backup/Restore eigener Daten.Lieferumfang:Datenbankprogramm - "How to's" - Groupmailprogramme - Internetmetasearchengine.(10'000 CD's zum Preis von jeweils SFr. 194.-- inklusive Porto und NN, anschliessend SFr. 364.-- --- dieses Einführungsangebot gilt nurin der Schweiz und fuer die ersten 10'000 CD's)More infos and order online onwww.eurodirector.com www.carfashop.com www.eu-sales.comwww.iq-u.com See you there!
Re: GENERIC from today does not detect system console on my box
IMHO, the hints are a machine property, not a per-kernel property. Setting up a /boot/device.hints is (IMHO) a one-time task that never needs to be done more than once, and (again IMHO) the 'make install' had damn well better not mess with. But what if one does not exist? Wouldn't it be a good bootstrapping mechanism to create one for first-time use in the install rule? Not that it matters much in my case since there are apparently no "hints" for the perl script to generate from my config file. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC from today does not detect system console on my box
Err.. how did you run it? 'perl MYKERNEL'? If you run 'perl MYKERNEL' it will generate nothing because I was kinda lame and didn't know how to do argument parsing. :-] Yep, I ran it exactly as you specified in your "HEADS UP" message to -current. It generates no output for either GENERIC or for my kernel config file: jkh@zippy- perl gethints.pl ZIPPY jkh@zippy- perl gethints.pl GENERIC jkh@zippy- which perl /usr/bin/perl jkh@zippy- /usr/bin/perl -v This is perl, version 5.005_03 built for i386-freebsd - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: HEADS UP!: config changes...
On 13-Jun-00 Peter Wemm wrote: *** CAUTION IS REQUIRED ***! FYI, an intrusive commit has been done that requires careful attention. If you ignore this or mess it up, it can burn your house down, shoot your dog, close your bank accounts, report you to the IRS, or maybe even something bad. Well, I updated today (CVSup as of 16th June 20:00 UTC) And it worked fine except 1) the generated makefile for my kernel/modules build directory was broken (missing a ; \) - I've been told this is fixed, and 2) I had 'device sc' when it should have been 'device sc 1'. I had a minor problem where the perl script generated lines like - hint.fdc.0.port=""0x3F0"" Which the loader barfed on.. easy to fix though. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
Hi, "Daniel C. Sobral" wrote: Mitsuru IWASAKI wrote: - support S2, S3, S4 (hibernation) sleeping transition. S4 sleep require some hack in boot loader needs help. I thought hibernation was entirely controlled by kernel? What do you ^^ Err, BIOS. need? Yes, we need to consider both. In ACPI spec. 1.0b 9.1.4 S4 Sleeping State, this is described that S4 supports two entry mechanisms: OS initiated and BIOS initiated. From: Intel, Microsoft, Toshiba Subject: Advanced Configuration and Power Interface Specification 1.0b Date: Tue, 2 Feb 1999 07:55:24 +0900 In the OS-initiated S4 sleeping state, the OS is responsible for saving all system context. Before entering the S4 state, the OS will save context of all memory. Upon awakening, the OS will then restore the system context. When the OS re-enumerates buses coming out of the S4 sleeping state, it will discover any devices that have come and gone, and configure devices as they are turned on. I think OS-initiated S4 (hibernation) in FreeBSD has enough advantages because we can do `Save-to-Disk' anywhere even on non-laptop machines which BIOS doesn't support hibernation. FreeBSD supports crash dump facility here, so I'm expecting that `Save-to-Disk' by kernel would not be so difficult. We might need dedicated swap partition for OS-initiated S4 because used swap areas need to be protected for the system oprerations after awakening. The boot loader is the best place for restoring the system context in FreeBSD I think. Unfortunately I don't have enough knowledge on crash dump and boot loader to implement OS-initiated S4 transition (actually, this is not related with ACPI at all). I love to see someone say `hey! I'll take this one!' :-) Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
