Re: Broken (?) unistd.h
On Wed, 27 Feb 2002, Bruce Evans wrote: On Tue, 26 Feb 2002, Bill Fenner wrote: Here's a patch for bind's port/freebsd/include/port_before.h . --- port_before.h.orig Tue Feb 26 20:57:35 2002 +++ port_before.h Tue Feb 26 21:02:18 2002 @@ -15,6 +15,7 @@ #define SETPWENT_VOID #endif +#include sys/param.h #include sys/types.h From style(9): Kernel include files (i.e. sys/*.h) come first; normally, include sys/types.h OR sys/param.h, but not both. sys/types.h includes sys/cdefs.h, and it is okay to depend on that. Based on a suggestion from someone else, I actually generated the same patch that Bill did. Without including sys/param.h, there is no definition of __FreeBSD_version at this point in the process, so the test always fails. If there is a more correct way to test, I'll be glad to use it, otherwise I'll have to go with what works. Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Are there periodic GOOD tags in CVS for -CURRENT?
On Tue, 26 Feb 2002, George V. Neville-Neil wrote: Hi Folks, I'm wondering if anyone has been laying down periodic good tags in -CURRENT so that people who are just starting with it have a place to start that is reasonably stable. Several of us have asked for this repeatedly, but it's not likely to happen. With or without a tag, at this point there is still no substitute for reading freebsd-current if you plan to run 5.0. -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Discussion of guidelines for additional version control
My general opinion is that a developer should not claim ownership of anything, it should simply be apparent from the traffic the developer posts to the public lists, discussion, and his commits. This implies that the developer is only actively working on one thing at a time, at least in regards to non-trivial projects, which further implies that the work can be committed in smaller chunks (or A smaller chunk) verses otherwise. While this ideal cannot always be met I believe it is a good basis for people working on a large project without formal management (i.e. open source). In the relatively rare case where a large rip-up must be done all at once an exception is made. For the FreeBSD project such an exception would be something like CAM or KSEs, but virtually nothing else. As an example of this I will note some non-trivial things that I have done using this model: * Implementation of idle processes. Anyone remember how long that took me? It turned out to be a good basis for further work now didn't it? * Pushing Giant through (most of) the syscall code and into the syscalls. * The critical_*() patch is an excellent example of this. The engineering cycle was 3 days (non-inclusive of all the crap that is preventing me from comitting it), and it is rock solid. * The rewrite of the swap system (In two pieces: added radix tree bitmap infrastructure, then switched out the swapper). I think my engineering cycle on this was 1.5 weeks. DG might remember better. So as you can see, from my viewpoint something like UCRED is just not that big a deal. With the infrastructure incrementally comitted and in place the final UCRED pushdown is something one could write, test, and commmit, from scratch, in just a few days. That is far more efficient then trying to keep it in a private tree for months on end, having to constantly sync it with code and algorithmic changes occuring in the rest of the tree. The same can be said for many of the other subsystems sitting in P4, like preemption. Experimental code has it's uses, but when I've gleened the information I need from one of my experiments I typically scrap the source entirely so it doesn't get in the way of other work. Later I rewrite the feature from scratch when the infrastructure has developed enough to support it. It may seem inefficient but the reality is that it speeds up my overall engineering and design cycles and, at least for me, the end result is pretty damn good code. Because I typically focus on one thing at a time, 3 days to get something simple like critical_*() done often seems like an eternity to me. I can't just switch my focus to something else, that isn't how I work. I can do a few things in parallel, like help find bugs in this or that, but real engineering cycles I do one at a time. Personally speaking if I do something complex and instrumenting it is straightforward, I always go ahead and instrument it because it makes debugging by others easy. That is why I have been and want to instrument Giant in the places where Giant is otherwise being removed, and why for example I had a sysctl to allow the critical_*() code behavior to change on the fly for testing purposes. The thing about instrumentation is that it's easy to put in if you integrate it right off the bat, and utterly trivial to rip out months or years down the line when you don't need it any more. I don't understand why people complain about 'putting in instrumentation that we'll just have to rip out later'. That kind of attitude is tantamount to saying 'I'm not going to bother to make this code debuggable because I've found all the bugs in it'. Yah, right. From my point of view instrumentation reduces the overall time required to add and stabilize a new feature, whereas someone saving source lines by not instrumenting his code is simply setting himself up for a long, buggy engineering cycle down the line (and not being a good neighbor to his peers much either). There is a damn good reason why I am rabid about instrumenting a complex piece of code. I don't care *how* long a developer has tested a big piece of code, it is simply naive to believe that anything short of exposure to the entire development community will exercise the code enough to really give it a good test. In that respect I have a strong dislike for the idea of sub-groups of developers testing a non-experimental feature (i.e. intended for commit) in a side-tree. I do not feel that it adds anything to the project and, in fact, I believe it is a detriment to the project. -Matt To Unsubscribe: send
Re: NetBSD-style rc.d Project
On Tue, 26 Feb 2002, Crist J. Clark wrote: Looking at the repository, I have not really seen anything done with building a NetBSD-style rc.d system that will provide FreeBSD functionality for a long time. Several of us have started on this, and either run out of time, or interest (as you've seen described already). There are at least three problems I can see with this project, in no particular order. A) Everyone in the project thinks they know both the problems and the solutions. B) Everyone who is willing to do actual work on the project (myself included) has strong ideas about how it should go, often incompatible with other's strong ideas. C) The real problem of making this work is actually much bigger than the just do a straight port drum that most of the people who aren't actually willing to put the work into it beat rather loudly whenever the topic comes up. Currently I don't have nearly as much time to work on this project as I thought I would by now. I moved to the bay area in september and was hoping feverishly that the many hours of overtime required to get in the groove of my new job would slow down, and to some extent they have, but I'm barely getting back up to speed on current -current, which I personally think of as a pre-req for doing the rc work. What I have always said we need before people spend a lot of time on coding is discussion about what the project should look like. If people are interested in this, I set up a discussion list on Yahoo! groups, and a few people actually subscribed. If there is still interest in discussion about what the project should look like, I think I'm ready to go on that if people still think my experience with the existing rc system is worth including. -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
Mike Silbersack wrote: On Wed, 27 Feb 2002, Mike Silbersack wrote: Disabling PG_G allows it to work here again as well. Given the problems we're experiencing, backing out the pmap changes of the last two days seems like a good idea. Mike Silby Silbersack Well, I sorta take that back. The box has been up for ~5 minutes now, and the buildworld I started hasn't paniced it yet. I guess this is workable. FWIW: I'm typing this on a kernel with that bandaid right now, but I still manage to panic it immediately by preloading smbfs.ko from the loader. kldload'ing it later works fine, though. -- Michael Nottebrock To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: setpgrp(1, 1) does not FAIL
On Wed, 27 Feb 2002 15:44:23 +0900,
HIROSHI OOTA [EMAIL PROTECTED] said:
oota The following will succeed in non privilege user.
oota I think it should fail.
oota main()
oota {
ootaprintf(%d\n, setpgrp(1, 1));
oota }
Fixed in rev 1.138 of kern/kern_prot.c, thanks!
--
Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Discussion of guidelines for additional version controlmechanisms (fwd)
In message: [EMAIL PROTECTED] George V. Neville-Neil [EMAIL PROTECTED] writes: : The problem here is process. The FreeBSD project now has more than : 12 core members and more than 12 committers. With any number larger : than 12 it is VERY HARD to reach consensus on anything. Without a : process by which we agree to reach consensus it is impossible. There are only only 8 core team members, unless you mean something different by core here than [EMAIL PROTECTED] Otherwise, I tend to agree with your basic premise that it is process and not tools at the heart of this problem. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Discussion of guidelines for additional version control mechanisms (fwd)
In message [EMAIL PROTECTED], M. Warner Losh writes: In message: [EMAIL PROTECTED] George V. Neville-Neil [EMAIL PROTECTED] writes: : The problem here is process. The FreeBSD project now has more than : 12 core members and more than 12 committers. With any number larger : than 12 it is VERY HARD to reach consensus on anything. Without a : process by which we agree to reach consensus it is impossible. There are only only 8 core team members, unless you mean something different by core here than [EMAIL PROTECTED] Otherwise, I tend to agree with your basic premise that it is process and not tools at the heart of this problem. In addition to process it might be attitude. Core@ was not elected to be ornamental. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Going to CURRENT from STABLE
Well, I've decided to go to CURRENT from STABLE, but much of the kernel sources break, because of -Werror. I solve my problem passing NO_WERROR=1 on make command line, but this was not documented. :-=(( -- Dimitar Peikov GnuPG key http://www.bgzone.com/~mitko/mitko.key.asc Key fingerprint 97AF 6192 78E2 AC68 FD56 CCB0 68B9 DF7D B3C1 9ED7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Going to CURRENT from STABLE
* Dimitar Peikov [EMAIL PROTECTED] [020227 03:54] wrote: Well, I've decided to go to CURRENT from STABLE, but much of the kernel sources break, because of -Werror. I solve my problem passing NO_WERROR=1 on make command line, but this was not documented. :-=(( Since 5.x is a moving target you should expect this sort of thing from the devel branch. Also, please wrap lines at 80 characters. -- -Alfred Perlstein [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Latest versions of bsd.lib.mk break picobsd...
On Mon, Feb 25, 2002 at 04:38:29PM -0800, George V. Neville-Neil wrote:
Hi Folks,
I've tried contacting [EMAIL PROTECTED] directly but haven't seen anything so I
figure I'll throw this out to the list. On 21 Feb 2002 a change was made to
the
You'll have to pay some money if you need a 24-hour responsiveness. :-)
bsd.lib.mk and bsd.prog.mk which is commented, in part, as:
Get rid of the (now unneeded) -I${DESTDIR}/usr/include magic in bsd.prog.mk
and bsd.lib.mk. Finish the removal of LDDESTDIR in bsd.lib.mk,v 1.55 -- we
no longer have users of it.
This change was made by ru. Alas this breaks the picobsd build since the
statically built libraries need some way to know to get their includes from the
directory you're building in. This does not affect a general 5.0 build (I checked
that this morning) but is still very problematic. I'm only just starting with the
picobsd stuff and I would love to fix this bug in the right place if only someone
could tell me what this change meant and how pervasive it was.
Putting in an extra CFLAG for -I${SRC}usr/include works for some libraries but
breaks libbind as alluded to by this comment in the same checkin:
(Attempt to move the -nostdinc -I... part of CFLAGS into the new CINCLUDES
(modeled after a similar CXXINCLUDES) eventually failed because hard-coding
${WORLDTMP}/usr/include to be the first in the include list does not always
work, e.g. lib/libbind.)
So, can someone help me out here?
What src/release PicoBSD script should I try to run to reproduce this?
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
panic: bad peter
Using ``FreeBSD 5.0-CURRENT #0: Wed Feb 27 02:00:14 EST 2002''. While cvs updating in /usr/ports: TPTE at 0xbfca0348 IS ZERO @ VA 280d2000 panic: bad peter cpuid = 0; lapic.id = 0100 Looks like there was plenty committed to src/sys in the last few hours, so I'm rebuilding the kernel now. Thanks, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Going to CURRENT from STABLE
In message: [EMAIL PROTECTED] Dimitar Peikov [EMAIL PROTECTED] writes: : Well, I've decided to go to CURRENT from STABLE, but much of the : kernel sources break, because of -Werror. I solve my problem passing : NO_WERROR=1 on make command line, but this was not documented. :-=(( It was documented when you typed config: You may need to use the make -DNO_WERROR flag if you hit unfixed warnings. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
On Tue, Feb 26, 2002 at 09:29:51PM -0800, Peter Wemm wrote:
FWIW, turning off PG_G see_ms to help. Change in pmap.c:
#if !defined(SMP) || defined(ENABLE_PG_G)
to:
#if /*!defined(SMP) ||*/ defined(ENABLE_PG_G)
and see how you go. This got me past atkbd0, but it is a very worrying
sign. I now get a vnode related panic. :-(
On my (single processor, non-acpi) system the kernel now completes
booting, but savecore receives a signal 11 after having saved about
235 MB, and all(?) processes after that get a signal 11 or 10 until
finally there's a panic: bad peter. This is absolutely reproducible.
Is there any additional information I should provide?
Bye, Philipp
savecore: writing core to /var/crash/vmcore.22
Feb 27 13:15:40 i609a savecore: reboot after panic: from debugger
pid 175 (savecore), uid 0: exited on signal 11 (core dumped)
Segmentation fault - core dumped
Doing additional network setup: ntpdpid 176 (sh), uid 0: exited on signal 10 (co
re dumped)
Bus error - core dumped
.
Starting final network daemons:.
pid 177 (sh), uid 0: exited on signal 11 (core dumped)
Segmentation fault - core dumped
pid 178 (sh), uid 0: exited on signal 11 (core dumped)
Segmentation fault - core dumped
Starting standard daemons: inetdpid 179 (sh), uid 0: exited on signal 11 (core d
umped)
[...]
Additional TCP options:pid 213 (sh), uid 0: exited on signal 10 (core dumped)
Bus error - core dumped
pid 214 (sh), uid 0: exited on signal 11 (core dumped)
Segmentation fault - core dumped
.
Starting background filesystem checks
Wed Feb 27 13:16T:44 CET 2002
PTE at 0xbfc20404 IS ZERO @ VA 08101000
panic: bad peter
Debugger(panic)
Stopped at Debugger+0x40: xorl%eax,%eax
db
save a crash dump and reboot into old kernel
This GDB was configured as i386-unknown-freebsd...Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 2629
in elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 935
in fill_symbuf
IdlePTD at phsyical address 0x003ff000
initial pcb at physical address 0x0032f8c0
panicstr: from debugger
panic messages:
---
panic: bad peter
panic: from debugger
Uptime: 1m31s
pfs_vncache_unload(): 1 entries remaining
dumping to dev ad0s1b, offset 589952
dump ata0: resetting devices .. ata0: mask=03 ostat0=50 ostat2=00
ad0: ATAPI 00 00
ata0-slave: ATAPI 00 00
ata0: mask=03 stat0=50 stat1=00
ad0: ATA 01 a5
ata0: devices=01
ad0: invalidating queued requests
ad0: success setting PIO4 on generic chip
done
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:504
504 if (!dodump)
(kgdb) bt
#0 dumpsys () at ../../../kern/kern_shutdown.c:504
#1 0xc01a2117 in boot (howto=260) at ../../../kern/kern_shutdown.c:336
#2 0xc01a25a1 in panic (fmt=0xc02a772a from debugger)
at ../../../kern/kern_shutdown.c:646
#3 0xc013784d in db_panic (addr=-1071127031, have_addr=0, count=-1,
modif=0xcf3adb10 ) at ../../../ddb/db_command.c:452
#4 0xc01377eb in db_command (last_cmdp=0xc02ed424, cmd_table=0xc02ed244,
aux_cmd_tablep=0xc02e4020, aux_cmd_tablep_end=0xc02e4024)
at ../../../ddb/db_command.c:348
#5 0xc01378b7 in db_command_loop () at ../../../ddb/db_command.c:474
#6 0xc0139c4b in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc027e326 in kdb_trap (type=3, code=0, regs=0xcf3adc0c)
at ../../../i386/i386/db_interface.c:161
#8 0xc028ac18 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
tf_edi = -1077804028, tf_esi = 256, tf_ebp = -818226092,
tf_isp = -818226120, tf_ebx = -1070734913, tf_edx = 1017, tf_ecx = 1,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071127148, tf_cs = 8,
tf_eflags = 582, tf_esp = -1070742881, tf_ss = -1070895941})
at ../../../i386/i386/trap.c:589
#9 0xc027e594 in Debugger (msg=0xc02b6cbb panic) at machine/cpufunc.h:66
#10 0xc01a258c in panic (fmt=0xc02de1bf bad peter)
at ../../../kern/kern_shutdown.c:633
#11 0xc0289019 in pmap_remove_pages (pmap=0xcd2fadec, sva=0,
Re: Going to CURRENT from STABLE
On Wed, 27 Feb 2002 06:44:19 MST, M. Warner Losh wrote: It was documented when you typed config: You may need to use the make -DNO_WERROR flag if you hit unfixed warnings. Output from config(8) is lost in the noise when you use the buildkernel target. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Discussion of guidelines for additional version control mechanisms (fwd)
One of the disagreements that seems to be evolving is whether or not the project formally supports a task-oriented structure. A couple of people have asserted that people might claim tasks (such as myself) and by virtue of claiming the task, be provided with some notion of ownership that is supported in a more formal sense. Others have pointed out that in a volunteer environment, people simply do what they want to regardless of any task ownership, and would prefer a first-past-the-post model to a task ownership model. My assumption had been that disagreement existed to some extent based on the nature and strength of ownership, but it seems that I've made a fundamental assumption there that not everyone agrees with. My feeling has always been that imposing some modicrum of structure is important: to avoid people stepping on toes, people can announce what they're working on, and expect that others might avoid replicating the work, or at least be communicated with before it happens. The rationale for this lies both in efficiency (non-replication of work), and to avoid toe-stepping, since there's a natural notion of ownership over work done, and a desire to not see it discarded. Perhaps this can't be supported in our environment. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Broken (?) unistd.h
On Wed, 27 Feb 2002, Doug Barton wrote: On Wed, 27 Feb 2002, Bruce Evans wrote: From style(9): Kernel include files (i.e. sys/*.h) come first; normally, include sys/types.h OR sys/param.h, but not both. sys/types.h includes sys/cdefs.h, and it is okay to depend on that. Based on a suggestion from someone else, I actually generated the same patch that Bill did. Without including sys/param.h, there is no definition of __FreeBSD_version at this point in the process, so the test always fails. If there is a more correct way to test, I'll be glad to use it, otherwise I'll have to go with what works. Include the necessary header, but not both. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
valgrind
hi, I found this tool called valgrind (http://devel-home.kde.org/~sewardj/) a few days ago and find it really interesting. It is something similair to purify (memory use debugger one could call it I guess) but GPL'ed and developed by the KDE team from what I can tell. I have been looking for this kind of tool for a long time and haven't found one I really like yet. As it is right now valgrind is x86linux 2.4 specific (probably gcc specific too..) but I would really love to see a FreeBSD port. It should be quite possible to port the OS specific parts to handle FreeBSD systemcalls instead of Linux ones. Is anyone already looking in to this or interested? It would be a great tool to debug the base system with as well as your own applications. -- ---. Patrik SundbergAddress: Rydsvägen 100C, 584 31 Linköping, Sweden | Email: [EMAIL PROTECTED] || [EMAIL PROTECTED] | Phone: +46 13 178567 || +46 707 602240| .--- Applied Physics and Electrical Engineering student | |- Master of Science in Business Administration and Economics student | |--- UNIX/Programming consultant | `--' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
double panic in todays kernel
Using ``FreeBSD 5.0-CURRENT #1: Wed Feb 27 09:07:28 EST 2002''.
While building some port (-pipe probably played its fatal role)...
-mi
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /boot/mi/kernel
(kgdb) core-file /ccd/crash/vmcore.28
IdlePTD at phsyical address 0x004f4000
initial pcb at physical address 0x00418120
panicstr: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id =
fault virtual address = 0xa4
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc023ea63
stack pointer = 0x10:0xcf9a0c14
frame pointer = 0x10:0xcf9a0c30
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 = 23591 (bzip2)
trap number = 12
panic: page fault
cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id =
boot() called on cpu#1
Uptime: 51m48s
pfs_vncache_unload(): 8 entries remaining
dumping to dev da0b, offset 131200
dump 319 318 [...] 1 0
---
#0 dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:504
504 if (!dodump)
(kgdb) where
#0 dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:504
#1 0xc0220d54 in boot (howto=260) at /ccd/src/sys/kern/kern_shutdown.c:336
#2 0xc0221245 in panic (fmt=0xc03790b8 bwrite: buffer is not busy???)
at /ccd/src/sys/kern/kern_shutdown.c:646
#3 0xc0259043 in bwrite (bp=0xc7d1aa34) at /ccd/src/sys/kern/vfs_bio.c:676
#4 0xc025a2ca in vfs_bio_awrite (bp=0xc7d1aa34)
at /ccd/src/sys/kern/vfs_bio.c:1526
#5 0xc01f7168 in spec_fsync (ap=0xcf9a0ad0)
at /ccd/src/sys/fs/specfs/spec_vnops.c:403
#6 0xc01f6d21 in spec_vnoperate (ap=0xcf9a0ad0)
at /ccd/src/sys/fs/specfs/spec_vnops.c:121
#7 0xc02e45d8 in ffs_sync (mp=0xc16d2a00, waitfor=2, cred=0xc102eb80,
td=0xc03d5c00) at vnode_if.h:441
#8 0xc0266212 in sync (td=0xc03d5c00, uap=0x0)
at /ccd/src/sys/kern/vfs_syscalls.c:669
#9 0xc0220980 in boot (howto=256) at /ccd/src/sys/kern/kern_shutdown.c:245
#10 0xc0221245 in panic (fmt=0xc0397dde %s)
at /ccd/src/sys/kern/kern_shutdown.c:646
#11 0xc032fd16 in trap_fatal (frame=0xcf9a0bd4, eva=164)
at /ccd/src/sys/i386/i386/trap.c:848
#12 0xc032fa3d in trap_pfault (frame=0xcf9a0bd4, usermode=0, eva=164)
at /ccd/src/sys/i386/i386/trap.c:762
#13 0xc032f503 in trap (frame={tf_fs = -1069940712, tf_es = -819986416,
tf_ds = -812187632, tf_edi = -812170240, tf_esi = 4096,
tf_ebp = -811987920, tf_isp = -811987968, tf_ebx = 0,
tf_edx = -812170240, tf_ecx = -811987824, tf_eax = -830089152,
tf_trapno = 12, tf_err = 0, tf_eip = -1071388061, tf_cs = 8,
tf_eflags = 66178, tf_esp = -1069695296, tf_ss = 4096})
at /ccd/src/sys/i386/i386/trap.c:430
#14 0xc023ea63 in pipe_write (fp=0xc20751c0, uio=0xcf9a0c90, cred=0xc2d32a80,
flags=0, td=0xcf974400) at /ccd/src/sys/kern/sys_pipe.c:820
#15 0xc023b834 in dofilewrite (td=0xcf974400, fp=0xc20751c0, fd=1,
buf=0x83ef000, nbyte=4096, offset=-1, flags=0)
at /ccd/src/sys/sys/file.h:191
#16 0xc023b62d in write (td=0xcf974400, uap=0xcf9a0d20)
at /ccd/src/sys/kern/sys_generic.c:337
#17 0xc033015c in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134640440, tf_esi = 138342400, tf_ebp = -1077947856,
tf_isp = -811987596, tf_ebx = 134640440, tf_edx = 138342400,
tf_ecx = 134640440, tf_eax = 4, tf_trapno = 0, tf_err = 2,
tf_eip = 134611567, tf_cs = 31, tf_eflags = 663, tf_esp = -1077947884,
tf_ss = 47}) at /ccd/src/sys/i386/i386/trap.c:1044
#18 0xc031f7ed in syscall_with_err_pushed ()
#19 0x805e2ff in ?? ()
#20 0x805db5f in ?? ()
#21 0x805daa9 in ?? ()
#22 0x80488d8 in ?? ()
(kgdb) up 14
#14 0xc023ea63 in pipe_write (fp=0xc20751c0, uio=0xcf9a0c90, cred=0xc2d32a80,
flags=0, td=0xcf974400) at /ccd/src/sys/kern/sys_pipe.c:820
820 PIPE_LOCK(wpipe);
(kgdb) p wpipe
$1 = (struct pipe *) 0x0
(kgdb) l
815 struct pipe *wpipe, *rpipe;
816
817 rpipe = (struct pipe *) fp-f_data;
818 wpipe = rpipe-pipe_peer;
819
820 PIPE_LOCK(wpipe);
821 /*
822 * detect loss of pipe read side, issue SIGPIPE if lost.
823 */
824 if ((wpipe == NULL) || (wpipe-pipe_state PIPE_EOF)) {
(kgdb) p rpipe
$2 = (struct pipe *) 0x0
(kgdb) p fp
$3 = (struct file *) 0xc20751c0
(kgdb) p fp-f_data
$4 = 0xce85d840
(kgdb) p *fp
$5 = {f_list = {le_next = 0xc256c500, le_prev = 0xc181a700}, f_gcflag = 0,
f_type = 3, f_count = 2, f_msgcount = 0, f_cred = 0xc2d32a80,
f_ops = 0xc03dbec0, f_seqcount = 1, f_nextoff = 0, f_offset = 0,
f_data = 0xce85d840 , f_flag = 3, f_mtxp = 0xc0417970}
(kgdb) up
#15 0xc023b834 in dofilewrite (td=0xcf974400,
Re: valgrind
I'm working on porting this right now. Be forewarned, though, that the FreeBSD hacks for this tool will *never* be allowed into the main distro. Why? Licence. Valgrind includes some code from the Linux kernel and libc. When we hack it for FreeBSD, we'll end up putting some BSD-licenced code into a GPL product. Obviously, this will cause problems. Afaik, the patches can remain part of the ports tree without problems. -- Matthew Emmerton || [EMAIL PROTECTED] GSI Computer Services || http://www.gsicomp.on.ca On Wed, 27 Feb 2002, Patrik Sundberg wrote: hi, I found this tool called valgrind (http://devel-home.kde.org/~sewardj/) a few days ago and find it really interesting. It is something similair to purify (memory use debugger one could call it I guess) but GPL'ed and developed by the KDE team from what I can tell. I have been looking for this kind of tool for a long time and haven't found one I really like yet. As it is right now valgrind is x86linux 2.4 specific (probably gcc specific too..) but I would really love to see a FreeBSD port. It should be quite possible to port the OS specific parts to handle FreeBSD systemcalls instead of Linux ones. Is anyone already looking in to this or interested? It would be a great tool to debug the base system with as well as your own applications. -- ---. Patrik SundbergAddress: Rydsvägen 100C, 584 31 Linköping, Sweden | Email: [EMAIL PROTECTED] || [EMAIL PROTECTED] | Phone: +46 13 178567 || +46 707 602240| .--- Applied Physics and Electrical Engineering student | |- Master of Science in Business Administration and Economics student | |--- UNIX/Programming consultant | `--' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Discussion of guidelines for additional version control mechanisms (fwd)
: My feeling has always been that imposing some modicrum of structure is : important: to avoid people stepping on toes, people can announce what : they're working on, and expect that others might avoid replicating the : work, or at least be communicated with before it happens. The rationale : for this lies both in efficiency (non-replication of work), and to avoid : toe-stepping, since there's a natural notion of ownership over work done, : and a desire to not see it discarded. Perhaps this can't be supported in : our environment. In the past, we haven't been strictly a first one past the post project. We have rejected things as not being ready for inclusion in FreeBSD all the time. Jon Chen's Cardbus work was the second or third effort that was presented to FreeBSD. It was the first one acceptable to those folks that took a look at it. Sure, it had its problems, but it was something that could be worked with and people generally agreed that it was the direction we wanted to go. The first one that was presented worked as well, but there were some issues with the direction that it took, so we didn't integrate it. We had the first CardBus implementation almost 9 months or a year before the second one. Of course, looking at the past to get precedent can be dicy, since we've done many things right as a project and many things wrong. :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: valgrind
On Wed, Feb 27, 2002 at 11:00:14AM -0500, Matthew Emmerton wrote: I'm working on porting this right now. great news! what is the current status and have you set up a website for the project or will it be a simple portsentry with some patches? (I thought it would require some more rewriting than a usual port+patches, but I could be wrong, haven't looked at the code yet). Be forewarned, though, that the FreeBSD hacks for this tool will *never* be allowed into the main distro. Why? Licence. Valgrind includes some code from the Linux kernel and libc. When we hack it for FreeBSD, we'll end up putting some BSD-licenced code into a GPL product. Obviously, this will cause problems. as long as it can exist in the ports-collection I will be more than pleased. -- ---. Patrik SundbergAddress: Rydsvägen 100C, 584 31 Linköping, Sweden | Email: [EMAIL PROTECTED] || [EMAIL PROTECTED] | Phone: +46 13 178567 || +46 707 602240| .--- Applied Physics and Electrical Engineering student | |- Master of Science in Business Administration and Economics student | |--- UNIX/Programming consultant | `--' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: setpgrp(1, 1) does not FAIL
Can you look into PR kern/29844 as well?
I think after your fix, it should fail even when invoked by super
user.
Regards,
In article [EMAIL PROTECTED],
Seigo Tanimura [EMAIL PROTECTED] wrote:
On Wed, 27 Feb 2002 15:44:23 +0900,
HIROSHI OOTA [EMAIL PROTECTED] said:
oota The following will succeed in non privilege user.
oota I think it should fail.
oota main()
oota {
ootaprintf("%d\n", setpgrp(1, 1));
oota }
Fixed in rev 1.138 of kern/kern_prot.c, thanks!
--
$B$5$M$r(B (SANETO Takanori) // [$B
Re: valgrind
On Wed, Feb 27, 2002 at 11:00:14AM -0500, Matthew Emmerton wrote: Be forewarned, though, that the FreeBSD hacks for this tool will *never* be allowed into the main distro. Why? Licence. Valgrind includes some code from the Linux kernel and libc. When we hack it for FreeBSD, we'll end up putting some BSD-licenced code into a GPL product. Obviously, this will cause problems. Actually, this doesn't cause as many as you might think. GPL'd code can swallow BSDL'd code. BSDL'd code cannot swallow GPL'd code. You could probably get your code assimilated into the main valgrind distro. FreeBSD also includes (among others) gdb, which is GPL'd. Since valgrind is not necessary to run a minimal FreeBSD install, it's OK. (Note that I'm not advocating assimilating it into the main system, I'm just saying that the license isn't an impediment. :-) ==ml -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons http://www.blackhelicopters.org/~mwlucas/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-Current is stable enough for use again
FWIW, now that Peter has temporarily backed out his pmap-related changes, -current has stabilized again. Those who were having trouble with panics on boot (or within a few minutes after) with kernels built during the last day or two should definitely cvsup. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's panic on boot problem
Peter Wemm wrote: Mike Silbersack wrote: On Tue, 26 Feb 2002, Peter Wemm wrote: Mike Silbersack wrote: Hm, sounds like UP got optimized out. Gah! That would be a first. :( Well, until I can build a working kernel, I'll just assume that it's a feature. FWIW, turning off PG_G see_ms to help. Change in pmap.c: #if !defined(SMP) || defined(ENABLE_PG_G) to: #if /*!defined(SMP) ||*/ defined(ENABLE_PG_G) and see how you go. This got me past atkbd0, but it is a very worrying sign. I now get a vnode related panic. :-( I've reread the changes about 50 times now and cannot for the life of me see why it works for SMP but not UP. I'm about ready to back it all out. I believe I know what the problem is. Turn off PG_PSE using DISABLE_PSE in your config. If that fixes it, back the code out. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -Current is stable enough for use again
Date: Wed, 27 Feb 2002 10:52:38 + (GMT) From: Mike Silbersack [EMAIL PROTECTED] FWIW, now that Peter has temporarily backed out his pmap-related changes, -current has stabilized again. Those who were having trouble with panics on boot (or within a few minutes after) with kernels built during the last day or two should definitely cvsup. Confirmed: freebeast(5.0-C)[7] uname -a FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Feb 27 07:24:36 PST 2002 [EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST i386 freebeast(5.0-C)[8] (My SMP build machine) Given the nature of what we were seeing, after booting that kernel, I set the box to doing a make -j 16 buildworld; once that finishes, I'll do another with -j4 But -CURRENT does seem to be in much better shape now than it was 24 hours ago. :-} Recent CVSup times: freebeast(5.0-C)[8] tail /var/log/cvsup-history.log CVSup begin from cvsup14.freebsd.org at Sun Feb 24 03:47:03 PST 2002 CVSup ended from cvsup14.freebsd.org at Sun Feb 24 03:53:45 PST 2002 CVSup begin from cvsup14.freebsd.org at Mon Feb 25 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Mon Feb 25 03:53:57 PST 2002 CVSup begin from cvsup14.freebsd.org at Mon Feb 25 10:01:00 PST 2002 CVSup ended from cvsup14.freebsd.org at Mon Feb 25 10:07:56 PST 2002 CVSup begin from cvsup14.freebsd.org at Tue Feb 26 03:47:03 PST 2002 CVSup ended from cvsup14.freebsd.org at Tue Feb 26 03:53:30 PST 2002 CVSup begin from cvsup14.freebsd.org at Wed Feb 27 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Wed Feb 27 03:53:38 PST 2002 freebeast(5.0-C)[9] 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
Re: setpgrp(1, 1) does not FAIL
[Please write in us-ascii]
On Thu, 28 Feb 2002 01:39:11 +0900,
Takanori Saneto [EMAIL PROTECTED] said:
Takanori Can you look into PR kern/29844 as well?
Takanori I think after your fix, it should fail even when invoked by super
Takanori user.
The superuser fails as well.
Takanori In article [EMAIL PROTECTED],
Takanori Seigo Tanimura [EMAIL PROTECTED] wrote:
On Wed, 27 Feb 2002 15:44:23 +0900,
HIROSHI OOTA [EMAIL PROTECTED] said:
oota The following will succeed in non privilege user.
oota I think it should fail.
oota main()
oota {
oota printf(%d\n, setpgrp(1, 1));
oota }
Fixed in rev 1.138 of kern/kern_prot.c, thanks!
--
Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: valgrind
Matthew Emmerton wrote: I'm working on porting this right now. Be forewarned, though, that the FreeBSD hacks for this tool will *never* be allowed into the main distro. Why? Licence. Valgrind includes some code from the Linux kernel and libc. When we hack it for FreeBSD, we'll end up putting some BSD-licenced code into a GPL product. Obviously, this will cause problems. Afaik, the patches can remain part of the ports tree without problems. Add a dlopen-based module interface? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: you broke current in some weird way... etc
:date: 2002/02/27 09:51:32; author: peter; state: Exp; lines: +245 -191 :Back out all the pmap related stuff I've touched over the last few days. :There is some unresolved badness that has been eluding me, particularly :affecting uniprocessor kernels. Turning off PG_G helped (which is a bad :sign) but didn't solve it entirely. Userland programs still crashed. I'm just going to use this opportunity to plug the concept of temporary sysctl-instrumentation for a commit like this. I'm not saying that sysctl instrumentation will catch such problems every time, or that it is appropriate in all cases, but if you had done it and turning off the sysctl had stopped the crashes you could have simply committed a change to the sysctl default. This would have stopped the breakage in the general community and give you time to track the problem down with the aid of those specific developers who reported the problem. This rather then backing out the entire commit which creates additional disruption and makes it difficult to solicit help from the people reporting the problem. I'm just going to contrast this with my critical_*() commit - the whiners that forced the backout aside, if the commit had stayed in and through normal developer testing was found to be buggy, the fact that it is instrumented would have (1) made validation of the bug easy, (2) allowed developers to get back to a working system without having to back anything out, and (3) it DID greatly improve my ability to follow-up with Ian to track the bug down, again without him having to back anything out. The length of time one keeps the instrumentation is heavily dependant on the feature being instrumented. For critical_*() I expect to keep the instrumentation intact only for a two or three months. For Giant wrappers I intend to keep it intact through the 5.0 release. Another example would be something like vfs.vmiodirenable. This sysctl allowed three or four developers to track down VMIO-backed directory bugs over a period of a year in stable without effecting our userbase. I recently made it the default and I'll probably remove the instrumentation entirely within the next two releases or so. I can't even begin guessing how much time and effort that sysctl has saved me. It's a win-win proposition. just a thought. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: valgrind
Michael Lucas wrote: Actually, this doesn't cause as many as you might think. GPL'd code can swallow BSDL'd code. BSDL'd code cannot swallow GPL'd code. You could probably get your code assimilated into the main valgrind distro. No, it can't. You can't change the license on the original code, or you lose your rights granted under that license. The only thing that works for swallowing is an aggregate license. In the vgrind case, that is not an option. FreeBSD also includes (among others) gdb, which is GPL'd. Since valgrind is not necessary to run a minimal FreeBSD install, it's OK. (Note that I'm not advocating assimilating it into the main system, I'm just saying that the license isn't an impediment. :-) Distribution of the binary is a problem as long as there is a license miscibility issue. Distribution of the components is allowed. As an example, you can't build a FreeBSD with a statically linked IBM JFS port in it (and therefore you can't boot from an IBM JFS with a distribution kernel), but you can distribute an IBM JFS as a binary kernel module with accompanying source code (all under the GPL). Doing this really skirts dangerously close to the interface GPL'ing issue that FSF used to try and beat some crypto into GPL-land; I would not want to be a test case for this. This is why FreeBSD lets people use GPL'ed components as an after market item, but does not distribute them: it is in the ditribution that the clause activates. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: you broke current in some weird way... etc
Matthew Dillon wrote: :date: 2002/02/27 09:51:32; author: peter; state: Exp; lines: +245 -191 :Back out all the pmap related stuff I've touched over the last few days. :There is some unresolved badness that has been eluding me, particularly :affecting uniprocessor kernels. Turning off PG_G helped (which is a bad :sign) but didn't solve it entirely. Userland programs still crashed. I'm just going to use this opportunity to plug the concept of temporary sysctl-instrumentation for a commit like this. Overall, this is a good idea. However, it can't apply to any code that runs before init_main.c runs the SI_SUB_TUNABLES. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Discussion of guidelines for additional version control mechanisms (fwd)
In addition to process it might be attitude. It might be a stretch but they are kind of the same. Good processes come from good attitude. It is extraordinarily hard for most people (especially smart people) to be introspective on such questions when they think they already have the answer. Sometimes people think that because something works for them it will work in a group. But we know that's not always the case. So, how do we get our attitudes adjusted before hitting a wall, as many companies I've worked for did? It comes back to agreeing on a process by which we work. We have one now, it may not all be written down, but we do have it. Later, George -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 Those who would trade liberty for temporary security deserve neither - Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Discussion of guidelines for additional version controlmechanisms (fwd)
In message: [EMAIL PROTECTED] George V. Neville-Neil [EMAIL PROTECTED] writes: : There are only only 8 core team members, unless you mean something : different by core here than [EMAIL PROTECTED] : : I guess I was going based on the meeting I attended back at BSD Con. The last core meeting at BSDcon had 9 members. Since then asami-san has left core. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Latest versions of bsd.lib.mk break picobsd...
You'll have to pay some money if you need a 24-hour responsiveness. :-) The check is in the mail ;-) What src/release PicoBSD script should I try to run to reproduce this? -CURRENT as of Monday. Things work fine in a checkout from 20 Feb 2002 and that's what I'm working with. If you can give me a bit of info (or a place to look) I can help address this problem. I'm going to try to work with Luigi on maintaining picobsd as this will be my main development system. It's a very good way for embedded systems hacks (like myself) to work. Very natural. And it's nice that I don't have to worry about having -CURRENT on my development machine. Later, George -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 Those who would trade liberty for temporary security deserve neither - Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Discussion of guidelines for additional version control mechanisms (fwd)
+---[ George V. Neville-Neil ]-- | In addition to process it might be attitude. | | | So, how do we get our attitudes adjusted before hitting a wall, | as many companies I've worked for did? Alcohol and a cam-corder d8) -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Discussion of guidelines for additional version controlmechanisms (fwd)
In message: [EMAIL PROTECTED] George V. Neville-Neil [EMAIL PROTECTED] writes: : So, how do we get our attitudes adjusted before hitting a wall, : as many companies I've worked for did? It comes back to agreeing : on a process by which we work. We have one now, it may not all : be written down, but we do have it. That's the $64k question. Our current worst case is the rock tumbler school of management. You put everybody together in one big hopper and spin. This knockes the rough edges off people. However, it doesn't take into account differing hardness of the material that people are made from so sometimes you end up with a hard rough rock and dust, which is not a desirable outcome. We have a process that varies depending on who you ask. Some of that variance is simple imprecision of words, while some of it is wishful thinking (maybe unconscious) about what can and can't be done. Our established guidelines work well when they work, but do not handle the degenerate cases where someone has life happen or when there's a fundamental disagreement. In those cases, we're back to the rock tumbler school of management. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Discussion of guidelines for additional version control mechanisms (fwd)
One of the disagreements that seems to be evolving is whether or not the project formally supports a task-oriented structure. A couple of people have asserted that people might claim tasks (such as myself) and by virtue of claiming the task, be provided with some notion of ownership that is supported in a more formal sense. Others have pointed out that in a volunteer environment, people simply do what they want to regardless of any task ownership, and would prefer a first-past-the-post model to a task ownership model. My assumption had been that disagreement existed to some extent based on the nature and strength of ownership, but it seems that I've made a fundamental assumption there that not everyone agrees with. My feeling has always been that imposing some modicrum of structure is important: to avoid people stepping on toes, people can announce what they're working on, and expect that others might avoid replicating the work, or at least be communicated with before it happens. The rationale for this lies both in efficiency (non-replication of work), and to avoid toe-stepping, since there's a natural notion of ownership over work done, and a desire to not see it discarded. Perhaps this can't be supported in our environment. I think we need to avoid the concept of imposing some modicum of structure. If we create structure it is because we need it. Just like software. There was a good comment recently about software gets created to scratch an itch. I'd say that structure gets created because you're tired of losing fingers and toes to the person next to you wielding the axe. It's great that your friends are helping you clear the forest but you'd all like to be able to walk and pick up your cup of coffee at the end of the day as well. We are always going to have first past the post problems. If someone comes along and has rewritten a whole subsystem, and testing and performance measurement show that it's an order of magnitude better (faster, smaller, etc.) than what we have we'd be idiots not to take it, right? The question is What processes do we need to put in place to make a project of this size and dynamisticity work? I put forward a few of them. I suggest we start somewhere (including airing gripes people have with the current system) and write down (i.e. build a web page, use TWiki) what we're going to do about it. I hate to make this analogy but we need a constitution or something like it. Not so grandiose of course, but a written set of rules and are easy to interpret that can take care of the 80% case. The 20% we'll always get to argue over but I'd rather not argue over the 100%. Later, George -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 Those who would trade liberty for temporary security deserve neither - Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: you broke current in some weird way... etc
Matthew Dillon wrote: : I'm just going to use this opportunity to plug the concept of temporary : sysctl-instrumentation for a commit like this. : :Overall, this is a good idea. However, it can't apply to :any code that runs before init_main.c runs the SI_SUB_TUNABLES. Sure it does, because it means you can simply commit a change to the default assignment for that sysctl rather then backing the whole thing out to unbreak the general developer community. That saves a lot of time and removes the 'oh hell, I have to track this down quickly!' pressure. Sometimes features in early boot can be adjusted by breaking into DDB and w/l changing the sysctl variable, but perhaps not in this case. Definitely not in this case. Similarly, there are a number of early allocations that occur by declaration, rather than by process, where the page mappings are then established post-facto, where it won't work. I really need to publish my early life of FreeBSD article. 8-(. I have all my extensive notes together, but I think it's at least a three-parter, and I need to expand the examples. I'll get around to it eventually, I promise. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: you broke current in some weird way... etc
In message [EMAIL PROTECTED] Matthew Dillon writes: : Sometimes features in early boot can be adjusted by breaking into DDB : and w/l changing the sysctl variable, but perhaps not in this case. I think this is an excellent idea. I have many of these tunables in the cardbus/oldcard code and it has helped me to diagnose many problems. All my stuff runs after SI_SUB_TUNABLES, so that's not an issue. Of course, not much happens before SUB_TUNABLES, but Peter's changes look like they might be one of them. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Is Adaptec ATA Raid Supported
I am looking for a mid-range Raid solution for my database server. I hate to put down a significant chunk of change for SCSI Raid for a website that still doesn't quite pay its bills. Now for my question. I was looking at an: Adaptec ATA RAID 2400A controller card. It is a four channel ATA/100 raid controller with up to 128MB onboard cache and it support Levels 0,1,0+1 and 5. Looks real promising, but I cannot see any support for it in ata-raid.[ch]. Will the current code support this card? Or are there plans to add it in the near future? tia, - brian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: usb product identified as ugen
You don't mention how your kernel is presently configured or what other troubleshooting you've done, so all you can hope to receive are wild guesses like: - Configure a kernel with the umass, scbus, and da devices, along with the standard usb devices. This is documented in both the GENERIC config file and NOTES (as I assume that you are running -current) - The device may not declare itself as a mass-storage device. It may need some custom driver that only exists for Windows. - There may be a bug. Scott On Wed, 2002-02-27 at 11:08, Riccardo Torrini wrote: A friend of mime give me (only for some days) an external usb hard disk device (a normal ide 2.5 with an interface from ide to usb, self powered). When I attach I got this info, I need it show as umass to mount the msdos (fat32) file system on it, right? Need I some special kernel configuration? Like adding the scsi subsystem or that misterious device is not supported? Or other stuff that don't get loaded automagically? (I manually wrapped long lines) # usbdevs -v -d Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x), \ VIA(0x), rev 1.00 uhub0 port 1 powered port 2 addr 2: full speed, power 400 mA, config 1, \ product 0x07d1(0x07d1), ScanLogic(0x04ce), rev 1.05 ugen0 TIA, Riccardo. 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: Discussion of guidelines for additional version controlmechanisms (fwd)
Hi Folks, I've put up the following TWiki page: http://www.neville-neil.com/twiki/bin/view/Freebsd/DevelopmentProcess as a scribbling area for a possible set of rules/practices that we can use to address the issues raised in this discussion. For those not familiar with TWiki who want to know what this is before scribbling please start here: www.twiki.org Later, George -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 Those who would trade liberty for temporary security deserve neither - Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is Adaptec ATA Raid Supported
On Wed, 2002-02-27 at 11:32, Wm Brian McCane wrote: I am looking for a mid-range Raid solution for my database server. I hate to put down a significant chunk of change for SCSI Raid for a website that still doesn't quite pay its bills. Now for my question. I was looking at an: Adaptec ATA RAID 2400A controller card. It is a four channel ATA/100 raid controller with up to 128MB onboard cache and it support Levels 0,1,0+1 and 5. Looks real promising, but I cannot see any support for it in ata-raid.[ch]. Will the current code support this card? Or are there plans to add it in the near future? The 2400A is supported by the asr driver. This driver is part of the GENERIC kernel, so it should work right out-of-the-box for you. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is xe building while commented out?
On Wed, Feb 27, 2002 at 03:44:03PM +0100, Christopher Sharp wrote: * Stephen L. Palmer ([EMAIL PROTECTED]) wrote: /usr/src/sys/dev/isp/isp.c: In function `isp_reset': /usr/src/sys/dev/isp/isp.c:633: warning: cast discards qualifiers from pointer target type *** Error code 1 A small workaround is to change: -const u_int16_t *dv_ispfw; /* ptr to f/w */ +u_int16_t *dv_ispfw; /* ptr to f/w */ in src/sys/dev/isp/ispvar.h:76 I don't know if this is ok but I does at least make the kernel build and should not hurt as long as you don't use the isp device Fixes to make it compile are not desired. Fixes that are are *FIXES* are. If you are unable to understand why dv_ispfw is `const'; just follow the advice of adding: makeoptions NO_WERROR=true to your kernel configuration. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is xe building while commented out?
On Wed, 27 Feb 2002, David O'Brien wrote: Fixes to make it compile are not desired. Fixes that are are *FIXES* are. If you are unable to understand why dv_ispfw is `const'; just follow the advice of adding: makeoptions NO_WERROR=true to your kernel configuration. Did that last night. Ended up with a kernel that blew up on boot, but from reading, that's what others were getting on UP systems as well. It was not urgent for me to rebuild, just trying to get a working kernel with sound installed. It can wait a day or three as needed for a stable build, I've got a good kernel from Feb 08 to run on until then. FWIW, I agree with your Fixes should fix something ideal. I'm slowly getting to the point where I can understand some of the code, but I'm no kernel hacker yet. One of these days I'll start testing the waters with patch submissions, but not until I feel I understand the system a bit better. Thanks! Stephen L. Palmer [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NetBSD-style rc.d Project
On Wed, Feb 27, 2002 at 02:02:11AM -0800, Doug Barton wrote: On Tue, 26 Feb 2002, Crist J. Clark wrote: Looking at the repository, I have not really seen anything done with building a NetBSD-style rc.d system that will provide FreeBSD functionality for a long time. Several of us have started on this, and either run out of time, or interest (as you've seen described already). There are at least three problems I can see with this project, in no particular order. A) Everyone in the project thinks they know both the problems and the solutions. B) Everyone who is willing to do actual work on the project (myself included) has strong ideas about how it should go, often incompatible with other's strong ideas. C) The real problem of making this work is actually much bigger than the just do a straight port drum that most of the people who aren't actually willing to put the work into it beat rather loudly whenever the topic comes up. Currently I don't have nearly as much time to work on this project as I thought I would by now. I moved to the bay area in september and was hoping feverishly that the many hours of overtime required to get in the groove of my new job would slow down, and to some extent they have, but I'm barely getting back up to speed on current -current, which I personally think of as a pre-req for doing the rc work. What I have always said we need before people spend a lot of time on coding is discussion about what the project should look like. If people are interested in this, I set up a discussion list on Yahoo! groups, and a few people actually subscribed. If there is still interest in discussion about what the project should look like, I think I'm ready to go on that if people still think my experience with the existing rc system is worth including. I am interested. -- Regards Cliff Sarginson -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Latest versions of bsd.lib.mk break picobsd...
On Wed, Feb 27, 2002 at 09:49:28AM -0800, George V. Neville-Neil wrote: You'll have to pay some money if you need a 24-hour responsiveness. :-) The check is in the mail ;-) What src/release PicoBSD script should I try to run to reproduce this? -CURRENT as of Monday. Things work fine in a checkout from 20 Feb 2002 and that's what I'm working with. If you can give me a bit of info (or a place to look) I can help address this problem. I'm going to try to work with Luigi on maintaining picobsd as this will be my main development system. It's a very good way for embedded systems hacks (like myself) to work. Very natural. And it's nice that I don't have to worry about having -CURRENT on my development machine. This still doesn't answer my question -- how can I reproduce the problem? cd /foo/bar make grrr Something like that... 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
Financial freedom / One-up Club!! 59291914119
$750/DAY IN 20 DAYS! AMAZING ONE-UP PLAN GENERATES CASH FASTER THAN EVER BEFORE! FEATURES: * One-Time $50 Out-of-Pocket! * One Invitee To Qualify Forever! * Two To Cash In! * Administration Fee Only $20/Year! * Monthly Residuals Forever! Here's How It Works: Day 1: Invite one person Day 2: Invite 2nd person..$50 breakeven Day 3: Gift from one up$50 Day 4: Gift from one up$50 Day 5: Gift from one up$50 Day 6: Gift from one up$50 Day 7: Gift from one up$50 Day 8: Gift from one up$50 Day 9: Gift from one up$50 Total Cash by Day 10 = $400 + $50/day forever Day 10 Join $200 level$50 Day 11 1st $200 one up..$250 Day 12 Gift from one up...$250 Day 13 Gift from one up...$250 Day 14 Gift from one up...$250 Day 15 Gift from one up...$250 Day 16 Gift from one up...$250 Total Cash by Day 17 = $1950 + $250/day forever Day 17 Join $500 level$250 Day 18 1st $500 gift.$750 Day 19 Gift from one up...$750 Day 20 Gift from one up...$750 TOTAL CASH BY DAY 20 = $4450 + $750/DAY (that's $21,000/month!) FOREVER! Designed for the below average networker to succeed! Invite More Than Two To Make Even More! Proven Internet Marketing System Provides YOU With All The Motivated ContactsYou Want! Say Good-Bye To All MLM Pay Plans, Board Pay Plans, Matrix Pay Plans, Binary Pay Plans, and Linear Pay Plans, and Say Good-Bye to Wasteful and Ineffective Marketing . . . And Say Hello To Financial Freedom! We have a proven duplicateable system in place for you to be successful very quickly. Respond IMMEDIATELY [leave Ph #] to reserve your FREE 10k Bulk e-mail[ limited openings] For your PRIVATE INVITATION to this incredible opportunity, type I am interested in the subject line of your e-mail, and you will be conacted promptly with all the details to your financial freedom!. PLEASE LEAVE PH#. Name:_ Email: Phone: mailto:[EMAIL PROTECTED]?subject=I_am_interested FREE 10K BULK e-broadcast for FIRST 10 people that register leaving PHONE # Control YOUR destiny and take a step TODAY toward YOUR financial freedom!!! THE FASTEST, EASIEST WAY TO FINANCIAL FREEDOM . . . PERIOD! THIS PROVEN SYSTEM REALLY WORKS! A COMPLETE INSTRUCTION MANUAL IS AVAILABLE TO INSURE YOUR SUCCESS THE FINANCIAL FREEDOM SYSTEM [12 pages] Yours for FINANCIAL FREEDOM, PS: Please put Remove in subject line to get out from future mailing. thanks. 59291914119 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
controversial fix or some errors breaking LINT
There are saveral places (e.g. if_ie.c) where data is copied out of a buffer that is shared with the hardware. The pointer to this is correctly labelled as volatile, though at the time we will copy the data out we know it to be stable. the problem is that it uses bcopy() to do this, and that generates teh error message ../../../dev/ie/if_ie.c:1232: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type ../../../dev/ie/if_ie.c:1232: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type which is now fatal. Now since it is also possible to copy data INTO a volatile shared buffer it seems logical to allow bcopy to do so. A while ago I proposed the following patch: /* * Note: the volatile below does not REQUIRE that the argument be * volatile, but rather ony says that it is OK to use a volatile * i * there. Same for the const. I know a const volatile sounds strange * but it only indicates that either is acceptable. */ voidbcopy __P((volatile const void *from, volatile void *to, size_t len)); NOW we can get rid of lots of UGLY casting tricks here and there that have been used to try UNVOLATILE things so thay they can use bcopy. I suggest a similar addition to a few other standard operations. Hopefully the BUS-space stuff should be used eventually but I'm not going to rewrite if_ie.c. are you? (I've also seem this used in the IPV6 code but I think thye've been (yukky) cast'ed by now. julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: controversial fix or some errors breaking LINT
:/* : * Note: the volatile below does not REQUIRE that the argument be : * volatile, but rather ony says that it is OK to use a volatile * i : * there. Same for the const. I know a const volatile sounds strange : * but it only indicates that either is acceptable. : */ :voidbcopy __P((volatile const void *from, volatile void *to, size_t :len)); : :NOW we can get rid of lots of UGLY casting tricks here and there that :have been used to try UNVOLATILE things so thay they can use bcopy. :I suggest a similar addition to a few other standard operations. : :Hopefully the BUS-space stuff should be used eventually :but I'm not going to rewrite if_ie.c. are you? :(I've also seem this used in the IPV6 code but I think :thye've been (yukky) cast'ed by now. : :julian I really don't like this. I mean, it will work but I really don't like this. Volatile in C will effectively prevent optimization of read and write accesses to the data the pointer is pointing at. Of course, this is bcopy(), which we implement in assembly, so again it will work for bcopy(). But it sets a very bad coding precedent. I would keep the casts. It reminds us that there is something funny going on. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: controversial fix or some errors breaking LINT
ok so I leave it to other people to fix LINT I'm not going near it any more one small example: ../../../dev/ie/if_ie.c:1471: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../../dev/ie/if_ie.c:1480: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../../dev/ie/if_ie.c:1483: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../../dev/ie/if_ie.c:1508: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type it's so obviously the right way that I'm amazed that there can even be discussion. (except that I know Bruce didn't lik eit before) (he and jhb just actualy created more errors in LINT by removing a volatile on the definition of bzero in the kernel.) (the above fatal errors are new and brought to you by the people who just did that removal) remember folks.. this is the kernel here.. what Posix says doesn't count INSIDE the kernel. We deal wit devices inside the kernel. we have a LOT of volatile stuff. It may be worth creating a vbcopy and vbzero to handle volatile stuff then. (But I think it's a stupid thing to need to do) the bus-space mess should have stuff to do this but no-one who understands it has had teh energy to actually fix this stuff with it. so we are stuck with a broken LINT. On Wed, 27 Feb 2002, Matthew Dillon wrote: :/* : * Note: the volatile below does not REQUIRE that the argument be : * volatile, but rather ony says that it is OK to use a volatile * i : * there. Same for the const. I know a const volatile sounds strange : * but it only indicates that either is acceptable. : */ :voidbcopy __P((volatile const void *from, volatile void *to, size_t :len)); : :NOW we can get rid of lots of UGLY casting tricks here and there that :have been used to try UNVOLATILE things so thay they can use bcopy. :I suggest a similar addition to a few other standard operations. : :Hopefully the BUS-space stuff should be used eventually :but I'm not going to rewrite if_ie.c. are you? :(I've also seem this used in the IPV6 code but I think :thye've been (yukky) cast'ed by now. : :julian I really don't like this. I mean, it will work but I really don't like this. Volatile in C will effectively prevent optimization of read and write accesses to the data the pointer is pointing at. Of course, this is bcopy(), which we implement in assembly, so again it will work for bcopy(). But it sets a very bad coding precedent. I would keep the casts. It reminds us that there is something funny going on. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: controversial fix or some errors breaking LINT
: :ok so I leave it to other people to fix LINT :I'm not going near it any more It's the responsibility of whoever added -Werror to the default compile to unbreak the tree, either by fixing the problem or by backing out his commit. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: controversial fix or some errors breaking LINT
* Matthew Dillon [EMAIL PROTECTED] [020227 14:51] wrote: : :ok so I leave it to other people to fix LINT :I'm not going near it any more It's the responsibility of whoever added -Werror to the default compile to unbreak the tree, either by fixing the problem or by backing out his commit. No. Leave it in, this will benifit us all in the long run. In fact it was the _only_ way I was able to get people clean up bad code at a former job and I strongly support keeping -Weerror enabled. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: controversial fix or some errors breaking LINT
No. Leave it in, this will benifit us all in the long run. Until we start hitting the broken/buggy warnings, which will cause people to write more obfuscated or harder to maintain code in order to avoid the warnings. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: controversial fix or some errors breaking LINT
At 1:27 PM -0800 2/27/02, Julian Elischer wrote: There are saveral places (e.g. if_ie.c) where data is copied out of a buffer that is shared with the hardware. The pointer to this is correctly labelled as volatile, though at the time we will copy the data out we know it to be stable. Note: at the time we will copy the data ... we know A while ago I proposed the following patch: /* * Note: the volatile below does not REQUIRE that the argument be * volatile, but rather ony says that it is OK to use a volatile * i * there. Same for the const. I know a const volatile sounds strange * but it only indicates that either is acceptable. */ voidbcopy __P((volatile const void *from, volatile void *to, size_t len)); This will always allow bcopy to do the copy to or from any volatile location, even if the call is done at a bad time. Any programmer calling bcopy should at least get a little flag waved at them if they are working with volatile arguments. How philosophically sickening would it be to create a macro: #define bcopy_volatile(x,y) bcopy((casts)x,(casts)y) so that you can have cleaner-looking source code, but still have it so the programmer has to *explicitly* say Yes, I know I am dealing with volatile memory here. -- 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
Re: usb product identified as ugen
On 27-Feb-2002 (18:35:18/GMT) Scott long wrote: You don't mention how your kernel is presently configured or what other troubleshooting you've done, so all you can hope to receive are wild guesses like: Usually I don't make stupid questions (I think), sorry for wasting your time, but after 4 auto-reboot on last 24 hours I'm not sure of nothing, even of my name :) - Configure a kernel with the umass, scbus, and da devices, along with the standard usb devices. This is documented in both the GENERIC config file and NOTES... Sorry, last time I checked comment I got (for device umass): USB Iomega Zip 100 Drive (Requires scbus and da) so I think that was only for Zip, not for all. (as I assume that you are running -current) Yes, of course (from 3.0). I missing only da devices :( Going to rebuild world and kernel... [...after 4 hours...] puff, puff, pant, pant... reboot... :( The same, ugen0, ugen0.1 and ugen0.2 but build seems fine, it compile all world and kernel without need of NO_WERROR. - There may be a bug. A bug would be better than a need for a custom driver for win. Have you any idea of what can I check now? Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: controversial fix or some errors breaking LINT
Alfred Perlstein wrote: * Matthew Dillon [EMAIL PROTECTED] [020227 14:51] wrote: : :ok so I leave it to other people to fix LINT :I'm not going near it any more It's the responsibility of whoever added -Werror to the default compile to unbreak the tree, either by fixing the problem or by backing out his commit. No. Leave it in, this will benifit us all in the long run. In fact it was the _only_ way I was able to get people clean up bad code at a former job and I strongly support keeping -Weerror enabled. If there are files that are too hard to fix, or vendor files, or the fix isn't clear, we should use the nowerror conf/files* flags. It is important that we stop new warnings turning up when the compile output is so damn large that it hides things. I will do a pass over things now and see what I can do. 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: controversial fix or some errors breaking LINT
On Wed, Feb 27, 2002 at 03:15:09PM -0800, Peter Wemm wrote: If there are files that are too hard to fix, or vendor files, or the fix isn't clear, we should use the nowerror conf/files* flags. It is important that we stop new warnings turning up when the compile output is so damn large that it hides things. I definatly agree. The warnings in gif(4) were mostly lame and should have been fixed, but no one bothered. I will do a pass over things now and see what I can do. Please make sure to test the !SMP case. The following slipped through the initial sweep: Index: kern_sig.c === RCS file: /usr/cvs/src/sys/kern/kern_sig.c,v retrieving revision 1.149 diff -u -r1.149 kern_sig.c --- kern_sig.c 23 Feb 2002 11:12:54 - 1.149 +++ kern_sig.c 26 Feb 2002 19:37:00 - @@ -1233,7 +1233,9 @@ register int prop; register sig_t action; struct thread *td; +#ifdef SMP struct ksegrp *kg; +#endif KASSERT(_SIG_VALID(sig), (psignal(): invalid signal %d\n, sig)); -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg35466/pgp0.pgp Description: PGP signature
Re: controversial fix or some errors breaking LINT
It's not my problem as jhb has volunteered to fix all these. :-) we just add an entry point for bcopy_volatile() next to that for bcopy. (I called it vbcopy in my suggestion.) bzero has the same thing bzero_volatile() I guess. Though I still feel that it breaks POLA to not be able to use bcopy and bzero. On Wed, 27 Feb 2002, Garance A Drosihn wrote: At 1:27 PM -0800 2/27/02, Julian Elischer wrote: There are saveral places (e.g. if_ie.c) where data is copied out of a buffer that is shared with the hardware. The pointer to this is correctly labelled as volatile, though at the time we will copy the data out we know it to be stable. Note: at the time we will copy the data ... we know A while ago I proposed the following patch: /* * Note: the volatile below does not REQUIRE that the argument be * volatile, but rather ony says that it is OK to use a volatile * i * there. Same for the const. I know a const volatile sounds strange * but it only indicates that either is acceptable. */ voidbcopy __P((volatile const void *from, volatile void *to, size_t len)); This will always allow bcopy to do the copy to or from any volatile location, even if the call is done at a bad time. Any programmer calling bcopy should at least get a little flag waved at them if they are working with volatile arguments. How philosophically sickening would it be to create a macro: #define bcopy_volatile(x,y) bcopy((casts)x,(casts)y) so that you can have cleaner-looking source code, but still have it so the programmer has to *explicitly* say Yes, I know I am dealing with volatile memory here. -- 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
Re: controversial fix or some errors breaking LINT
I presume then that you also feel that allowing bcopy to copy volatile regions is a bad idea? On Wed, 27 Feb 2002, Peter Wemm wrote: Alfred Perlstein wrote: * Matthew Dillon [EMAIL PROTECTED] [020227 14:51] wrote: : :ok so I leave it to other people to fix LINT :I'm not going near it any more It's the responsibility of whoever added -Werror to the default compile to unbreak the tree, either by fixing the problem or by backing out his commit. No. Leave it in, this will benifit us all in the long run. In fact it was the _only_ way I was able to get people clean up bad code at a former job and I strongly support keeping -Weerror enabled. If there are files that are too hard to fix, or vendor files, or the fix isn't clear, we should use the nowerror conf/files* flags. It is important that we stop new warnings turning up when the compile output is so damn large that it hides things. I will do a pass over things now and see what I can do. 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: controversial fix or some errors breaking LINT
In message p05101410b8a31356bb54@[128.113.24.47] Garance A Drosihn writes: : How philosophically sickening would it be to create a macro: : : #define bcopy_volatile(x,y) bcopy((casts)x,(casts)y) How about just using bus_space in these drivers? That's the right solution and isn't too hard to do. I'm working on the wl driver right now. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: usb product identified as ugen
On Wed, 2002-02-27 at 16:07, Riccardo Torrini wrote: On 27-Feb-2002 (18:35:18/GMT) Scott long wrote: You don't mention how your kernel is presently configured or what other troubleshooting you've done, so all you can hope to receive are wild guesses like: Usually I don't make stupid questions (I think), sorry for wasting your time, but after 4 auto-reboot on last 24 hours I'm not sure of nothing, even of my name :) Yes, I've had those kinds of days also =-) - Configure a kernel with the umass, scbus, and da devices, along with the standard usb devices. This is documented in both the GENERIC config file and NOTES... Sorry, last time I checked comment I got (for device umass): USB Iomega Zip 100 Drive (Requires scbus and da) so I think that was only for Zip, not for all. It's commented in the 'device umass' line in GENERIC, but that's not a big deal. Is the umass device compiled into the kernel, or loaded as a module? If it's a module, is it loaded before you attach the drive? The usb daemon isn't smart enough yet to load it, it seems. Thus, you must load it manually, else the ugen driver will claim the device. (as I assume that you are running -current) Yes, of course (from 3.0). I missing only da devices :( Going to rebuild world and kernel... The da device is certainly required, though not having would give you different symptoms, or so I think. Try adding the da device and see what happens. [...after 4 hours...] puff, puff, pant, pant... reboot... :( The same, ugen0, ugen0.1 and ugen0.2 but build seems fine, it compile all world and kernel without need of NO_WERROR. - There may be a bug. A bug would be better than a need for a custom driver for win. Have you any idea of what can I check now? The USB_DEBUG, UGEN_DEBUG, and UMASS_DEBUG kernel options might be helpful. Scott Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: controversial fix or some errors breaking LINT
sure.. does bus-space have a bzero? On Wed, 27 Feb 2002, Warner Losh wrote: In message p05101410b8a31356bb54@[128.113.24.47] Garance A Drosihn writes: : How philosophically sickening would it be to create a macro: : : #define bcopy_volatile(x,y) bcopy((casts)x,(casts)y) How about just using bus_space in these drivers? That's the right solution and isn't too hard to do. I'm working on the wl driver right now. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: you broke current in some weird way... etc
On Wed, Feb 27, 2002 at 09:33:48AM -0800, Matthew Dillon wrote: I'm just going to use this opportunity to plug the concept of temporary sysctl-instrumentation for a commit like this. Any thoughts on having a root oid for sysctl oids like this, so they're not forgotten, and aren't assumed by anyone to be permanent? tmp.foo.bar or similar? N -- FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Projecthttp://www.freebsd.org/docproj/\\\'',) \/ \ ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/_) msg35472/pgp0.pgp Description: PGP signature
Re: you broke current in some weird way... etc
:On Wed, Feb 27, 2002 at 09:33:48AM -0800, Matthew Dillon wrote: : I'm just going to use this opportunity to plug the concept of tempora= :ry : sysctl-instrumentation for a commit like this. =20 : :Any thoughts on having a root oid for sysctl oids like this, so they're :not forgotten, and aren't assumed by anyone to be permanent? : : tmp.foo.bar : :or similar? : :N We have a 'debug' OID, that's what I used for debug.critical_mode. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: controversial fix or some errors breaking LINT
In message: [EMAIL PROTECTED] Julian Elischer [EMAIL PROTECTED] writes: : does bus-space have a bzero? Effectively yes. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: usb product identified as ugen
On 27-Feb-2002 (23:17:15/GMT) Scott Long wrote: I forgot this piece of messages, it happens only once, when I manually detached usb cable but never again when I rescan it. -8-[ messages ]-8- ...kernel: ugen0: at uhub0 port 2 (addr 2) disconnected ...kernel: ugen0: detached ...kernel: usbd_new_device: addr=2, getting first desc failed ...kernel: uhub0: device problem, disabling port 2 ...kernel: umass0: USB to IDE USB to IDE, rev 1.10/2.60, \ addr 2, 8070i (ATAPI) over Bulk-Only ...kernel: umass0: Max Lun is 0 ...kernel: umass-sim:0:-1:-1:XPT_PATH_INQ:. ...kernel: umass0:0:0:-1: Attached to scbus0 as device 0 ...kernel: scbus0: scanning for umass0:0:0:-1 ...kernel: umass-sim:0:-1:-1:XPT_PATH_INQ:. Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: usb product identified as ugen
On 27-Feb-2002 (23:17:15/GMT) Scott Long wrote: Is the umass device compiled into the kernel, or loaded as a module? If it's a module, is it loaded before you attach the drive? The usb daemon isn't smart enough yet to load it... Now I have all compiled in. Something happens... -8-[ from my kernel ]-8- options DEBUG #Guess :) # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device pass# Passthrough device (direct SCSI access) # USB support device uhci# UHCI PCI-USB interface device usb # USB Bus (required) device ugen# Generic device umass # Disks/Mass storage - Requires scbus+da device uscanner# Scanners # Hints from Scott Long options USB_DEBUG options UGEN_DEBUG options UMASS_DEBUG -8-[ dmesg ]-8- uhci0: VIA 83C572 USB controller port 0xe400-0xe41f irq 10 \ at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ugen0: ScanLogic product 0x07d1, rev 1.00/1.05, addr 2 All test with and without verbose boot, single or normal has no differences but when I detached usb cable _after_ boot it show up as umass0 (at least into the /var/log/messages). Also doing a manual camcontrol rescan 0 have same results. I attach (part of) messages (compressed), sorry for that. Anyway, ugen0 disappear from /dev/ but _no_ umass0 appear, only xpt0... Riccardo. messages.gz Description: messages.gz
Re: controversial fix or some errors breaking LINT
Peter Wemm wrote: Alfred Perlstein wrote: * Matthew Dillon [EMAIL PROTECTED] [020227 14:51] wrote: : :ok so I leave it to other people to fix LINT :I'm not going near it any more It's the responsibility of whoever added -Werror to the default compile to unbreak the tree, either by fixing the problem or by backing out his commit. No. Leave it in, this will benifit us all in the long run. In fact it was the _only_ way I was able to get people clean up bad code at a former job and I strongly support keeping -Weerror enabled. If there are files that are too hard to fix, or vendor files, or the fix isn't clear, we should use the nowerror conf/files* flags. It is important that we stop new warnings turning up when the compile output is so damn large that it hides things. I will do a pass over things now and see what I can do. LINT now compiles, FWIW. 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
lock order reversal (vfs_syscalls.c)
I got this message on today's -current: lock order reversal 1st 0xc036afc0 allproc @ ../../../kern/vfs_syscalls.c:452 2nd 0xc7ecce34 filedesc structure @ ../../../kern/vfs_syscalls.c:457 -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: setpgrp(1, 1) does not FAIL
thanks for your quick fixing. but, It should return EPERM instead of ESRCH. Because ESRCH means `The requested process does not exist'. thanks, -- HIROSHI OOTA [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: controversial fix or some errors breaking LINT
* Peter Wemm [EMAIL PROTECTED] [020227 15:44] wrote: Alfred Perlstein wrote: * Matthew Dillon [EMAIL PROTECTED] [020227 14:51] wrote: : :ok so I leave it to other people to fix LINT :I'm not going near it any more It's the responsibility of whoever added -Werror to the default compile to unbreak the tree, either by fixing the problem or by backing out his commit. No. Leave it in, this will benifit us all in the long run. In fact it was the _only_ way I was able to get people clean up bad code at a former job and I strongly support keeping -Weerror enabled. If there are files that are too hard to fix, or vendor files, or the fix isn't clear, we should use the nowerror conf/files* flags. It is important that we stop new warnings turning up when the compile output is so damn large that it hides things. I will do a pass over things now and see what I can do. Agreed, any doofus that obfuscates code to mask a warning gets a kick in the pants at the next BSDcon. If you don't know then ask. (I know I'll be asking Bruce/Peter if I have a problem) -- -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: usb product identified as ugen
On Thu, Feb 28, 2002 at 01:39:55AM +0100, Riccardo Torrini wrote: On 27-Feb-2002 (23:17:15/GMT) Scott Long wrote: Is the umass device compiled into the kernel, or loaded as a module? If it's a module, is it loaded before you attach the drive? The usb daemon isn't smart enough yet to load it... Now I have all compiled in. Something happens... [...] Anyway, ugen0 disappear from /dev/ but _no_ umass0 appear, only xpt0... Riccardo. The debug trace looks very good. No umass0 device should appear in /dev. Instead, you should get a da device. Do 'camcontrol devlist -v' and you should see the bus (represented as umass-sim) and a 'da' and 'pass' device for the drive. It also sounds like you have other issues with the device not always attaching or detaching correctly. This is a weakness of the umass driver, so you'll have to experiment a bit to see what works for you. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: usb product identified as ugen
On 28-Feb-2002 (05:05:40/GMT) Scott Long wrote:
Anyway, ugen0 disappear from /dev/ but _no_ umass0 appear,
only xpt0...
The debug trace looks very good.
I think this is the only good news...
No umass0 device should appear in /dev. Instead, you should
get a da device. Do 'camcontrol devlist -v' and you should
see the bus (represented as umass-sim) and a 'da' and 'pass'
device for the drive.
The only difference in /dev was -ugen{0,0.1,0.2} +xpt0 :(
# camcontrol rescan 0
Re-scan of bus 0 was successful
# camcontrol devlist -v
scbus0 on umass-sim0 bus 0:
scbus-1 on xpt0 bus 0:
at scbus-1 target -1 lun -1 (xpt0)
It also sounds like you have other issues with the device
not always attaching or detaching correctly.
You mean broken usb, broken device or bad luck?
This is a weakness of the umass driver, so you'll have to
experiment a bit to see what works for you.
I'm here. I can _any_ sort of experiment you may need (except
opening case of external hd :-)
Riccardo.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Latest versions of bsd.lib.mk break picobsd...
This still doesn't answer my question -- how can I reproduce the problem? cd /foo/bar make grrr Something like that... Whoops, sorry. To reproduce this do: cd /usr/src ./release/picobsd/build/picobsd --src /usr/src --init yes, I know that --src is unnecessary but I always use it since I'm often using a tree that's NOT at /usr/src so I include it here. The --init will break with: mkdep -f .depend -a -nostdinc -DSTANDARD_INCLUDE_DIR=/home/gnn/FreeBSD/src.latest../usr/include -I/home/gnn/FreeBSD/src.latest/lib/csu/i386-elf/../common /home/gnn/FreeBSD/src.latest/lib/csu/i386-elf/crt1.c /home/gnn/FreeBSD/src.latest/lib/csu/i386-elf/crt1.c:32: stddef.h: No such file or directory /home/gnn/FreeBSD/src.latest/lib/csu/i386-elf/crt1.c:33: stdlib.h: No such file or directory In file included from /home/gnn/FreeBSD/src.latest/lib/csu/i386-elf/crt1.c:34: /home/gnn/FreeBSD/src.latest/lib/csu/i386-elf/../common/crtbrand.c:28: sys/param.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /home/gnn/FreeBSD/src.latest/lib/csu/i386-elf. *** Error code 1 Stop in /home/gnn/FreeBSD/src.latest. *** Error code 1 Stop in /home/gnn/FreeBSD/src.latest. --- fail: Error 1 error code libraries in Error: failed while making libraries --- Aborting ./release/picobsd/build/picobsd Later, George -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 Those who would trade liberty for temporary security deserve neither - Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: setpgrp(1, 1) does not FAIL
On Thu, 28 Feb 2002 13:18:06 +0900, HIROSHI OOTA [EMAIL PROTECTED] said: oota but, It should return EPERM instead of ESRCH. Because ESRCH oota means `The requested process does not exist'. Setpgrp(2) should fail in this case because pid 1 (which is usually init(8)) is not a child of the curproc, not due to insufficient privilege. ESRCH means that the target process is not found in the children of the curproc. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
