Broken world (was Re: cvs commit: src/lib/libc/posix1e cap_text.c)
Robert Watson <[EMAIL PROTECTED]> writes: > rwatson 2001/08/30 19:12:00 PDT > > Modified files: > lib/libc/posix1e cap_text.c > Log: > o Remove definition of CAP_MAX_BUF_LEN since it is defined in > sys/capability.h now. > > Submitted by: tmm > Obtained from: TrustedBSD Project > > Revision ChangesPath > 1.4 +5 -2 src/lib/libc/posix1e/cap_text.c This seems to break world on my Alpha. The error is: /usr/src/lib/libc/../libc/posix1e/cap_text.c:293: `CAP_MAX_BUF_LEN' undeclared CAP_MAX_BUF_LEN doesn't seem to be defined in rev 1.8 of capability.h. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New release date for FreeBSD 5.0-RELEASE
At 03:46 PM 8/30/2001 -0700, jkh wrote: >* >* The projected ship date for FreeBSD 5.0-RELEASE is now November 1st, 2002 * >* While I'd like to see 5.0 ship as much as the next guy, one thing I've always respected is FreeBSD's **honest** focus on quality. Thank you, --chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ipfw syntax - should this error?
The following ipfw commands produce an error. Could we make this work: ipfw add allow udp from any to any lowport,higherport1-higherport2 Instead of ipfw add allow udp from any to any highport1-highport2,lowpot Could we make this work: ipfw add allow udp from any to any range1-range2, range3-range4 Instead of having to do ipfw add allow udp from any to any range1-range2 ipfw add allow udp from any to any range3-range4 fog# uname -a FreeBSD fog.hill.hom 4.4-RC FreeBSD 4.4-RC #0: Thu Aug 30 15:02:13 EDT 2001 david@fog:/usr/src/sys/compile/FOG i386 Thanks David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE: How often diff'ed ?
On 31-Aug-01 Peter Wemm wrote: > Julian Elischer wrote: >> The diff file is updated automatically one per hour >> from the P4 repository that we are working on. >> it IS possible that yuo might catch it at a time when what is in teh >> repository may not match what is in -current but generally that should not >> last to long. >> (depends on how often one of us does an MFC from -current) > > I can make a cvsup'able collection and do a live replication of the kse > branch into a cvs tree.. I think having a p4 -> cvs duplicator up so people can cvsup any of the stuff currently in p4 for testing would be nice. It would also be good practice for the future. *wink* *wink* *nudge* *nudge* Also, I think that you don't need to make the KSE diff track -current so tightly. Use a label for when you last integrate from head, and make your diff relative to that. The diff will then just be the KSE stuff and should apply to all but really drastic changes. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE: How often diff'ed ?
Julian Elischer wrote: > The diff file is updated automatically one per hour > from the P4 repository that we are working on. > it IS possible that yuo might catch it at a time when what is in teh > repository may not match what is in -current but generally that should not > last to long. > (depends on how often one of us does an MFC from -current) I can make a cvsup'able collection and do a live replication of the kse branch into a cvs tree.. > On Thu, 30 Aug 2001, Carlo Dapor wrote: > > > Julian > > > > How often do You plan to produce diff files ? > > I can not spend too much time in the next 2 to 3 weeks, since I will be tra vel- > > ling most of the time. > > > > Ciao, derweil, > > -- > > Carlo > > > > 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 > > 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: KSE: How often diff'ed ?
The diff file is updated automatically one per hour from the P4 repository that we are working on. it IS possible that yuo might catch it at a time when what is in teh repository may not match what is in -current but generally that should not last to long. (depends on how often one of us does an MFC from -current) On Thu, 30 Aug 2001, Carlo Dapor wrote: > Julian > > How often do You plan to produce diff files ? > I can not spend too much time in the next 2 to 3 weeks, since I will be travel- > ling most of the time. > > Ciao, derweil, > -- > Carlo > > 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: another panic (mix ppp and usb to taste)
On 30 Aug, Nick Hibma wrote:
> /usr/sbin/ppp -quiet -direct -nat <> /dev/ugen0.1
>
I was confused by the following from ppp's man-page:
-direct
This is used for receiving incoming connections. ppp ignores
the ``set device'' line and uses descriptor 0 as the link.
which seems to imply, I don't need to care the descriptor 1 :-)
> USB is NOT a serial protocol. It has nothing in common with a serial
> port.
The reason I tried this, was finding a Linux how-to guide for making the
ppp over USB work between a PDA (Palm or Handsrping) and the Linux
machine. It mentioned having to install the "Handspring module" or
something to work with /dev/ttyUSB (sp?). I figured, I'll try it with a
ugen-device...
Could we have such a device-module too, BTW? Similar to the serial
modems we already have? Or will you just I suggest I write it myself
:-)?
> P.S.: The reason why it crashes is that it looks for an endpoint
> descriptor for endpoint 0 which doesn't exist. I'll fix that.
Yeah, but it seems, that just a few lines above the crash, it checks for
the sce being non-NULL... Or is it an optimization artifact?
Thanks,
-mi
> On Fri, 24 Aug 2001, Mikhail Teterin wrote:
>
>> As I was trying to let the Palm Pilot connect to my desktop
>> through usb using PPP, I tried to run
>>
>> /usr/sbin/ppp -quiet -direct -nat < /dev/ugen0
>>
>> While, perhaps, not the right way to do what I want (what is? aren't
>> serial devices the simplest?), it should not panic (nothing should
>> really). But it does, and quite repeatedly (some more comments after
>> the trace):
>>
>> IdlePTD 4984832
>> initial pcb at 3db040
>> panicstr: bwrite: buffer is not busy???
>> panic messages:
>> ---
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 0; lapic.id = 0100
>> fault virtual address = 0x3
>> fault code = supervisor read, page not present
>> instruction pointer = 0x8:0xc01d5a0b
>> stack pointer = 0x10:0xce7f1c4c
>> frame pointer = 0x10:0xce7f1c58
>> 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 = 442 (ppp)
>> trap number = 12
>> panic: page fault
>> cpuid = 0; lapic.id = 0100
>> boot() called on cpu#0
>>
>> syncing disks... panic: bwrite: buffer is not busy???
>> cpuid = 0; lapic.id = 0100
>> boot() called on cpu#0
>> Uptime: 10m14s
>>
>> dumping to dev da0b, offset 131200
>> dump ... 2 1 0
>> ---
>> [...]
>> #12 0xc030b0bc in trap (frame={tf_fs = -1071644648, tf_es = -830734320,
>> tf_ds = 16777232, tf_edi = 64, tf_esi = 0, tf_ebp = -830530472,
>> tf_isp = -830530504, tf_ebx = -1049243648, tf_edx = -1049243428,
>> tf_ecx = 34, tf_eax = 0, tf_trapno = 12, tf_err = 0,
>> tf_eip = -1071818229, tf_cs = 8, tf_eflags = 66178,
>> tf_esp = -830530412, tf_ss = -1049288448})
>> at ../../../i386/i386/trap.c:405
>> #13 0xc01d5a0b in ugenpoll (dev=0xc1752100, events=64, p=0xce7abb80)
>> at ../../../dev/usb/ugen.c:1369
>> #14 0xc01ed604 in spec_poll (ap=0xce7f1c94)
>> at ../../../fs/specfs/spec_vnops.c:333
>> #15 0xc01ed27d in spec_vnoperate (ap=0xce7f1c94)
>> at ../../../fs/specfs/spec_vnops.c:119
>> #16 0xc0252333 in vn_poll (fp=0xc17328c0, events=64, cred=0xc1734700,
>> p=0xce7abb80) at vnode_if.h:381
>> #17 0xc0228b8b in selscan (p=0xce7abb80, ibits=0xce7f1d48,
>> obits=0xce7f1d3c, nfd=1) at ../../../sys/file.h:192
>> #18 0xc02286b5 in select (p=0xce7abb80, uap=0xce7f1f80)
>> at ../../../kern/sys_generic.c:772
>> #19 0xc030bf2d in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
>> tf_edi = 134842880, tf_esi = 134842880, tf_ebp = 0,
>> tf_isp = -830529580, tf_ebx = 3, tf_edx = 134996480,
>> tf_ecx = 134996352, tf_eax = 93, tf_trapno = 12, tf_err = 2,
>> tf_eip = 673178596, tf_cs = 31, tf_eflags = 643,
>> tf_esp = -1077937708, tf_ss = 47}) at ../../../i386/i386/trap.c:1129
>> (kgdb) up 13
>> #13 0xc01d5a0b in ugenpoll (dev=0xc1752100, events=64, p=0xce7abb80)
>> at ../../../dev/usb/ugen.c:1369
>> 1369switch (sce->edesc->bmAttributes & UE_XFERTYPE) {
>> (kgdb) p sce
>> $1 = (struct ugen_endpoint *) 0x0
>> (kgdb) l
>> 1364printf("ugenpoll: no pipe\n");
>> 1365return (EIO);
>> 1366}
>> 1367#endif
>> 1368s = splusb();
>> 1369switch (sce->edesc->bmAttributes & UE_XFERTYPE) {
>> 1370case UE_INTERRUPT:
>> 1371if (events & (POLLIN | POLLRDNORM)) {
>> 1372if (sce->q.c_cc > 0)
>> 1373revents |= events & (POLLIN | POLLRDNORM);
>> (kgdb) p events
>> $3 = 64
>> (kgdb) p s
>> No symbol "s" in current context.
>> (kgdb) p revents
>> $5 = 0
>>
>> What I don't unders
PATCH: if_tap device cloning
Hackers, Below some patches that implements device cloning (with devfs(5) support) for tap(4) device. The implementation is based on resource manager (just like tun(4) and gif(4)). Please review, test and if there is no objection commit. If there are any problems, please let me know. http://home.earthlink.net/~evmax/tap-current/if_tap.c.context.diff.gz http://home.earthlink.net/~evmax/tap-current/if_tapvar.h.context.diff.gz http://home.earthlink.net/~evmax/tap-current/tap.4.context.diff.gz if you do not like context diff substitute "context" with "unified" :) thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
KSE: How often diff'ed ?
Julian How often do You plan to produce diff files ? I can not spend too much time in the next 2 to 3 weeks, since I will be travel- ling most of the time. Ciao, derweil, -- Carlo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: another panic (mix ppp and usb to taste)
What you are doing doesn't work for sure. You are piping in and out of
the control enpoint which won't work. Perhaps
/usr/sbin/ppp -quiet -direct -nat <> /dev/ugen0.1
would work, if there is an endpoint 1-in and an endpoint 1-out and they
are both related to data transfer. Normally this is not the case. See
the 3Com 5605 modem.
USB is NOT a serial protocol. It has nothing in common with a serial
port.
Nick
P.S.: The reason why it crashes is that it looks for an endpoint
descriptor for endpoint 0 which doesn't exist. i'll fix that.
On Fri, 24 Aug 2001, Mikhail Teterin wrote:
> As I was trying to let the Palm Pilot connect to my desktop
> through usb using PPP, I tried to run
>
> /usr/sbin/ppp -quiet -direct -nat < /dev/ugen0
>
> While, perhaps, not the right way to do what I want (what is? aren't
> serial devices the simplest?), it should not panic (nothing should
> really). But it does, and quite repeatedly (some more comments after
> the trace):
>
> IdlePTD 4984832
> initial pcb at 3db040
> panicstr: bwrite: buffer is not busy???
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; lapic.id = 0100
> fault virtual address = 0x3
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc01d5a0b
> stack pointer = 0x10:0xce7f1c4c
> frame pointer = 0x10:0xce7f1c58
> 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 = 442 (ppp)
> trap number = 12
> panic: page fault
> cpuid = 0; lapic.id = 0100
> boot() called on cpu#0
>
> syncing disks... panic: bwrite: buffer is not busy???
> cpuid = 0; lapic.id = 0100
> boot() called on cpu#0
> Uptime: 10m14s
>
> dumping to dev da0b, offset 131200
> dump ... 2 1 0
> ---
> [...]
> #12 0xc030b0bc in trap (frame={tf_fs = -1071644648, tf_es = -830734320,
> tf_ds = 16777232, tf_edi = 64, tf_esi = 0, tf_ebp = -830530472,
> tf_isp = -830530504, tf_ebx = -1049243648, tf_edx = -1049243428,
> tf_ecx = 34, tf_eax = 0, tf_trapno = 12, tf_err = 0,
> tf_eip = -1071818229, tf_cs = 8, tf_eflags = 66178,
> tf_esp = -830530412, tf_ss = -1049288448})
> at ../../../i386/i386/trap.c:405
> #13 0xc01d5a0b in ugenpoll (dev=0xc1752100, events=64, p=0xce7abb80)
> at ../../../dev/usb/ugen.c:1369
> #14 0xc01ed604 in spec_poll (ap=0xce7f1c94)
> at ../../../fs/specfs/spec_vnops.c:333
> #15 0xc01ed27d in spec_vnoperate (ap=0xce7f1c94)
> at ../../../fs/specfs/spec_vnops.c:119
> #16 0xc0252333 in vn_poll (fp=0xc17328c0, events=64, cred=0xc1734700,
> p=0xce7abb80) at vnode_if.h:381
> #17 0xc0228b8b in selscan (p=0xce7abb80, ibits=0xce7f1d48,
> obits=0xce7f1d3c, nfd=1) at ../../../sys/file.h:192
> #18 0xc02286b5 in select (p=0xce7abb80, uap=0xce7f1f80)
> at ../../../kern/sys_generic.c:772
> #19 0xc030bf2d in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
> tf_edi = 134842880, tf_esi = 134842880, tf_ebp = 0,
> tf_isp = -830529580, tf_ebx = 3, tf_edx = 134996480,
> tf_ecx = 134996352, tf_eax = 93, tf_trapno = 12, tf_err = 2,
> tf_eip = 673178596, tf_cs = 31, tf_eflags = 643,
> tf_esp = -1077937708, tf_ss = 47}) at ../../../i386/i386/trap.c:1129
> (kgdb) up 13
> #13 0xc01d5a0b in ugenpoll (dev=0xc1752100, events=64, p=0xce7abb80)
> at ../../../dev/usb/ugen.c:1369
> 1369switch (sce->edesc->bmAttributes & UE_XFERTYPE) {
> (kgdb) p sce
> $1 = (struct ugen_endpoint *) 0x0
> (kgdb) l
> 1364printf("ugenpoll: no pipe\n");
> 1365return (EIO);
> 1366}
> 1367#endif
> 1368s = splusb();
> 1369switch (sce->edesc->bmAttributes & UE_XFERTYPE) {
> 1370case UE_INTERRUPT:
> 1371if (events & (POLLIN | POLLRDNORM)) {
> 1372if (sce->q.c_cc > 0)
> 1373revents |= events & (POLLIN | POLLRDNORM);
> (kgdb) p events
> $3 = 64
> (kgdb) p s
> No symbol "s" in current context.
> (kgdb) p revents
> $5 = 0
>
> What I don't understand, is -- there is a check, just a few lines
> above:
> if (sce == NULL)
> return (EINVAL);
>
> How come it is not being caught there? Thanks,
>
> --
> |\__-__/|
> _/ : :::\_
>'__--( ..::)--__` -mi
> If you have a / _- \/ :::\/ -_
> serious knowledge/ / :. .\ \
> about computers -- | | Ok, let's say you broke
> keep it in a secret! _|/ ::\|_ the wall with your head
> "Rules of dating", / /:/:_::\::\:.\ What are you going to
> 'Playboy', ? 1994 | :| ..:(_/ \::|::|::| do in the next cell?
> | :|:. ::|: |::|.:| Stanis
Re: old BSD/OS binary coredumps
As Philipp Mergenthaler wrote:
> I saw something like this some time ago, too. In my case it was
> because in kern_sysctl:ogetkerninfo(), in "case KINFO_BSDI_SYSINFO:",
> the variable "size" is not always given a value. Maybe the patch in
> http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25476
> fixes it for you, too?
Yep.
> (Hm, now I think my patch could need a comment: "size" will only be
> returned if needed==0. There are two ways this can happen:
After taking a look at the BSD/OS source code (which we are now
allowed to do), i decided to slightly modify the patch. Here's the
result for review.
Index: kern_sysctl.c
===
RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.112
diff -u -r1.112 kern_sysctl.c
--- kern_sysctl.c 25 Jul 2001 17:21:15 - 1.112
+++ kern_sysctl.c 30 Aug 2001 20:34:57 -
@@ -1237,6 +1237,7 @@
{
int error, name[6];
size_t size;
+ u_int needed = 0;
switch (uap->op & 0xff00) {
@@ -1300,16 +1301,15 @@
* this is pretty crude, but it's just enough for uname()
* from BSDI's 1.x libc to work.
*
-* In particular, it doesn't return the same results when
-* the supplied buffer is too small. BSDI's version apparently
-* will return the amount copied, and set the *size to how
-* much was needed. The emulation framework here isn't capable
-* of that, so we just set both to the amount copied.
-* BSDI's 2.x product apparently fails with ENOMEM in this
-* scenario.
+* *size gives the size of the buffer before the call, and
+* the amount of data copied after a successful call.
+* If successful, the return value is the amount of data
+* available, which can be larger than *size.
+*
+* BSDI's 2.x product apparently fails with ENOMEM if *size
+* is too small.
*/
- u_int needed;
u_int left;
char *s;
@@ -1338,11 +1338,13 @@
error = 0;
break;
}
-
-
- /* if too much buffer supplied, trim it down */
- if (size > needed)
- size = needed;
+ if ((error = copyin(uap->size, &size, sizeof(size))) != 0)
+ break;
+ if (size < needed) {
+ error = ENOMEM;
+ break;
+ }
+ size = needed;
/* how much of the buffer is remaining */
left = size;
@@ -1364,7 +1366,7 @@
}
if (error)
return (error);
- p->p_retval[0] = size;
+ p->p_retval[0] = needed ? needed : size;
if (uap->size)
error = copyout((caddr_t)&size, (caddr_t)uap->size,
sizeof(size));
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: testing KSE
The medium I mount is a hard disk partition. /dev/ad0s1 is my win98 boot drive, /dev/ad0s2* my FreeBSD world. It has worked for almost a year, never had a crash or lost a single byte. I can go back to the kse kernel, and remount Win98, with the instructions You just posted. Ciao, derweil, -- Carlo > I can not reproduce this with a memory disk image of an msdos floppy > (I do not have a floppy on that machine) > > can you try accessing the floppy without mounting? > > e.g. can you try using it as a raw device with TAR or something? > > Maybe it's the floppy driver rather than tehe filesystem. > If you can get a coredump and thus a stack backtrace > it could be very helpful. > > thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
lsof compile broken
Hi, I'm getting the following when trying to build lsof: >> Checksum OK for lsof_4.58A.freebsd.tar.gz. grep: README.lsof_4.58A.freebsd: No such file or directory md5: lsof_4.58A.freebsd.tar: No such file or directory lsof_4.58A.freebsd.tar.gz: No such file or directory This configuration step (the Inventory script) takes inventory of the lsof distribution. The script runs for a minute or two while it checks that all the subdirectories, information files, scripts, header files and source files that should be present really are. It's not absolutely necessary that you take inventory, but it's a good idea to do it right after the lsof distribution has been unpacked. Once the inventory has been taken, this script creates the file ./.ck00MAN as a signal that the inventory step has been done. You can call the Inventory script directly at any time to take inventory. You can inhibit the inventory step permanently by creating the file ./.neverInv, and you can tell the Configure script to skip the inventory and customization steps with the -n option. Do you want to take inventory (y|n) [y]? Conducting an inventory of the lsof distribution; this will take a while. Examining /usr/ports/sysutils/lsof/work/lsof_4.58A.freebsd: OK Examining dialects: OK Examining dialects/freebsd: OK Examining dialects/freebsd/include: OK Examining dialects/freebsd/include/procfs: OK Examining lib: OK Examining scripts: OK This lsof distribution seems to be complete. ===> Patching for lsof-4.57.1 ===> Applying FreeBSD patches for lsof-4.57.1 ===> Configuring for lsof-4.57.1 rm -f ddev.c dfile.c dlsof.h dmnt.c dnode*.c dproc.c dproto.h dsock.c dstore.c kernelbase.h machine.h machine.h.old new_machine.h __lseek.s Makefile ln -s dialects/freebsd/dlsof.h dlsof.h ln -s dialects/freebsd/dmnt.c dmnt.c ln -s dialects/freebsd/dnode.c dnode.c ln -s dialects/freebsd/dnode1.c dnode1.c ln -s dialects/freebsd/dproc.c dproc.c ln -s dialects/freebsd/dproto.h dproto.h ln -s dialects/freebsd/dsock.c dsock.c ln -s dialects/freebsd/dstore.c dstore.c ln -s dialects/freebsd/machine.h machine.h Makefile and lib/Makefile created. ===> Building for lsof-4.57.1 (cd lib; make DEBUG="-O" CFGF="-DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR=\"5.0-CURRENT\"") cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c ckkv.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c cvfs.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c dvch.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c fino.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c isfn.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c lkud.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c pdvn.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c prfp.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c ptti.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c rdev.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c regex.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c rmnt.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c rnam.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c rnch.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c rnmh.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR="5.0-CURRENT" -I/usr/include -I/usr/src/sys -O -c snpf.c ar cr liblsof.a ckkv.o cvfs.o dvch.o fino.o isfn.o lkud.o pdvn.o prfp.o ptti.o rdev.o regex.o rmnt.o rnam.o rnch.o rnmh.o snpf.o ranlib liblsof.a cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR=\"5.0-CURRENT\" -I/usr/include -I/usr/src/sys -O -c dmnt.c cc -DFREEBSDV=500 -DHASFDESCFS=2 -DHASPROCFS -DHAS9660FS -DHASIPv6 -DLSOF_VSTR=\"5.0-CURRENT\" -I/usr/include -I/usr/src/sys -O -c dnode.c dnode.c: In function `process_node': dnode.c:198: storage size of `pb' isn't
Re: testing KSE
The easiest way is to have a serial console. that is VERY easy to do. simply add the line console="comconsole" to the file /boot/loader.conf After that you can also work on getting core-dumps (man dumpon) and use gdb to get backtraces etc. Some machines don't clear all of ram so "dmesg" can sometimesm show panic messages from the last session too. On Thu, 30 Aug 2001, Jim Bryant wrote: > I'm in the process of getting set up for testing KSE too, but I was wondering, how >are you capturing the panic dump? Do you run a > serial console or something to do it? > > Carlo Dapor wrote: > > >>can you try the same with a "matching" -current? > >>I heard that msdosfs is bombing there too. > >>(just to confirm this.. if it works there but not with KSE > >>then we have work to do :-) > >> > > > > I build and run a kernel just before applying the patches, that was able to > > mount the partition and 'accepted' reads/writes/deletes/create directories etc. > > for a good three to four hours. > > > > As I stated earlier, the kse-patched kernel produced this: > > > > > >>Fatal trap 12: page fault while in kernel mode > >>fault virtual address = 0x4 > >>fault code = supervisor read, page not present > >>instruction pointer = 0x8:0xc11fa49a > >>stack pointer = 0x10:0xca36aa70 > >>frame pointer = 0x10:0xca36ae20 > >>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 = 24854 (mount_msdosfs) > >>trap number = 12 > >>panic: page fault > >>syncing disks... panic: bdwrite: buffer is not busy > >>Uptime: 15h12m23s > >>Automatic reboot in 15 seconds - press a key on the console to abort > >>--> Press a key on the console to reboot <-- > >> > > > > Right now, I am applying src-cur.4939.gz, after having reversed the KSE > > patches. I am building a brand new kernel next. > > > > I'll post more on this in very soon. > > > > Ciao, derweil, > > -- > > Carlo > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > -- > ET has one helluva sense of humor! > He's always anal-probing right-wing schizos! > >POWER TO THE PEOPLE! > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: testing KSE
I can not reproduce this with a memory disk image of an msdos floppy (I do not have a floppy on that machine) can you try accessing the floppy without mounting? e.g. can you try using it as a raw device with TAR or something? Maybe it's the floppy driver rather than tehe filesystem. If you can get a coredump and thus a stack backtrace it could be very helpful. thanks On Thu, 30 Aug 2001, Carlo Dapor wrote: > > can you try the same with a "matching" -current? > > I heard that msdosfs is bombing there too. > > (just to confirm this.. if it works there but not with KSE > > then we have work to do :-) > > I build and run a kernel just before applying the patches, that was able to > mount the partition and 'accepted' reads/writes/deletes/create directories etc. > for a good three to four hours. > > As I stated earlier, the kse-patched kernel produced this: > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x4 > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xc11fa49a > > stack pointer = 0x10:0xca36aa70 > > frame pointer = 0x10:0xca36ae20 > > 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 = 24854 (mount_msdosfs) > > trap number = 12 > > panic: page fault > > syncing disks... panic: bdwrite: buffer is not busy > > Uptime: 15h12m23s > > Automatic reboot in 15 seconds - press a key on the console to abort > > --> Press a key on the console to reboot <-- > > Right now, I am applying src-cur.4939.gz, after having reversed the KSE > patches. I am building a brand new kernel next. > > I'll post more on this in very soon. > > Ciao, derweil, > -- > Carlo > > 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
Non-KSE kernel mounts msdosfs
Houston, we have a . . . I confirm that with the 'normal' current module sources mount_msdosfs collabo- rates with me, successfully. I did not set anything up. I simply get mails to root, like the one pasted earlier on. In fact, I didn't even think that crash was reported via mail to root . . . > I'm in the process of getting set up for testing KSE too, but I was wondering, how >are you capturing the panic dump? Do you run a > serial console or something to do it? Ciao, derweil, -- Carlo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
heads-up - syscalls.master changes, MPSAFE comments, */*/trap.c:syscall()
(repost, it didn't like me cross-posting to the -alpha and -ia64 lists. sigh). I'm going to be comitting the following changes soon: syscalls.master: (going in now) Instead of having an MPSAFE keyword, existing keywords such as STD can be augmented with an [M] prefix, e.g. MSTD instead of STD, to indicate that a system call is MP safe. This change is being made because over the next few days I will be pushing down Giant for all system calls in the entire system, and keeping MPSAFE will turn the various syscalls.master files into a mess. Eventually, months from now, the original keywords 'STD', 'COMPAT' and so forth... will no longer exist and will be deprecated. MPSAFE comments (going in now) All procedures which are MP safe will have the following comment: /* * (other comments) * MPSAFE */ procedure definition I will be adding the MPSAFE comment to system calls as I push Giant down. Do not remove these comments, and add them when appropriate. The comment simply means that the procedure may be called without Giant held (even if the procedure itself obtains Giant). Keep in mind that we cannot arbitrarily remove Giant from higher level routines just because the calls they make are all marked MPSAFE. There are atomicy issues that must still be addressed, such as file descriptor races and such. These comments are not carte-blanc to go on a Giant-removal binge. */*/trap.c:syscall[2]() function changes: (going in now) sv_prepsyscall() is now assumed to be MP SAFE, and it just happens to be that the one user of this vector (the linux emu code) IS MP safe and doesn't even need to obtain Giant. sv_transtrap() is now assumed to be MP SAFE, and it just happens to be that the one user of this vector (the linux emu code) IS MP safe and doesn't even need to obtain Giant. ktrsyscall() and ktrsysret() are now marked MP SAFE (I just pushed Giant down into them). The syscall[2]() code no longer obtains Giant in order to make these calls. trapsignal() is now marked MP SAFE (I just pushed Giant down into it), so syscall[2]() does not have to obtain Giant when making trapsignal() calls. I have removed calls to if (mtx_owned(&Giant) mtx_unlock(&Giant) ... instead syscall[2]() explicitly unlocks Giant if it previously obtained it, and then asserts that Giant is no longer owned. This is to catch broken system calls. The previous code hid broken system calls by silently unlocking a Giant that system call might have left locked. Giant Pushdown work: (ongoing work over the next week) Over the next few days, Giant will be pushed down for *ALL* (or nearly all) system calls. This will effect about a hundred source files. I will be doing this work piecemeal, adjusting the syscalls.master files and associated routines in chunks starting with the FreeBSD core system calls. Some of the system calls may wind up looking fairly weird, for example the system calls that already partially implement jhb's PROC lock code. John will be fixing those up in the coming days as he continues to work on the PROC lock. His work will allow several dozen signal and proc-related (e.g. setuid()) system calls to run without Giant. The pushdown work is going to bloat the codebase a bit, but it is a necessary step. I can't believe that NOBODY other then Alfred has done any work on the Giant syscall pushdown since I first introduced the MPSAFE syscalls.master keyword months ago! So don't complain now if you see a lot of commits from me! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
>Date: Wed, 29 Aug 2001 19:58:59 -0700 >From: Mike Smith <[EMAIL PROTECTED]> >The loader now detects ACPI in your system, and loads the ACPI >module if it is present. This has major ramifications for the >device probe and attach phases of system initialisation. Flushed with the success of getting today's -CURRENT running on my build system: freebeast[8] uname -a FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #16: Thu Aug 30 09:12:22 PDT 2001 [EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/FREEBEAST i386 I proceeded to do likewise with my laptop. However, that machine needed a little more assistance, so I'm sending this note out to provide a clue for others who might be similarly situated. The mainstream laptop to which mine is most similar is a Dell i5000e; it's actually made by Compal (who makes them for several vendors); details on the machine may be found at http://www.catwhisker.org/~david/FreeBSD/laptop.html. The symptom is that during boot, after the acpi.ko module is loaded, the boot process hangs, with the last several lines (in verbose mode) displayed being: pci_open(1):mode 1 addr port (0x0cf8) is 0x80003904 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) Using $PIR table, 7 entries at 0xc00fdf50 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard A brute-force circumvention is to do an "unset acpi_load" before you get to that point, but that rather defeats the purpose. (It's still useful to know about it, though.) A slightly less brute-force approach (from a note that John Baldwin sent out to -mobile back on 22 Feb 2001) is to place the line debug.acpi.avoid="_SB_.PCI0.PX40.SIO_" in /boot/loader.conf -- and that done: m147[4] uname -a FreeBSD m147.whistle.com 5.0-CURRENT FreeBSD 5.0-CURRENT #107: Thu Aug 30 11:16:02 PDT 2001 [EMAIL PROTECTED]:/common/C/obj/usr/src/sys/LAPTOP_30W i386 (Now to research ways of achieving the functionality I had with APM) Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: testing KSE
I'm in the process of getting set up for testing KSE too, but I was wondering, how are you capturing the panic dump? Do you run a serial console or something to do it? Carlo Dapor wrote: >>can you try the same with a "matching" -current? >>I heard that msdosfs is bombing there too. >>(just to confirm this.. if it works there but not with KSE >>then we have work to do :-) >> > > I build and run a kernel just before applying the patches, that was able to > mount the partition and 'accepted' reads/writes/deletes/create directories etc. > for a good three to four hours. > > As I stated earlier, the kse-patched kernel produced this: > > >>Fatal trap 12: page fault while in kernel mode >>fault virtual address = 0x4 >>fault code= supervisor read, page not present >>instruction pointer = 0x8:0xc11fa49a >>stack pointer = 0x10:0xca36aa70 >>frame pointer = 0x10:0xca36ae20 >>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 = 24854 (mount_msdosfs) >>trap number = 12 >>panic: page fault >>syncing disks... panic: bdwrite: buffer is not busy >>Uptime: 15h12m23s >>Automatic reboot in 15 seconds - press a key on the console to abort >>--> Press a key on the console to reboot <-- >> > > Right now, I am applying src-cur.4939.gz, after having reversed the KSE > patches. I am building a brand new kernel next. > > I'll post more on this in very soon. > > Ciao, derweil, > -- > Carlo > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
> On 30-Aug-2001 Alexander N. Kabaev wrote: > | Freshly cvsuped kernel fails to build trying to find acpi_isa.c file, which > | does not exist anymore. > > The following patch I sent to Mike allows the kernel to build. The files omission has been fixed; the 'acpica' module has moved to become the 'acpi' module. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI & Toshiba Tecra 8000
> Hi, > a few things to note: > - Loading the new kernel & acpi.ko with the old loader freezes the loader. > - Loading acpi.ko by hand with the new loader freezes or endless-loops the lo > ader. I've no idea what's going on here; I used a Tecra 8000 for much of my testing, and never saw this. 8( > - Letting the new loader using the acpi.ko brings the system up and running e > xcept my sound-system > (missing equivalent to isa_probe_children: probing PnP devices?) I haven't added ACPI attachments to the sound drivers yet; I want Cameron to check these over, as many of them do questionable things with the PnP interface that aren't applicable to ACPI. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
On 30-Aug-2001 Alexander N. Kabaev wrote: | Freshly cvsuped kernel fails to build trying to find acpi_isa.c file, which | does not exist anymore. The following patch I sent to Mike allows the kernel to build. Index: modules/acpica/Makefile === RCS file: /home/ncvs/src/sys/modules/acpica/Makefile,v retrieving revision 1.11 diff -u -r1.11 Makefile --- modules/acpica/Makefile 2001/07/20 06:07:34 1.11 +++ modules/acpica/Makefile 2001/08/30 16:46:46 @@ -28,7 +28,7 @@ # OSD layer SRCS+= acpi.c acpi_acad.c acpi_battery.c acpi_button.c acpi_cmbat.c acpi_cpu.c -SRCS+= acpi_ec.c acpi_isa.c acpi_lid.c acpi_pcib.c acpi_powerprofile.c +SRCS+= acpi_ec.c acpi_lid.c acpi_pcib.c acpi_powerprofile.c SRCS+= acpi_powerres.c acpi_resource.c acpi_thermal.c acpi_timer.c SRCS+= acpi_wakecode.h acpi_wakeup.c SRCS+= OsdDebug.c Index: conf/files === RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.559 diff -u -r1.559 files --- conf/files 2001/08/23 23:58:49 1.559 +++ conf/files 2001/08/30 16:46:53 @@ -201,7 +201,6 @@ dev/acpica/acpi_cmbat.coptional acpica dev/acpica/acpi_cpu.c optional acpica dev/acpica/acpi_ec.c optional acpica -dev/acpica/acpi_isa.c optional acpica isa dev/acpica/acpi_lid.c optional acpica dev/acpica/acpi_pcib.c optional acpica pci dev/acpica/acpi_powerres.c optional acpica Mike -- Mike Heffner Blacksburg, VA <[EMAIL PROTECTED]> PGP signature
Re: testing KSE
thanks.. I will try duplicate this tomorrow (today is shaping up to be a bad day) On Thu, 30 Aug 2001, Carlo Dapor wrote: > > can you try the same with a "matching" -current? > > I heard that msdosfs is bombing there too. > > (just to confirm this.. if it works there but not with KSE > > then we have work to do :-) > > I build and run a kernel just before applying the patches, that was able to > mount the partition and 'accepted' reads/writes/deletes/create directories etc. > for a good three to four hours. > > As I stated earlier, the kse-patched kernel produced this: > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x4 > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xc11fa49a > > stack pointer = 0x10:0xca36aa70 > > frame pointer = 0x10:0xca36ae20 > > 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 = 24854 (mount_msdosfs) > > trap number = 12 > > panic: page fault > > syncing disks... panic: bdwrite: buffer is not busy > > Uptime: 15h12m23s > > Automatic reboot in 15 seconds - press a key on the console to abort > > --> Press a key on the console to reboot <-- > > Right now, I am applying src-cur.4939.gz, after having reversed the KSE > patches. I am building a brand new kernel next. > > I'll post more on this in very soon. > > Ciao, derweil, > -- > Carlo > > 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
find(1) -flags
[Bcc'ed to -current] Hi! The current implementation of find(1) -flags primitive is a bit icky and does not match the (poorly) documented behavior. For example, the fact that only a certain set of file flags is recognized is not documented, and there is no reason for this behavior. Also, "no" flags don't take the desired effect to match files that have corresponding flag bits unset. The attached patch extends -flags functionality as follows: : -flags [-|+], :The flags are specified using symbolic names (see chflags(1)). :Those with the "no" prefix (except "nodump") are said to be :. Flags in are checked to be set, and flags in : are checked to be not set. Note that this is different :from -perm, which only allows you to specify mode bits that are set. : :If flags are preceded by a dash (``-''), this primary evaluates :to true if at least all of the bits in and none of the bits :in are set in the file's flags bits. If flags are pre- :ceded by a plus (``+''), this primary evaluates to true if any of :the bits in is set in the file's flags bits, or any of the :bits in is not set in the file's flags bits. Otherwise, :this primary evaluates to true if the bits in exactly match :the file's flags bits, and none of the flags bits match those of :. Please review. Cheers, -- Ruslan Ermilov Oracle Developer/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 Index: find.1 === RCS file: /home/ncvs/src/usr.bin/find/find.1,v retrieving revision 1.36 diff -u -p -r1.36 find.1 --- find.1 2001/06/29 12:59:20 1.36 +++ find.1 2001/08/30 16:27:29 @@ -428,45 +428,90 @@ matched explicitly. Like .Ic -path , but the match is case insensitive. -.It Ic -perm Oo Fl Oc Ns Ar mode +.It Ic -perm Oo Cm - Ns | Ns Cm + Oc Ns Ar mode The .Ar mode may be either symbolic (see .Xr chmod 1 ) or an octal number. -If the mode is symbolic, a starting value of zero is assumed and the -mode sets or clears permissions without regard to the process' file mode +If the +.Ar mode +is symbolic, a starting value of zero is assumed and the +.Ar mode +sets or clears permissions without regard to the process' file mode creation mask. -If the mode is octal, only bits 0 +If the +.Ar mode +is octal, only bits 0 .Pq Dv S_ISUID | S_ISGID | S_ISTXT | S_IRWXU | S_IRWXG | S_IRWXO of the file's mode bits participate in the comparison. -If the mode is preceded by a dash +If the +.Ar mode +is preceded by a dash .Pq Dq Li - , this primary evaluates to true -if at least all of the bits in the mode are set in the file's mode bits. -If the mode is preceded by a plus +if at least all of the bits in the +.Ar mode +are set in the file's mode bits. +If the +.Ar mode +is preceded by a plus .Pq Dq Li + , this primary evaluates to true -if any of the bits in the mode are set in the file's mode bits. +if any of the bits in the +.Ar mode +are set in the file's mode bits. Otherwise, this primary evaluates to true if -the bits in the mode exactly match the file's mode bits. +the bits in the +.Ar mode +exactly match the file's mode bits. Note, the first character of a symbolic mode may not be a dash .Pq Dq Li - . -.It Ic -flags Op Fl Ns Ar flags -This primary evaluates to true if exactly those flags of the file are -set which are also set using the specified -.Ar flags -(if these are not preceded by a dash -.Pq Dq Li - , -or if they match the specified flags (if these are preceded by a dash). -The -.Ar flags -are specified using symbolic names (see +.It Ic -flags Oo Cm - Ns | Ns Cm + Oc Ns Ar flags , Ns Ar notflags +The flags are specified using symbolic names (see .Xr chflags 1 ) . +Those with the +.Qq Li no +prefix (except +.Qq Li nodump ) +are said to be +.Ar notflags . +Flags in +.Ar flags +are checked to be set, and flags in +.Ar notflags +are checked to be not set. Note that this is different from .Ic -perm , -which only allows you to specify flags which are set. +which only allows you to specify mode bits that are set. +.Pp +If flags are preceded by a dash +.Pq Dq Li - , +this primary evaluates to true +if at least all of the bits in +.Ar flags +and none of the bits in +.Ar notflags +are set in the file's flags bits. +If flags are preceded by a plus +.Pq Dq Li + , +this primary evaluates to true +if any of the bits in +.Ar flags +is set in the file's flags bits, +or any of the bits in +.Ar notflags +is not set in the file's flags bits. +Otherwise, +this primary evaluates to true +if the bits in +.Ar flags +exactly match the file's flags bits, +and none of the +.Ar flags +bits match those of +.Ar notflags . .It Ic -print This primary always evaluates to true. It prints the pathname of the current fil
Re: aac module broken
> On Thu, 30 Aug 2001 08:12:42 -0500, Michael Harnois <[EMAIL PROTECTED]> said: > >> /usr/src/sys/modules/aac/../../dev/aac/aac.c: At top level: >> /usr/src/sys/modules/aac/../../dev/aac/aac.c:1976: warning: >> `aac_describe_code' was used with no prototype before its >> definition /usr/src/sys/modules/aac/../../dev/aac/aac.c:1976: >> conflicting types for `aac_describe_code' >> /usr/src/sys/modules/aac/../../dev/aac/aac.c:156: previous >> declaration of `aac_describe_code' > > Should have looked before I leapt, the actual fatal error is here: > > /usr/src/sys/modules/aac/../../dev/aac/aac.c:156: syntax error before `u_int32_t > ' There obviously must be comma at the end of the line 155 of the 'sys/dev/aac/aac.c' file. N.Dudorov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
Freshly cvsuped kernel fails to build trying to find acpi_isa.c file, which does not exist anymore. On 30-Aug-2001 Mike Smith wrote: > > I have just committed some changes to the way that ACPI works in > current. This has an impact on all -current users, so please > take a few seconds to read this and feel free to ask questions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: testing KSE
> can you try the same with a "matching" -current? > I heard that msdosfs is bombing there too. > (just to confirm this.. if it works there but not with KSE > then we have work to do :-) I build and run a kernel just before applying the patches, that was able to mount the partition and 'accepted' reads/writes/deletes/create directories etc. for a good three to four hours. As I stated earlier, the kse-patched kernel produced this: > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x4 > fault code= supervisor read, page not present > instruction pointer = 0x8:0xc11fa49a > stack pointer = 0x10:0xca36aa70 > frame pointer = 0x10:0xca36ae20 > 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 = 24854 (mount_msdosfs) > trap number = 12 > panic: page fault > syncing disks... panic: bdwrite: buffer is not busy > Uptime: 15h12m23s > Automatic reboot in 15 seconds - press a key on the console to abort > --> Press a key on the console to reboot <-- Right now, I am applying src-cur.4939.gz, after having reversed the KSE patches. I am building a brand new kernel next. I'll post more on this in very soon. Ciao, derweil, -- Carlo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: old BSD/OS binary coredumps
As Philipp Mergenthaler wrote: > I saw something like this some time ago, too. In my case it was > because in kern_sysctl:ogetkerninfo(), in "case KINFO_BSDI_SYSINFO:", > the variable "size" is not always given a value. Maybe the patch in > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25476 > fixes it for you, too? I'll have a look at that. As Peter Wemm wrote: > That is certainly odd. Can you put a .tar.gz of whatever is needed to > replicate it somewhere? eg: on http://freefall/~joerg/ ? http://people.freebsd.org/~joerg/netscape.bz That's just the binary itself, i verified in a chroot environment that's all you need to reproduce it (here at least). Ignore all the warnings about missing keysyms etc., the don't influence the coredump behaviour. > What is the last -current kernel build date that it ran under? My old kernel was from 2001-06-07. > Have you removed COMPAT_43 by any chance? No. (I think the kernel cannot even be linked when omitting this, i once tried it.) The only change to the config file was to remove the userconfig stuff now. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aac module broken
On Thu, 30 Aug 2001 08:12:42 -0500, Michael Harnois <[EMAIL PROTECTED]> said: > /usr/src/sys/modules/aac/../../dev/aac/aac.c: At top level: > /usr/src/sys/modules/aac/../../dev/aac/aac.c:1976: warning: > `aac_describe_code' was used with no prototype before its > definition /usr/src/sys/modules/aac/../../dev/aac/aac.c:1976: > conflicting types for `aac_describe_code' > /usr/src/sys/modules/aac/../../dev/aac/aac.c:156: previous > declaration of `aac_describe_code' Should have looked before I leapt, the actual fatal error is here: /usr/src/sys/modules/aac/../../dev/aac/aac.c:156: syntax error before `u_int32_t ' -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota "Every revolution evaporates and leaves behind only the slime of a new bureaucracy." -- Franz Kafka To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
aac module broken
/usr/src/sys/modules/aac/../../dev/aac/aac.c: At top level: /usr/src/sys/modules/aac/../../dev/aac/aac.c:1976: warning: `aac_describe_code' was used with no prototype before its definition /usr/src/sys/modules/aac/../../dev/aac/aac.c:1976: conflicting types for `aac_describe_code' /usr/src/sys/modules/aac/../../dev/aac/aac.c:156: previous declaration of `aac_describe_code' -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota "Every revolution evaporates and leaves behind only the slime of a new bureaucracy." -- Franz Kafka To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI & Toshiba Tecra 8000
Hi, a few things to note: - Loading the new kernel & acpi.ko with the old loader freezes the loader. - Loading acpi.ko by hand with the new loader freezes or endless-loops the loader. - Letting the new loader using the acpi.ko brings the system up and running except my sound-system (missing equivalent to isa_probe_children: probing PnP devices?) Dmesg's with & without acpi: ### with new ACPI ### Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Thu Aug 30 16:25:32 CEST 2001 root@nihil:/usr/src/sys/i386/compile/nihil Calibrating clock(s) ... TSC clock: 266605716 Hz, i8254 clock: 1193143 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 266616245 Hz CPU: Pentium II/Pentium II Xeon/Celeron (266.62-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ff real memory = 268369920 (262080K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x003b4000 - 0x0ffe7fff, 264454144 bytes (64564 pages) avail memory = 257630208 (251592K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fc470 bios32: Entry = 0xfc480 (c00fc480) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0x827 pnpbios: Found PnP BIOS data at 0xc00fed00 pnpbios: Entry = f:92e4 Rev = 1.0 pnpbios: Event flag at 510 pnpbios: OEM ID 7933f351 Other BIOS signatures found: Preloaded elf kernel "kernel" at 0xc038e000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc038e0a8. Preloaded elf module "md.ko" at 0xc038e0f8. Preloaded elf module "if_dc.ko" at 0xc038e194. Preloaded elf module "miibus.ko" at 0xc038e234. Preloaded elf module "snd_mss.ko" at 0xc038e2d4. Preloaded elf module "snd_pcm.ko" at 0xc038e374. Preloaded elf module "usb.ko" at 0xc038e414. Preloaded elf module "ums.ko" at 0xc038e4b0. Preloaded elf module "if_ep.ko" at 0xc038e54c. Preloaded elf module "acpi.ko" at 0xc038e5ec. mem: Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 02 20 01 00 01 00 00 00 00 22 00 00 01 27 00 13 00 00 01 00 01 09 01 00 01 1b 01 00 01 00 01 01 01 02 01 03 01 04 01 05 01 07 01 08 01 0d 01 0e 01 10 01 11 01 12 01 13 01 14 01 VESA: 25 mode(s) found VESA: v2.0, 2496k memory, flags:0x0, mode table:0xc02834c2 (122) VESA: MagicGraph 256 AV 44K PRELIMINARY VESA: NeoMagic MagicMedia 256 AV 01.0 random: null: pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71928086) Using $PIR table, 6 entries at 0xc00f01e0 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfe08-0xfe0b on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 pci0: physical bus=0 map[10]: type 3, range 32, base e000, size 28, enabled found-> vendor=0x8086, dev=0x7192, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 map[10]: type 3, range 32, base df00, size 24, enabled map[14]: type 1, range 32, base ff80, size 22, enabled map[18]: type 1, range 32, base ff70, size 20, enabled found-> vendor=0x10c8, dev=0x0005, revid=0x12 bus=0, slot=4, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 found-> vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=5, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 map[20]: type 4, range 32, base fe60, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=5, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 map[20]: type 4, range 32, base ffe0, size 5, enabled found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=5, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 intpin=d, irq=11 map[90]: type 4, range 32, base fe70, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x02 bus=0, slot=5, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 map[10]: type 4, range 32, base ff80, size 5, enabled found-> vendor=0x1179, dev=0x0701, revid=0x23 bus=0, slot=9, func=0 class=07-80-00, hdrtype=0x00, mfdev=0 intpin=a, irq=11 found-> vendor=0x1179, dev=0x060f, revid=0x05 bus=0, slot=11, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 intpin=a, irq=255 found-> vendor=0x1179, dev=0x060f, revid=0x05 bus=0, slot=11, func=1 class=06-07-00, hdrtype=0x02, mfdev=1
Re: unknown PNP hardware
Ok, this is the 3rd revised patch for PnP. I think it works
fairely well.
I may not invest further time on this, now that ACPI is
taking over device configuration business... :-)
Kazu
>> I once wrote the following patch to deal with this problem by
>> probing ISA devices in the following order.
>>
>> 1. sensitive ISA devices described in device.hints
>> 2. PnP BIOS ISA devices
>> 3. other ISA devices described in device.hints
>> 4. PnP ISA devices
>
>This order is still slightly wrong. You need to do:
>
> 0. Disable ALL PnP devices which can be disabled.
> 1. PnP devices (of any kind) which cannot be disabled, or which only
>have a single configuration. These devices which cannot be disabled
>need a placeholder attached to them if a driver doesn't claim them,
>or some other mechanism so that their resources are never used.
> 2. Sensitive hinted ISA devices.
> 3. Other ISA devices.
> 4. Other PnP devices.
begin 666 isapnp.diff3.gz
M'XL("*O(C3L VES87!N<"YD:69F,P"]66USVD@2_HQ_1:]3ZQ)&&(D7@[&3
M#0&R2RTQ/D-B7/P^O]_'5SWI[!P5ZP+M3!P:OV;*?\,'\-:
M?C[]X2!@4>"R!]>[@P _0M?WP#RI-P[F[F(!U2U4 _H*&3>KU>J.[Z6Z89@U
MHU,S#3#:W9;1-9LE;JE2J>R7;J!TL]MJ= WCX.U;J#;;=1TM5)KM4[UU"F_?
M'D!I$3"F.8L['3Y8L^&'J_+Y >!P[?B@6H)CN&2?(M@$_BT#>[4"S_>J&V\#
M\8T) X[O+=R[;6!'N*#Z7A]VIP?4
MKN&[NP#MUO>C!Q;<^B$KH]G2)G"]:*$=TD+R>"UGZ:[F ?.Z/'[:Q"OO*O99
MV]AA"&;Y']XA+EFEM$!?-1=>@W$.+ER I]3Q:Z52AO_0)$+9BH _1&$E]*?[
M3S)2"J-@ZT0\(80L'+OX#TH.AC>SR6C:T[@*34GRM6,([]U-?E].3DXH4A2@
M4'^:]4;COUGO1]?3F79$]JIOW+DEEC$L\_!+^"URO2V+#=,[+O:4S$=+-Y2V
M 2VZ$6U69J=L;RZV:NT'3*KBKGBT:]D-.Q%/$^^TG$>6'44!' $&VW__:V\V
MN[8N)P/\]FX\+,/1$=?'UTL4I[/>;-1/:SV]%O#3ZZS@N%ZA3 JUZ>HQ-PC'P0IW/9DY5C[?JV,Q+PH>25,YP#V0
M22>2&O>)ELEVEM()C!@,X;U*SY!%E'U82J%T54<195)D!NUOG]>:[3W"UD-P
M\!T[PDQ(JB[RX9ZQ#?A8CH%24O6S"/PU;$,J*WR\/I'/>5J4IN/1=&:]GUP/
M>_W?-(Q'AV"EP\KU[M6BB=S!1]4W.&,\6L(JAL"EVA+/W/FY?))=*^ZP1E;1
M(UT4HBXE10)P_>AQP[+#[EMAIL PROTECTED]+H\%_\,^4JT? 7_L'?Z>T+7SN^@2^S%W2$SE26PU
M8/ 7M^CX 2;(QO?F6:37!4_/
M\]!1! AYI2*WOR0P^ (00I#>LZ
M:2),G"),M%(P\2P;R>-$BN9())#53X6+%&-._,/U^!-.](#'GV# UQ&,SY\5
M _@*?I$H/<,O7G\O?O$*(S-RU460$D;8A5-E-9AB<+.KZ^%T>#G;L2*W1.J[
M(5((SN<4*.W,RA ?%UC6\")V ]_ ;O;I9-@-[QXO:1_?EP$!]PZ!!KZ% 5%9
MM)L=_10JG7J;FJBHBF-4V*XB7)!4'JPWR);G?#EN V;?BTIP;&QPF'_6Z*9W
M;?4GE^]'/!&[Y'ZAG3AQ^7)(4Y4=4X/^9>_#,&=&VR+P;*+ BLHY8,X: URW
MA8TZ77(73[W;P(/AY00S3L SC_RLSB-OGR61[\2+DS[8*U[W+X^[L$QC0R^,
M.A<@18_F0L)#.X#C^
M*MU?DNTO8':RT+$L*-RSMDG[;!H8KZ"'O&]Y&^&0%C<:SKNS;0?)5M)E2 4S
M @_ (2X'S?$5+:A22N^>2EDB0,2YU/^N"%+LAHKK 3'.1Y)?+DAF'F!'!M@Q
M=%,18-'ULY1SY=^YCKVBK*:2#'&0(N+B^/K\>;?>LY(IMAJPQ8HYD6I]1.5B
M/BKS-=4$:"2#@A1T5B1%/=/=A$<0XR[.8O'$U\BBSM=.AT-UZC_4$<*IITE=
M?CQ"$B=23!W)Y*12*>-6LKQ_'TW.U9E)-9D7>K-8V7>A="4%Y8+PY/.<"\<<
MMGP>5Z-:]3D+'5E]F?((G83YIB2% 1D&3CR\=VYNZQ#1DG
M"ZX>EW29:-2,5JU^"D:]:S2[]7:)[!3
MZM9V[F&Q]1RZ>A)Z#[X[+V7D[>#NO)16P('M&OF&/(=[$25)MIN6[TF7$[ 3P0J
MNS8I%1^=^=)\X7"HYHXQ%37*)4TKN)LLIQ'%?;"#D N7[]99(?1/;8 7?
M5>JS5<@(-?Q@SHBG$!N97 ^&N,57P_[',6[SS5!T?'46>_=Q:O4& ZO_VV@\
MP.,='LL0^;@!'1(P%'WO)3ITT1#KB 8H]3B QHV/-TK<<(Z!3M)6Q*R2(V :
M!I% 6\#,VWKR2S8),#M^& [RN?;_ &-D?X Q('8OE0%\0*"?:=;P"&MTNF:C
MVVB4N(54 L22*>BKF]VZ^-'%K#>(_M&') LQ_;P97@XFUZ.!GAZ<#J]'O7%F
M:#SY==3OC4FP6DJQX ]7F"L#W**=,3T[J.AR9EB07U7UDKV9K28G-ZU3259)
MO-?O#Z?3R;46LL"U5SI('_'4'95S(C'IT2%QNTA041X=8J>%6"4G1N!&\$J"
M<2!%HB)!=1"!Z9#A[Q0C^T0]A%2#M1W>6P+,W.!?UH;Q>S^->@-EM93DK6+W
MVB7#8Q.^F<6\9AVD@SS=1J]\PM85LSM+ LT
M[*3./<,3NC@,MCJ\L5=:G49\S2F.I,7]-VGVZ+OJPU53=&'9:-4!E-_HPV9>
M?4,QS#,R,C?YZ;(PM?@Q;]\6)3V.$$+S_?HRKZ^JZB
M&']:-_9S5ST;PEX+B@GL&E!/GM;?^$&TJTNC3^OALGS#6HETY8JX*4H]261=
M7?!#*HQT'7+3\HX#,O?O=^JF01RB@)O)W4*@L
*_C]V:P\F!R4 (X#
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
On Wed, 29 Aug 2001, Robert Watson wrote: > On Wed, 29 Aug 2001, Garrett Wollman wrote: > > FSVO ``useful''. It's a real PITA to have to physically unplug the > > machine when the kernel is wedged rather than have the power button > > turn off the power. (The machine in question does not have a reset > > switch.) As a sometime developer, I may well have a reason to power > > the system off without performing any kind of shutdown. > > Most systems with soft power will perform a hard powerdown if you hold > down the power button for a sufficiently long period of time (10 - 20 > seconds). Yes, it's a real PITA to have to hold down the power button for that long :) (it's normally more like 5 seconds though). I have a system that often doesn't come up after a hard reset or crash (at least video doesn't work), and have to hold its power button down for too long. I've found acpica as useful as any other disk filling service and hope it stays that way. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
> | Most systems with soft power will perform a hard powerdown if you hold > | down the power button for a sufficiently long period of time (10 - 20 > | seconds). > > Correct ... and unfortunately it's done in hardware so you can trap it :-( > In some applications you want to make it really hard for someone to be > able to turn it off when a "power off" is not equivalent to "pull the > plug" and the "pull the plug" is safer for the system due to power supply > design. ... so rewire the power switch to the sleep button input, and set the sleep button action to S5. Then hitting the "power" button will shut down, but holding it down forever won't force power off... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
> > > - I pushed the power button, and my system shut down cleanly! > > > > > Yes. ACPI brings some useful new features. 8) > > > > FSVO ``useful''. It's a real PITA to have to physically unplug the > > machine when the kernel is wedged rather than have the power button > > turn off the power. (The machine in question does not have a reset > > switch.) As a sometime developer, I may well have a reason to power > > the system off without performing any kind of shutdown. > > Most systems with soft power will perform a hard powerdown if you hold > down the power button for a sufficiently long period of time (10 - 20 > seconds). Actually, it's typically somewhere between four and five. The spec mandates not less than four. Personally, as a sometime developer, I'd get a reset switch. Power cycling your system is Bad. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
