Re: tcsh being dodgy, or pipe code ishoos?
Juli Mallett wrote this message on Wed, Jun 25, 2003 at 00:15 -0500: > * Juli Mallett <[EMAIL PROTECTED]> [ Date: 2003-06-24 ] > [ w.r.t. Re: tcsh being dodgy, or pipe code ishoos? ] > > * Tim Kientzle <[EMAIL PROTECTED]> [ Date: 2003-06-24 ] > > > Hmmm... This looks like xargs isn't waiting for the subcommand > > > to exit. This looks like 'echo -- + 2' and 'echo -- + 3' are > > > running concurrently. > > > > How about this, it essentially says that in the not -P case, no procs > > may be unwaited-on, whereas otherwise we say that 1 may be unwaited-on.. > > jmg@ points out this better idea, of doing the waitchildren before the > vfork, allowing xargs to do its work while the child runs, as seems to > be the desirable effect of having maxprocs=1, so. Ok, I seem to have found out that we are reaping a child that we don't know about. slightly modified xargs produces this: > ( ( echo 2 ; echo 3 ) | ktrace -id -f /tmp/xargs.ktrace ./xargs -I% echo + % ) waiting: waitall: 0, curprocs: 0, maxprocs: 1 reaping: pid: 1073, self: 1072, status: 0 starting started: 1074 +waiting: waitall: 0, curprocs: 0, maxprocs: 1 2starting started: 1075 + waiting: waitall: 1, curprocs: 1, maxprocs: 1 3 reaping: pid: 1074, self: 1072, status: 0 reaping: pid: 1075, self: 1072, status: 0 Examining the output shows no restiges of pid 1073. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DellMod
On Wed, Jun 25, 2003 at 03:44:02AM +, Sebastian Yepes [ESN] wrote: > Hi all you FreeBSD dell freack.. xD > > I have just put in my webpaga the src of the dellmod to control the dell i8500 > > www.x123.info docs->i8500 -> ACPI Great work, but could you please state on your page also that this module is derived from GPL sources? I would not want people to get confused. Furthermore I'd still like to find out whether the 8500 also has some sort of signature for the BIOS version, like my 4150 has. Thanks! --Stijn -- My server has more fans than Britney. -- Steve Warwick, from a posting at [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Best way to get max KVA setting?
I could probably grep for this, but what's the best way to get a hold of the # of pages (or MB of ram) that max KVA is set to? I'm adding another autosize option, and I want to base it on min (KVA, ram) so that it doesn't balloon on boxes where ram >> KVA. Thanks, Mike "Silby" Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh being dodgy, or pipe code ishoos?
* Juli Mallett <[EMAIL PROTECTED]> [ Date: 2003-06-24 ]
[ w.r.t. Re: tcsh being dodgy, or pipe code ishoos? ]
> * Tim Kientzle <[EMAIL PROTECTED]> [ Date: 2003-06-24 ]
> > Hmmm... This looks like xargs isn't waiting for the subcommand
> > to exit. This looks like 'echo -- + 2' and 'echo -- + 3' are
> > running concurrently.
>
> How about this, it essentially says that in the not -P case, no procs
> may be unwaited-on, whereas otherwise we say that 1 may be unwaited-on..
jmg@ points out this better idea, of doing the waitchildren before the
vfork, allowing xargs to do its work while the child runs, as seems to
be the desirable effect of having maxprocs=1, so.
%%%
Index: xargs.c
===
RCS file: /home/ncvs/src/usr.bin/xargs/xargs.c,v
retrieving revision 1.54
diff -u -r1.54 xargs.c
--- xargs.c 13 Jun 2003 17:05:41 - 1.54
+++ xargs.c 25 Jun 2003 05:12:27 -
@@ -518,6 +518,8 @@
}
exec:
childerr = 0;
+ curprocs++;
+ waitchildren(*argv, 0);
switch(pid = vfork()) {
case -1:
err(1, "vfork");
@@ -537,8 +539,6 @@
childerr = errno;
_exit(1);
}
- curprocs++;
- waitchildren(*argv, 0);
}
static void
%%%
--
juli mallett. email: [EMAIL PROTECTED]; efnet: juli;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh being dodgy, or pipe code ishoos?
* Tim Kientzle <[EMAIL PROTECTED]> [ Date: 2003-06-24 ]
[ w.r.t. Re: tcsh being dodgy, or pipe code ishoos? ]
> Artem 'Zazoobr' Ignatjev wrote:
> > Juli Mallett wrote:
> >
> >>Anyone with insight into this?
> >>
> >>([EMAIL PROTECTED]:~)39% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) )
> >>1
> >>+ 2
> >>+ 3
> >>([EMAIL PROTECTED]:~)40% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) )
> >>| cat
> >>1
> >>+ +2
> >>3
> >
> > last cat is not necessary...
> > And it's more weird than that:
> >
> >>( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo -- + % ) )
> >
> > 1
> > -- --+ +2
> > 3
> >
>
>
> Hmmm... This looks like xargs isn't waiting for the subcommand
> to exit. This looks like 'echo -- + 2' and 'echo -- + 3' are
> running concurrently.
How about this, it essentially says that in the not -P case, no procs
may be unwaited-on, whereas otherwise we say that 1 may be unwaited-on..
Thanx,
juli.
%%%
Index: xargs.c
===
RCS file: /home/ncvs/src/usr.bin/xargs/xargs.c,v
retrieving revision 1.54
diff -d -u -r1.54 xargs.c
--- xargs.c 13 Jun 2003 17:05:41 - 1.54
+++ xargs.c 25 Jun 2003 04:45:39 -
@@ -123,7 +123,7 @@
/* 1 byte for each '\0' */
nline -= strlen(*ep++) + 1 + sizeof(*ep);
}
- maxprocs = 1;
+ maxprocs = 0;
while ((ch = getopt(argc, argv, "0E:I:J:L:n:oP:pR:s:tx")) != -1)
switch(ch) {
case 'E':
%%%
--
juli mallett. email: [EMAIL PROTECTED]; efnet: juli;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh being dodgy, or pipe code ishoos?
Tim Kientzle wrote this message on Tue, Jun 24, 2003 at 21:19 -0700: > Artem 'Zazoobr' Ignatjev wrote: > >Juli Mallett wrote: > > > >>Anyone with insight into this? > >> > >>([EMAIL PROTECTED]:~)39% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% > >>echo + % ) ) > >>1 > >>+ 2 > >>+ 3 > >>([EMAIL PROTECTED]:~)40% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% > >>echo + % ) ) | cat > >>1 > >>+ +2 > >>3 > > > >last cat is not necessary... > >And it's more weird than that: > > > >>( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo -- + % ) ) > > > >1 > >-- --+ +2 > >3 > > > > > Hmmm... This looks like xargs isn't waiting for the subcommand > to exit. This looks like 'echo -- + 2' and 'echo -- + 3' are > running concurrently. Yes, but the default xargs w/ -n is only one concurrently, which would mean that tcsh is returning a valid return value before it writes. I have gotten the 3 to appear before the 2. > ( ( echo 2 ; echo 3 ) | xargs -I% /bin/echo + % ) + 3 + 2 (btw, I can see this on sparc w/ tcsh, not bash or sh) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh being dodgy, or pipe code ishoos?
Artem 'Zazoobr' Ignatjev wrote: Juli Mallett wrote: Anyone with insight into this? ([EMAIL PROTECTED]:~)39% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) 1 + 2 + 3 ([EMAIL PROTECTED]:~)40% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) | cat 1 + +2 3 last cat is not necessary... And it's more weird than that: ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo -- + % ) ) 1 -- --+ +2 3 Hmmm... This looks like xargs isn't waiting for the subcommand to exit. This looks like 'echo -- + 2' and 'echo -- + 3' are running concurrently. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR in VM (with backtrace)
Andrew Gallatin wrote: > > Alan L. Cox writes: > > Thanks for letting me know. This is another false positive: Witness > > can't distinguish the lock on the object being destroyed from the lock > > on the object used by UMA because their labels are the same. They will > > never, however, be the same object. So, deadlock isn't a risk. > > In a closed source driver I maintain, I had to resort to passing a > string containing the meaningful name concatonated with some unique info > to mtx_init(). > > It seems like witness could just concat the address of the mutex along > with the strings passed to mtx_init() so as to make sure things were > unique.. > I'm not sure that witness could handle the 30,000 to 200,000 distinct mutex labels that would result from doing this for every vm object. Regards, Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi patch for dell laptop?
On Tue, 24 Jun 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Vincent Poy <[EMAIL PROTECTED]> writes: > : Speaking about ACPI, has anyone figured out how to close the lid > : without suspending? I remember before, when the lid was closed, it would > > add the following to your /boot/loader.conf: > > hw.acpi.lid_switch_state=NONE Putting it in /boot/loader.conf doesn't work since at some port during the system bootup, it will set the hw.acpi.lid_switch_state: S1 back to S1. My /boot/loader.conf is as follows: hw.ata.wc="1" snd_ich_load="YES" acpi_dsdt_load="YES" acpi_dsdt_name="/boot/acpi_dsdt.aml hw.acpi.lid_switch_state=NONE Doing /sbin/sysctl -w hw.acpi.lid_switch_state=NONE in /etc/rc.local does work which was the way I had it before but without the ACPI_DSDT patch, all it does when I close the lid is suspend the machine without the LCD going off and the LCD isn't alive until I reboot the machine. Same thing happens with hw.acpi.lid_switch_state=S1 even with the DSDT patch is that when the system resumes, the LCD is not live either. With the DSDT path and hw.acpi.lid_switch_state=NONE, the LCD turns off without suspending but when you open the lid, the LCD doesn't turn on until you hit Fn-F10. This is with the A10 BIOS on the Dell Inspiron 8200. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] [EMAIL PROTECTED] - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
3d screen saver.
Hello:) I want to present one-night-hack: 3d CERB logo screen saver. It is dedicated for FreeBSD 5.x and it is quite nice (IMHO). You can download it from: http://garage.freebsd.pl/cerb_saver.tbz Enjoy! -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
DellMod
Hi all you FreeBSD dell freack.. xD I have just put in my webpaga the src of the dellmod to control the dell i8500 www.x123.info docs->i8500 -> ACPI -- /* FingerPrint: 5BF1 58B1 DE75 CBE3 6044 7098 1246 1EF6 9E78 041C @@@ @@ @@@ @@! @@@ !@@ @@! @@@ @[EMAIL PROTECTED]@!@ !@@!! @!@ [EMAIL PROTECTED] !!: !!! !:! !!: !!! :: : :: ::.: : :: : : The Power To Kill LinuX */ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unkillable processes with libKSE
* Julian Elischer <[EMAIL PROTECTED]> [030624 19:01]: > As of last testing (yesterday my laptop (non SMP) acted the same.. > > I'm not sure what to suggest. > can you confirm that you are running the newest of everything.. > (though as far as I know it was ok, even several weeks ago). I'll re-cvsup and rebuild everything tommorrow. (Right now I'm getting the bluetooth build error that was fixed this afternoon.) Perhaps something wasn't rebuilt when I thought it was. --Mike pgp0.pgp Description: PGP signature
Re: Unkillable processes with libKSE
On Tue, 24 Jun 2003, Julian Elischer wrote: > I can not duplicate this.. > ON a system (SMP) compiled this afternoon (checked out this afternoon > too), ksetest responds immediatly to ^C and ^Z in the expected manner. > > I am using the csh as my shell and was running as root AND as myself > for the tests. > > %cd /usr/src/tools/KSE/ksetest/ > % make > %./ksetest > main() : 0x804c000 > > [...] I just ran this test here and it locked my system hard. The "zombie" processes were stil around, I guess that may have had something to do with it. When I get some free time I'll try it again with everything mounted RO. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh being dodgy, or pipe code ishoos?
jmallett> Anyone with insight into this? "Me Too" with zsh 4.0.6 on 5-current as of early June/2003. -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh being dodgy, or pipe code ishoos?
On Tue, Jun 24, 2003 at 18:54:11 -0500, Juli Mallett wrote: > stdout. Where does stderr come into it? Yes I know about TTY races Forget about stderr, it looks like fork race somewhere. Minimal example will be ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) which outputs + + 3 2 in rare cases. Note that ( echo 2 ; echo 3 ) | xargs -I% echo + % never pruduce this bug, so no pipes involved, just () ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh being dodgy, or pipe code ishoos?
Juli Mallett wrote: > Anyone with insight into this? > > ([EMAIL PROTECTED]:~)39% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) > 1 > + 2 > + 3 > ([EMAIL PROTECTED]:~)40% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) | > cat > 1 > + +2 > 3 last cat is not necessary... And it's more weird than that: > ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo -- + % ) ) 1 -- --+ +2 3 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh being dodgy, or pipe code ishoos?
* Andrey Chernov <[EMAIL PROTECTED]> [ Date: 2003-06-24 ] [ w.r.t. Re: tcsh being dodgy, or pipe code ishoos? ] > On Tue, Jun 24, 2003 at 18:35:15 -0500, Juli Mallett wrote: > > Anyone with insight into this? > > > > ([EMAIL PROTECTED]:~)39% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) > > 1 > > + 2 > > + 3 > > Loks like stdout/stderr mix, but I not check the code, so just raw guess. Really? What makes you say that? All of these utilities deal with stdout. Where does stderr come into it? Yes I know about TTY races outputting to stdout and stderr from different processes, especially how confusing it is to have say foo | bar | baz and bar puts something on stderr, and baz buffers for a second. But I don't see how, practically, this comes into play? The first is clearly correct, but throwing a pipe of alll the combined stuff in seems to complicate matters, so I suspect either buggy pipe code (not unheard of) or buggy tcsh handling of pipes (possible). Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi patch for dell laptop?
In message: <[EMAIL PROTECTED]> Vincent Poy <[EMAIL PROTECTED]> writes: : Speaking about ACPI, has anyone figured out how to close the lid : without suspending? I remember before, when the lid was closed, it would add the following to your /boot/loader.conf: hw.acpi.lid_switch_state=NONE Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh being dodgy, or pipe code ishoos?
On Tue, Jun 24, 2003 at 18:35:15 -0500, Juli Mallett wrote: > Anyone with insight into this? > > ([EMAIL PROTECTED]:~)39% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) > 1 > + 2 > + 3 Loks like stdout/stderr mix, but I not check the code, so just raw guess. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tcsh being dodgy, or pipe code ishoos?
Anyone with insight into this? ([EMAIL PROTECTED]:~)39% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) 1 + 2 + 3 ([EMAIL PROTECTED]:~)40% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) | cat 1 + +2 3 ([EMAIL PROTECTED]:~)41% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) | cat 1 + +2 3 ([EMAIL PROTECTED]:~)42% ( echo 1 ; ( ( echo 2 ; echo 3 ) | xargs -I% echo + % ) ) | cat 1 + 2+ 3 -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
broken DRM for ATI Radeon
Since the "new" DRM has been integrated in current by the end of April, I've been unable to use DRI with my ATI card. The X server starts and apparently works, then suddenly (when scrolling an xterm or doing some memory-intensive operation like 3D rendering) enters a busy loop. After an awful lot of searching and attempting to debug the code, I've finally been able to find out that the server loops on an ioctl(DRM_IOCTL_DMA) returning EBUSY, which means that the DRM driver can't get a free buffer from radeon_cp.c:radeon_freelist_get(). My XFree server is the latest version of the package (XFree86-Server-4.3.0_8). Earlier versions exhibited the same behaviour. Does anyone have a clue on where to investigate some more and fix that? -- Pierre Beyssac [EMAIL PROTECTED] [EMAIL PROTECTED] Free domains: http://www.eu.org/ or mail [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unkillable processes with libKSE
On Tue, 24 Jun 2003, Michael Edenfield wrote: [...] > thread_start() : 0x84af000 84af000 > kse_create() -> 0 > A*.kse_create() -> -1 > [...] > *R*.S.*T*.^C^D^Z > > (no response on this tty, so I close it). I can not duplicate this.. ON a system (SMP) compiled this afternoon (checked out this afternoon too), ksetest responds immediatly to ^C and ^Z in the expected manner. I am using the csh as my shell and was running as root AND as myself for the tests. %cd /usr/src/tools/KSE/ksetest/ % make %./ksetest main() : 0x804c000 [...] +-thread_start() : 0x84af000 84af000 kse_create() -> 0 A*.kse_create() -> 0 B-+.*+-C*.D-+.*+-E*.F-+.*+-G*.H-+.*+-I*.+J.*--K+*..+L-**.-M+.*+N-*.-O+.*+ P-*.-Q+*+R.-.*-S+*+T-.-U+*.+V-.*-W+*.+X-.*-Y+*.+Z-.*-A*.+*.+B-.*-C++-*.D E-+.*+-F*.G-+.*+-H*.I-+.*+-J*.K-+.*L+-*.-+M.*.*N+-.*-+O*.P+-.*-+Q*.R+-.*- +S*.T+-.*-+U*.V+-.*-+W*.X+-.*-+Y*.Z+-.*-+A*.B+-.*-+C*.D+-.*-+E*.F+-.*-+G *.H+-.*-+I*+-.JK-+.*+-L*.M-+.*+-N*.O-+.*-.P+**.-+Q.*R+-*.-+S.*T+-*.-+U.* V+-*.-+W.*X+-*.-+Y.*Z-+*.+-A.*B-+*.+-C.*D-+*.+-E.*F-+*.+-G.*H-+*.+-I*.-J +.*+K-*.-L+.*+M--N+.*+O-*.-P+.*+Q-*.-R+.*+S-*.T.+-**.-U+.*+V-*.-W+.X-*++ -Y*.Z-+.*+-A*.B-+.*+-C*.D-+.*+-E*.F-+.*+-G*.+-.H*I-+*.+-J.*K-+*.+-L.*M-+ *.^C % [...] uts() at : 0x8048e20 uts stack at : 0x8486000 - 0x848e000 thread_start() : 0x848e000 848e000 thread_start() : 0x848e800 848e800 thread_start() : 0x84af000 84af000 kse_create() -> 0 A*.kse_create() -> 0 B+-.*-+C*.D+-.*-+E*.F+-.*-+G*.H+-.*I+.*--+J*.-+.K*L+-*.-+M.*N+-*.-+O.*P +-*.-+Q.*R+-*.-+S.*T+-*.-+U.*V+-*.W*.+-.*-+X*.Y+-.*-+Z*.A+-.*-+B*.C+-.* -+D*.E+-.*-+F+-*G.H-+.*+-I*.^Z Suspended %fg ./ksetest *.+-J.*K-+*.+-L.*M-+*.+-N.*O-+*.+-P.*Q-+*.^C % As of last testing (yesterday my laptop (non SMP) acted the same.. I'm not sure what to suggest. can you confirm that you are running the newest of everything.. (though as far as I know it was ok, even several weeks ago). Julian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR in VM (with backtrace)
Alan L. Cox writes: > Thanks for letting me know. This is another false positive: Witness > can't distinguish the lock on the object being destroyed from the lock > on the object used by UMA because their labels are the same. They will > never, however, be the same object. So, deadlock isn't a risk. In a closed source driver I maintain, I had to resort to passing a string containing the meaningful name concatonated with some unique info to mtx_init(). It seems like witness could just concat the address of the mutex along with the strings passed to mtx_init() so as to make sure things were unique.. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: optreset undeclared
On Tue, Jun 24, 2003 at 03:37:52PM +0200, Martin Dvorak wrote: > Hi, > > am I the only one having this problem while building world: I think so. Are you sure you have completely up-to-date sources and no extra cruft in your source and object trees? Kris pgp0.pgp Description: PGP signature
Re: LOR in VM (with backtrace)
Kris Kennaway wrote: > > CURRENT dated June 19; > > lock order reversal > 1st 0xc45788ac vm object (vm object) @ > /a/asami/portbuild/i386/src-client/sys/vm/vm_object.c:1506 > 2nd 0xc082f110 system map (system map) @ > /a/asami/portbuild/i386/src-client/sys/vm/vm_kern.c:328 > > Debugger(c03f450d,c082f110,c043190e,c043190e,c043178f) at Debugger+0x54 > witness_lock(c082f110,8,c043178f,148,d8ca79f8) at witness_lock+0x6ac > _mtx_lock_flags(c082f110,0,c043178f,148,c4496850) at _mtx_lock_flags+0xb1 > _vm_map_lock(c082f0b0,c043178f,148,c025dc34,246) at _vm_map_lock+0x36 > kmem_malloc(c082f0b0,1000,101,d8ca7a8c,c0390425) at kmem_malloc+0x65 > page_alloc(c083a240,1000,d8ca7a7f,101,c0457e2c) at page_alloc+0x27 > slab_zalloc(c083a240,101,c04332aa,66e,c414e5c4) at slab_zalloc+0x155 > uma_zone_slab(c083a240,101,c04332aa,66e,0) at uma_zone_slab+0xd8 > uma_zalloc_internal(c083a240,0,101,6ee,0) at uma_zalloc_internal+0x55 > uma_zfree_arg(c414e5a0,d7a86000,0,1,0) at uma_zfree_arg+0x2cc > swp_pager_meta_free(c45788ac,1d,0,1,0) at swp_pager_meta_free+0x1b2 > swap_pager_freespace(c45788ac,1d,0,1,0) at swap_pager_freespace+0x57 > vm_object_backing_scan(c4bec5c8,4,c0432299,5f7,c0432299) at > vm_object_backing_scan+0x28a > vm_object_collapse(c4bec5c8,0,c0432299,1ef,c45a0ec4) at vm_object_collapse+0x11a > vm_object_deallocate(c4fab940,c5093ce4,c4fab940,c5093ce4,d8ca7c60) at > vm_object_deallocate+0x28e > vm_map_entry_delete(c1506100,c5093ce4,c043197c,86d,c041ada4) at > vm_map_entry_delete+0x3b > vm_map_delete(c1506100,0,bfc0,c1506100,c4123f00) at vm_map_delete+0x413 > vm_map_remove(c1506100,0,bfc0,11d,65) at vm_map_remove+0x55 > exit1(c4496850,0,c041a26b,65,d8ca7d40) at exit1+0x63d > sys_exit(c4496850,d8ca7d10,c0437c26,3fd,1) at sys_exit+0x41 > syscall(2f,2f,2f,0,) at syscall+0x26e > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x2829e9ff, esp = 0xbfbfde3c, ebp = > 0xbfbfde58 --- > Thanks for letting me know. This is another false positive: Witness can't distinguish the lock on the object being destroyed from the lock on the object used by UMA because their labels are the same. They will never, however, be the same object. So, deadlock isn't a risk. I will probably disable witness checking on the "system map" mutexes (or at least the kmem_map's mutex) shortly so that folks don't become conditioned to ignoring these. Regards, Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
truncate operation on fat32 may corrupt the file system
>Submitter-Id: current-users
>Originator:Ariff Abdullah
>Organization: MyBSD
>Confidential: no
>Synopsis: truncate operation on fat32 may corrupt the file system
>Severity: critical
>Priority: high
>Category: kern
>Class: sw-bug
>Release: FreeBSD 4.7-RELEASE i386
>Environment:
System: 4.7-RELEASE, 5.1-RELEASE (GENERIC)
>Description:
Truncate operation involving truncate() or ftruncate() on
FAT32 mounted as msdos either failed or silently corrupting
the file or even worse, corrupting the neighbour file reiside
in the same partition/file system.
>How-To-Repeat:
# cd /to/fat32/partition/
# dd if=/dev/zero of=XX bs=4099 count=1
# truncate -s 4097 XX
truncate: XX: Argument list too long
errno E2BIG
>Fix:
--- /usr/src/sys/msdosfs/msdosfs_denode.c.orig Tue Jun 24 06:01:09 2003
+++ /usr/src/sys/msdosfs/msdosfs_denode.c Tue Jun 24 05:53:41 2003
@@ -501,26 +501,19 @@
bn = cntobn(pmp, eofentry);
error = bread(pmp->pm_devvp, bn, pmp->pm_bpcluster,
NOCRED, &bp);
- } else {
- bn = de_blk(pmp, length);
- error = bread(DETOV(dep), bn, pmp->pm_bpcluster,
- NOCRED, &bp);
- }
- if (error) {
- brelse(bp);
+ if (error) {
+ brelse(bp);
#ifdef MSDOSFS_DEBUG
- printf("detrunc(): bread fails %d\n", error);
+ printf("detrunc(): bread fails %d\n", error);
#endif
- return (error);
+ return (error);
+ }
+ bzero(bp->b_data + boff, pmp->pm_bpcluster - boff);
+ if (flags & IO_SYNC)
+ bwrite(bp);
+ else
+ bdwrite(bp);
}
- /*
-* is this the right place for it?
-*/
- bzero(bp->b_data + boff, pmp->pm_bpcluster - boff);
- if (flags & IO_SYNC)
- bwrite(bp);
- else
- bdwrite(bp);
}
/*
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: flock error
In the last episode (Jun 18), Santos said: > I'm trying to do a make release on 5.1-RELEASE to do a custom 5.1. > > CHROOTDIR=/home/custom and CVSROOT=/home/ncvs are both on a redhat nfs > server. I had some errors related to telnet, telnetd and libtelnet. > After a few makes the error went away. Now the the error is this: > > /home/custom/etc/login.conf; install > -o root -g wheel -m 755 netstart pccard_ether rc.suspend rc.resume > /home/custom/etc; ins > tall -o root -g wheel -m 600 master.passwd nsmb.conf opieaccess > /home/custom/etc; pwd_mk > db -p -d /home/custom/etc /home/custom/etc/master.passwd > pwd_mkdb: flock: Operation not supported > *** Error code 1 > > I read somewhere weeks ago, that on -current, nfs locking and chroot > stuff didn't play well together > > Was this corrected, or is this a user error? :) Do you have rpc.lockd and rpc.statd loaded on the RedHat box? Any messages in its logs? -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unkillable processes with libKSE
If it's duplicatable on recent systems I'll see it on my test system... thanks.. On Tue, 24 Jun 2003, Michael Edenfield wrote: > * Julian Elischer <[EMAIL PROTECTED]> [030624 14:47]: > > > > I had the same experience just running the KSE test application from > > > /usr/src/tools last night. I ended up with three unkillable ksetest > > > applications and ultimately rebooted to get rid of them. I was > > > planning to report it as soon as I finished reading my email :) > > > > "Interesting".. > > > > I'll check on my testd machine.. > > the test program responded to ^C as of a few days ago.. > > I just rebuilt my system to see if the problem had perhaps been > solved, but it's still doing it. It doesn't cause any problems (the > process doesn't look like it's doing anything, just not going away) so > I am gonna just let the processes sit there. > > [EMAIL PROTECTED]:/usr/src/tools/KSE/ksetest# ./ksetest > main() : 0x804c000 > eip -> 0x280c06b3 > uts() at : 0x8048e20 > uts stack at : 0x814d000 - 0x8155000 > main() : 0x804c400 > eip -> 0x280c06b3 > uts() at : 0x8048e20 > uts stack at : 0x8255000 - 0x825d000 > thread_start() : 0x804c800 804c800 > thread_start() : 0x826d000 826d000 > kse_create() -> 0 > +-kse_create() -> -1 > main() : 0x826d800 > eip -> 0x280c06b3 > uts() at : 0x8048e20 > uts stack at : 0x837e000 - 0x8386000 > main() : 0x826dc00 > eip -> 0x280c06b3 > uts() at : 0x8048e20 > uts stack at : 0x8486000 - 0x848e000 > thread_start() : 0x848e000 848e000 > thread_start() : 0x848e800 848e800 > thread_start() : 0x84af000 84af000 > kse_create() -> 0 > A*.kse_create() -> -1 > [...] > *R*.S.*T*.^C^D^Z > > (no response on this tty, so I close it). > > On another tty I get this: > > [EMAIL PROTECTED]:/home/kutulu# ps x | grep ksetest > 30947 p2 RL-0:00.12 ./ksetest > 30947 p2 RL-0:00.12 ./ksetest > 30947 p2 TL-0:00.12 ./ksetest > [EMAIL PROTECTED]:/home/kutulu# kill -KILL 30947 > [EMAIL PROTECTED]:/home/kutulu# ps x | grep ksetest > 30947 p2 RL-0:00.12 ./ksetest > 30947 p2 RL-0:00.12 ./ksetest > 30947 p2 TL-0:00.12 ./ksetest > [EMAIL PROTECTED]:/home/kutulu# top > > [...] > 30947 root 760 5760K 628K WAIT 0:00 0.00% 0.00% ksetest > 30947 root 80 5760K 628K RUN 0:00 0.00% 0.00% ksetest > 30947 root 80 5760K 628K RUN 0:00 0.00% 0.00% ksetest > [...] > > I don't have DDB in this kernel at the moment (it's remote and I > prefer the crash dumps) but I can put it in and try again if there's > something you can use from it. > > --Mike > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unkillable processes with libKSE
* Julian Elischer <[EMAIL PROTECTED]> [030624 14:47]: > > I had the same experience just running the KSE test application from > > /usr/src/tools last night. I ended up with three unkillable ksetest > > applications and ultimately rebooted to get rid of them. I was > > planning to report it as soon as I finished reading my email :) > > "Interesting".. > > I'll check on my testd machine.. > the test program responded to ^C as of a few days ago.. I just rebuilt my system to see if the problem had perhaps been solved, but it's still doing it. It doesn't cause any problems (the process doesn't look like it's doing anything, just not going away) so I am gonna just let the processes sit there. [EMAIL PROTECTED]:/usr/src/tools/KSE/ksetest# ./ksetest main() : 0x804c000 eip -> 0x280c06b3 uts() at : 0x8048e20 uts stack at : 0x814d000 - 0x8155000 main() : 0x804c400 eip -> 0x280c06b3 uts() at : 0x8048e20 uts stack at : 0x8255000 - 0x825d000 thread_start() : 0x804c800 804c800 thread_start() : 0x826d000 826d000 kse_create() -> 0 +-kse_create() -> -1 main() : 0x826d800 eip -> 0x280c06b3 uts() at : 0x8048e20 uts stack at : 0x837e000 - 0x8386000 main() : 0x826dc00 eip -> 0x280c06b3 uts() at : 0x8048e20 uts stack at : 0x8486000 - 0x848e000 thread_start() : 0x848e000 848e000 thread_start() : 0x848e800 848e800 thread_start() : 0x84af000 84af000 kse_create() -> 0 A*.kse_create() -> -1 [...] *R*.S.*T*.^C^D^Z (no response on this tty, so I close it). On another tty I get this: [EMAIL PROTECTED]:/home/kutulu# ps x | grep ksetest 30947 p2 RL-0:00.12 ./ksetest 30947 p2 RL-0:00.12 ./ksetest 30947 p2 TL-0:00.12 ./ksetest [EMAIL PROTECTED]:/home/kutulu# kill -KILL 30947 [EMAIL PROTECTED]:/home/kutulu# ps x | grep ksetest 30947 p2 RL-0:00.12 ./ksetest 30947 p2 RL-0:00.12 ./ksetest 30947 p2 TL-0:00.12 ./ksetest [EMAIL PROTECTED]:/home/kutulu# top [...] 30947 root 760 5760K 628K WAIT 0:00 0.00% 0.00% ksetest 30947 root 80 5760K 628K RUN 0:00 0.00% 0.00% ksetest 30947 root 80 5760K 628K RUN 0:00 0.00% 0.00% ksetest [...] I don't have DDB in this kernel at the moment (it's remote and I prefer the crash dumps) but I can put it in and try again if there's something you can use from it. --Mike pgp0.pgp Description: PGP signature
Re: Unkillable processes with libKSE
On Tue, 24 Jun 2003, Julian Elischer wrote: > what about kill -9 887 > ? > The signals in libKSE are known to be 'delicate'. > We are working on (well, actually David Xu is working on) > a set of code to make the signal more robust. > Hopefully this will fix the problem you are seeing.. Kill -9 doesn't work. > Any other comments? > Other than not being able to kill it, how as the experience? KDE seems fine... Firebird "died" before it got far enough to open any windows. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on i386/i386
I've fixed the breakage and I'll commit other fixes pointed out by ru.. seems a pity to back it out just for that.. On Tue, 24 Jun 2003, Maksim Yevmenkin wrote: > > Hello, > > please disconnect usr.bin/bluetooth and usr.sbin/bluetooth from the build > for now. i'm working on the patch to fix this. sorry about this. > > thanks, > max > > > TB --- 2003-06-24 17:27:15 - starting CURRENT tinderbox run for i386/i386 > > TB --- 2003-06-24 17:27:15 - checking out the source tree > > TB --- cd /home/des/tinderbox/CURRENT/i386/i386 > > TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src > > TB --- 2003-06-24 17:28:58 - building world > > TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src > > TB --- /usr/bin/make -B buildworld > > >>> Rebuilding the temporary build tree > > >>> stage 1: legacy release compatibility shims > > >>> stage 1: bootstrap tools > > >>> stage 2: cleaning up the object tree > > >>> stage 2: rebuilding the object tree > > >>> stage 2: build tools > > >>> stage 3: cross tools > > >>> stage 4: populating > > > /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include > > >>> stage 4: building libraries > > >>> stage 4: make dependencies > > [...] > > echo hccontrol: /usr/sbin//usr/lib/libc.a >> .depend > > ===> usr.sbin/bluetooth/hcsecd > > lex -t > > > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/lexer.l > > > lexer.c > > yacc -d -o parser.c > > > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/parser.y > > rm -f .depend > > mkdep -f .depend -a > > > -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/../../../sys/netgraph/bluetooth/include > > > > > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/hcsecd.c > > lexer.c parser.c > > > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/parser.y:41:20: > > hcsecd.h: No such file or directory > > mkdep: compile failed > > *** Error code 1 > > > > Stop in > > > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd. > > *** Error code 1 > > > > Stop in > > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth. > > *** Error code 1 > > > > Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin. > > *** Error code 1 > > > > Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. > > *** Error code 1 > > > > Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. > > *** Error code 1 > > > > Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. > > TB --- 2003-06-24 18:06:21 - /usr/bin/make returned exit code 1 > > TB --- 2003-06-24 18:06:21 - ERROR: failed to build world > > TB --- 2003-06-24 18:06:21 - tinderbox aborted > > > > > __ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on i386/pc98
TB --- 2003-06-24 18:06:29 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-06-24 18:06:29 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-24 18:08:22 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies [...] echo hccontrol: /usr/sbin//usr/lib/libc.a >> .depend ===> usr.sbin/bluetooth/hcsecd lex -t /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.sbin/bluetooth/hcsecd/lexer.l > lexer.c yacc -d -o parser.c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.sbin/bluetooth/hcsecd/parser.y rm -f .depend mkdep -f .depend -a -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.sbin/bluetooth/hcsecd/../../../sys/netgraph/bluetooth/include /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.sbin/bluetooth/hcsecd/hcsecd.c lexer.c parser.c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.sbin/bluetooth/hcsecd/parser.y:41:20: hcsecd.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.sbin/bluetooth/hcsecd. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.sbin/bluetooth. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.sbin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-06-24 18:45:45 - /usr/bin/make returned exit code 1 TB --- 2003-06-24 18:45:45 - ERROR: failed to build world TB --- 2003-06-24 18:45:45 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unkillable processes with libKSE
On Tue, 24 Jun 2003, Michael Edenfield wrote: > * Wesley Morgan <[EMAIL PROTECTED]> [030624 12:45]: > > > Thought I would give libKSE a try making use of the 'libmap.conf' library > > translations. KDE loads fine, but when I tried to run Firebird I get a > > process with 3 threads, and it is completely unkillable. It also is > > I had the same experience just running the KSE test application from > /usr/src/tools last night. I ended up with three unkillable ksetest > applications and ultimately rebooted to get rid of them. I was > planning to report it as soon as I finished reading my email :) "Interesting".. I'll check on my testd machine.. the test program responded to ^C as of a few days ago.. > > --Mike > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unkillable processes with libKSE
what about kill -9 887 ? The signals in libKSE are known to be 'delicate'. We are working on (well, actually David Xu is working on) a set of code to make the signal more robust. Hopefully this will fix the problem you are seeing.. Any other comments? Other than not being able to kill it, how as the experience? On Tue, 24 Jun 2003, Wesley Morgan wrote: > Thought I would give libKSE a try making use of the 'libmap.conf' library > translations. KDE loads fine, but when I tried to run Firebird I get a > process with 3 threads, and it is completely unkillable. It also is > holding some kind of lock on it's own directory that has caused a couple > of ls's to hang unkillable in lstat(): > > [EMAIL PROTECTED]:/usr/X11R6/lib/firebird/lib$]: ls > ^C^C^Z^Z^Z^C^C^Z^C^Z^C^Z > > The offending threads are: > > 887 morganw -40 39120K 30972K ufs 0:02 0.00% 0.00% MozillaFirebi > 887 morganw 760 39120K 30972K WAIT 0:02 0.00% 0.00% MozillaFirebi > 887 morganw -80 39120K 30972K RUN 0:02 0.00% 0.00% MozillaFirebi > > Kernel has ddb in it and I'll leave the processes running as they don't > seem to be causing any harm so if there is any information I can provide > to help debug, let me know. Truss/strace/ktrace produce no output. > > -- > Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
questions about VM_KMEM_SIZE_SCALE
Hi there,
Can anyone shed some light on the implications of adjusting
VM_KMEM_SIZE_SCALE? In particular I'm wondering if I increase this to,
say, 2, what happens? I must admit I don't know how KVA is different from
KVM or total RAM... so the note in kern_malloc ("on an x86 with 256M KVA,
try to keep VM_KMEM_SIZE_MAX at 80M or below") doesn't shed enough light
on the matter. What are the implications of VM_KMEM_SIZE getting large?
Does changing this affect memory available to user programs if it's unused
by the kernel?
Thanks for any assistance,
Jay
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Nothing fails like success because you do not learn
anything from it. The only thing we ever learn from
is failure. Success only confirms our superstitions.
Jay Kuri [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on i386/i386
Hello, please disconnect usr.bin/bluetooth and usr.sbin/bluetooth from the build for now. i'm working on the patch to fix this. sorry about this. thanks, max > TB --- 2003-06-24 17:27:15 - starting CURRENT tinderbox run for i386/i386 > TB --- 2003-06-24 17:27:15 - checking out the source tree > TB --- cd /home/des/tinderbox/CURRENT/i386/i386 > TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src > TB --- 2003-06-24 17:28:58 - building world > TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src > TB --- /usr/bin/make -B buildworld > >>> Rebuilding the temporary build tree > >>> stage 1: legacy release compatibility shims > >>> stage 1: bootstrap tools > >>> stage 2: cleaning up the object tree > >>> stage 2: rebuilding the object tree > >>> stage 2: build tools > >>> stage 3: cross tools > >>> stage 4: populating > /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include > >>> stage 4: building libraries > >>> stage 4: make dependencies > [...] > echo hccontrol: /usr/sbin//usr/lib/libc.a >> .depend > ===> usr.sbin/bluetooth/hcsecd > lex -t > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/lexer.l > > lexer.c > yacc -d -o parser.c > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/parser.y > rm -f .depend > mkdep -f .depend -a > -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/../../../sys/netgraph/bluetooth/include > > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/hcsecd.c > lexer.c parser.c > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/parser.y:41:20: > hcsecd.h: No such file or directory > mkdep: compile failed > *** Error code 1 > > Stop in > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd. > *** Error code 1 > > Stop in > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth. > *** Error code 1 > > Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin. > *** Error code 1 > > Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. > *** Error code 1 > > Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. > *** Error code 1 > > Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. > TB --- 2003-06-24 18:06:21 - /usr/bin/make returned exit code 1 > TB --- 2003-06-24 18:06:21 - ERROR: failed to build world > TB --- 2003-06-24 18:06:21 - tinderbox aborted > __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on i386/i386
TB --- 2003-06-24 17:27:15 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-06-24 17:27:15 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-24 17:28:58 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies [...] echo hccontrol: /usr/sbin//usr/lib/libc.a >> .depend ===> usr.sbin/bluetooth/hcsecd lex -t /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/lexer.l > lexer.c yacc -d -o parser.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/parser.y rm -f .depend mkdep -f .depend -a -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/../../../sys/netgraph/bluetooth/include /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/hcsecd.c lexer.c parser.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd/parser.y:41:20: hcsecd.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth/hcsecd. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin/bluetooth. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/usr.sbin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-06-24 18:06:21 - /usr/bin/make returned exit code 1 TB --- 2003-06-24 18:06:21 - ERROR: failed to build world TB --- 2003-06-24 18:06:21 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unkillable processes with libKSE
* Wesley Morgan <[EMAIL PROTECTED]> [030624 12:45]: > Thought I would give libKSE a try making use of the 'libmap.conf' library > translations. KDE loads fine, but when I tried to run Firebird I get a > process with 3 threads, and it is completely unkillable. It also is I had the same experience just running the KSE test application from /usr/src/tools last night. I ended up with three unkillable ksetest applications and ultimately rebooted to get rid of them. I was planning to report it as soon as I finished reading my email :) --Mike pgp0.pgp Description: PGP signature
Re: [current] Re: ACPI Patch/DSDT .asl for Dell Inspiron 5000
On Mon, 23 Jun 2003, David Gilbert wrote: > > "Nate" == Nate Lawson <[EMAIL PROTECTED]> writes: > Nate> Thanks for your patch submission. I looked into it and found a > Nate> few problems. Attached is a patch based on yours that should be > Nate> equivalent but fixes a few problems: > > Is this working for your laptop's S3 suspend? I'm trying to figure > out what is required to make the S3 suspend work on my Dell D800 . Your message is not relevant to this particular discussion. Please post your problems including dmesg to the list separately. As far as the topic goes, I've looked further into fixing EC support and there are much more extensive problems in this file. I'm currently reworking and debugging it. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Unkillable processes with libKSE
Thought I would give libKSE a try making use of the 'libmap.conf' library translations. KDE loads fine, but when I tried to run Firebird I get a process with 3 threads, and it is completely unkillable. It also is holding some kind of lock on it's own directory that has caused a couple of ls's to hang unkillable in lstat(): [EMAIL PROTECTED]:/usr/X11R6/lib/firebird/lib$]: ls ^C^C^Z^Z^Z^C^C^Z^C^Z^C^Z The offending threads are: 887 morganw -40 39120K 30972K ufs 0:02 0.00% 0.00% MozillaFirebi 887 morganw 760 39120K 30972K WAIT 0:02 0.00% 0.00% MozillaFirebi 887 morganw -80 39120K 30972K RUN 0:02 0.00% 0.00% MozillaFirebi Kernel has ddb in it and I'll leave the processes running as they don't seem to be causing any harm so if there is any information I can provide to help debug, let me know. Truss/strace/ktrace produce no output. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI thermal _ACx values
On Tue, Jun 24, 2003 at 11:20:56AM -0400, Michael W. Oliver wrote: > Here is the problem. When I boot up, everything is working fine, and the > following sysctl is set as follows: > > hw.acpi.thermal.tz0._ACx: 3351 -1 -1 -1 -1 -1 -1 -1 -1 -1 (3351 - 2732) / 10 = 61.9 degrees Centigrade So that's the temperature your system CPU is at. > > Ok, this is fine, except that sometimes the first value isn't 3351. I have > seen 3331 and 3341, too. Is that a big deal? And, how is this value set? > > Now, on to the problem. When I suspend the machine (S1), and then wake it > back up again, the first value is changed to -1, just like the other nine > values, yielding: > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > So, if I try to change the value back to 3331, I find out that this is a > read-only oid. I found that I can get the value restored by disconnecting > the AC power (putting the machine in 'economy' mode) and then restoring the > AC power (putting the maching back into 'performance' mode). > > I turned on verbose ACPI logging and here is what I see in the message log: > > acpi_tz0: _AC9: temperature 61.9 >= setpoint -273.-2 > acpi_tz0: _AC8: temperature 61.9 >= setpoint -273.-2 > acpi_tz0: _AC7: temperature 61.9 >= setpoint -273.-2 > acpi_tz0: _AC6: temperature 61.9 >= setpoint -273.-2 > acpi_tz0: _AC5: temperature 61.9 >= setpoint -273.-2 > acpi_tz0: _AC4: temperature 61.9 >= setpoint -273.-2 > acpi_tz0: _AC3: temperature 61.9 >= setpoint -273.-2 > acpi_tz0: _AC2: temperature 61.9 >= setpoint -273.-2 > acpi_tz0: _AC1: temperature 61.9 >= setpoint -273.-2 > acpi_tz0: _AC0: temperature 61.9 >= setpoint -273.-2 > acpi_tz0: switched from NONE to _AC0: 61.9C > acpi_tz0: WARNING - current temperature (61.9C) exceeds system limits > acpi_tz0: _AC0: temperature 62.9 >= setpoint 61.9 > acpi_tz0: switched from NONE to _AC0: 62.9C > acpi_tz0: switched from _AC0 to NONE: 59.9C > acpi_tz0: _AC0: temperature 61.9 >= setpoint 61.9 > acpi_tz0: switched from NONE to _AC0: 61.9C > acpi_tz0: switched from _AC0 to NONE: 55.9C > > Do I have anything to fear in the -1 value that replaces the 3351 when > waking up from suspend? > > I have searched high and low and found very little information. Thanks in > advance for your replies, they are much appreciated. > > -- > +-+--+ > | Michael W. Oliver, CCNP | "The tree of liberty must be | > | IPv6 & FreeBSD mark | refreshed from time to time | > | [EMAIL PROTECTED]| with the blood of patriots | > | http://michael.gargantuan.com/| and tyrants."| > | ASpath-tree, Looking Glass, etc. | - President Thomas Jefferson | > | +--+ > | gpg key - http://michael.gargantuan.com/gnupg/pubkey.asc | > ++ > > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Gunnar Flygt OPC Data Sveriges Radio ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI stuff to make Libretto 110CT work
Hi
You (?) gave me these patches at least 6 months ago, and they've
been working for my Libretto ever since then. Is it OK if I commit
them?
M
--
Mark Murray
iumop ap!sdn w,I idlaH
Index: dev/acpica/acpi.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v
retrieving revision 1.89
diff -u -d -r1.89 acpi.c
--- dev/acpica/acpi.c 1 May 2003 18:51:43 - 1.89
+++ dev/acpica/acpi.c 2 May 2003 08:15:39 -
@@ -817,6 +817,10 @@
if (ACPI_SUCCESS(AcpiGetHandle(ACPI_ROOT_OBJECT, scopes[i], &parent)))
AcpiWalkNamespace(ACPI_TYPE_ANY, parent, 100, acpi_probe_child, bus, NULL);
+if (devclass_get_device(devclass_find("isa"), 0) == NULL) {
+ device_set_flags(BUS_ADD_CHILD(bus, 0, "isa", 0), 1);
+}
+
/*
* Scan all of the child devices we have created and let them probe/attach.
*/
Index: isa/isa_common.c
===
RCS file: /home/ncvs/src/sys/isa/isa_common.c,v
retrieving revision 1.35
diff -u -d -r1.35 isa_common.c
--- isa/isa_common.c11 Jun 2003 00:32:45 - 1.35
+++ isa/isa_common.c11 Jun 2003 08:10:34 -
@@ -1108,6 +1108,60 @@
1, /* no softc */
};
+static int
+acpi_isa_probe(device_t dev)
+{
+
+ if (device_get_flags(dev) == 0) {
+ return (ENXIO);
+ }
+
+ return (isa_probe(dev));
+}
+
+static device_method_t acpi_isa_methods[] = {
+ /* Device interface */
+ DEVMETHOD(device_probe, acpi_isa_probe),
+ DEVMETHOD(device_attach,isa_attach),
+ DEVMETHOD(device_detach,bus_generic_detach),
+ DEVMETHOD(device_shutdown, bus_generic_shutdown),
+ DEVMETHOD(device_suspend, bus_generic_suspend),
+ DEVMETHOD(device_resume,bus_generic_resume),
+
+ /* Bus interface */
+ DEVMETHOD(bus_add_child,isa_add_child),
+ DEVMETHOD(bus_print_child, isa_print_child),
+ DEVMETHOD(bus_probe_nomatch,isa_probe_nomatch),
+ DEVMETHOD(bus_read_ivar,isa_read_ivar),
+ DEVMETHOD(bus_write_ivar, isa_write_ivar),
+ DEVMETHOD(bus_child_detached, isa_child_detached),
+ DEVMETHOD(bus_driver_added, isa_driver_added),
+ DEVMETHOD(bus_setup_intr, isa_setup_intr),
+ DEVMETHOD(bus_teardown_intr,isa_teardown_intr),
+
+ DEVMETHOD(bus_get_resource_list,isa_get_resource_list),
+ DEVMETHOD(bus_alloc_resource, isa_alloc_resource),
+ DEVMETHOD(bus_release_resource, isa_release_resource),
+ DEVMETHOD(bus_set_resource, isa_set_resource),
+ DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),
+ DEVMETHOD(bus_delete_resource, bus_generic_rl_delete_resource),
+ DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
+ DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
+
+ /* ISA interface */
+ DEVMETHOD(isa_add_config, isa_add_config),
+ DEVMETHOD(isa_set_config_callback, isa_set_config_callback),
+ DEVMETHOD(isa_pnp_probe,isa_pnp_probe),
+
+ { 0, 0 }
+};
+
+static driver_t acpi_isa_driver = {
+ "isa",
+ acpi_isa_methods,
+ 1, /* no softc */
+};
+
/*
* ISA can be attached to a PCI-ISA bridge or directly to the legacy device.
*/
@@ -1115,5 +1169,6 @@
DRIVER_MODULE(isa, eisab, isa_driver, isa_devclass, 0, 0);
#if defined(__i386__) || defined(__amd64__)
DRIVER_MODULE(isa, legacy, isa_driver, isa_devclass, 0, 0);
+DRIVER_MODULE(isa, acpi, acpi_isa_driver, isa_devclass, 0, 0);
#endif
MODULE_VERSION(isa, 1);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI thermal _ACx values
Here is the problem. When I boot up, everything is working fine, and the following sysctl is set as follows: hw.acpi.thermal.tz0._ACx: 3351 -1 -1 -1 -1 -1 -1 -1 -1 -1 Ok, this is fine, except that sometimes the first value isn't 3351. I have seen 3331 and 3341, too. Is that a big deal? And, how is this value set? Now, on to the problem. When I suspend the machine (S1), and then wake it back up again, the first value is changed to -1, just like the other nine values, yielding: hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 So, if I try to change the value back to 3331, I find out that this is a read-only oid. I found that I can get the value restored by disconnecting the AC power (putting the machine in 'economy' mode) and then restoring the AC power (putting the maching back into 'performance' mode). I turned on verbose ACPI logging and here is what I see in the message log: acpi_tz0: _AC9: temperature 61.9 >= setpoint -273.-2 acpi_tz0: _AC8: temperature 61.9 >= setpoint -273.-2 acpi_tz0: _AC7: temperature 61.9 >= setpoint -273.-2 acpi_tz0: _AC6: temperature 61.9 >= setpoint -273.-2 acpi_tz0: _AC5: temperature 61.9 >= setpoint -273.-2 acpi_tz0: _AC4: temperature 61.9 >= setpoint -273.-2 acpi_tz0: _AC3: temperature 61.9 >= setpoint -273.-2 acpi_tz0: _AC2: temperature 61.9 >= setpoint -273.-2 acpi_tz0: _AC1: temperature 61.9 >= setpoint -273.-2 acpi_tz0: _AC0: temperature 61.9 >= setpoint -273.-2 acpi_tz0: switched from NONE to _AC0: 61.9C acpi_tz0: WARNING - current temperature (61.9C) exceeds system limits acpi_tz0: _AC0: temperature 62.9 >= setpoint 61.9 acpi_tz0: switched from NONE to _AC0: 62.9C acpi_tz0: switched from _AC0 to NONE: 59.9C acpi_tz0: _AC0: temperature 61.9 >= setpoint 61.9 acpi_tz0: switched from NONE to _AC0: 61.9C acpi_tz0: switched from _AC0 to NONE: 55.9C Do I have anything to fear in the -1 value that replaces the 3351 when waking up from suspend? I have searched high and low and found very little information. Thanks in advance for your replies, they are much appreciated. -- +-+--+ | Michael W. Oliver, CCNP | "The tree of liberty must be | | IPv6 & FreeBSD mark | refreshed from time to time | | [EMAIL PROTECTED]| with the blood of patriots | | http://michael.gargantuan.com/| and tyrants."| | ASpath-tree, Looking Glass, etc. | - President Thomas Jefferson | | +--+ | gpg key - http://michael.gargantuan.com/gnupg/pubkey.asc | ++ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
adduser : typo in variable name
>Submitter-Id: current-users
>Originator:Kostyuk Oleg
>Organization:
>Confidential: no
>Synopsis: adduser : typo in variable name
>Severity: non-critical
>Priority: low
>Category: bin
>Class: update
>Release: FreeBSD 5.1-RELEASE i386
>Environment:
System: FreeBSD demani.digma 5.1-RELEASE FreeBSD 5.1-RELEASE #3: Mon Jun 9 12:19:59
EEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/CUB i386
>Description:
Typo in variable name
>How-To-Repeat:
See in source, line 781
# $FreeBSD: src/usr.sbin/adduser/adduser.sh,v 1.15 2003/03/23 23:06:44 mtm Exp
$
>Fix:
Patch
--- /usr/src/usr.sbin/adduser/adduser.shMon Mar 24 01:06:44 2003
+++ adduser.sh Tue Jun 24 16:31:37 2003
@@ -778,7 +778,7 @@
savedpwtype=
defaultclass=
defaultLgroup=
-defaultgoups=
+defaultgroups=
defaultshell="${DEFAULTSHELL}"
# Make sure the user running this program is root. This isn't a security
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
optreset undeclared
Hi, am I the only one having this problem while building world: cc -I/usr/local/include -march=athlon-tbird -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DHESIOD -c /usr/src/lib/libc/stdlib/getopt_long.c -o getopt_long.o /usr/src/lib/libc/stdlib/getopt_long.c: In function `getopt_internal': /usr/src/lib/libc/stdlib/getopt_long.c:205: `optreset' undeclared (first use in this function) /usr/src/lib/libc/stdlib/getopt_long.c:205: (Each undeclared identifier is reported only once /usr/src/lib/libc/stdlib/getopt_long.c:205: for each function it appears in.) It seems like line 72 of getopt_long.c should read #elif !HAVE_CONFIG_H && !HAVE_DECL_OPTRESET instead of #elif HAVE_CONFIG_H && !HAVE_DECL_OPTRESET I cannot make buildworld for days now because of this error. Any suggestions? Thanks. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ReiserFS
On Sun, Jun 22, 2003 at 07:00:26PM +0200, Brad Knowles wrote: > What if it's the same machine? What if they have only the one > machine, so they can't even copy it over to another one, just to > copy it back? What about using a FAT32 exchange partition? On the same disk or on a new one, depending of the size of the data to be moved. And (as the very last resource) you can upload a dump somewhere on internet and then download from the FreeBSD system (or even send it uuencoded by mail :-) -- Riccardo. ( http://www.GUFI.org/~vic/ ) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildproblem
On Tue, Jun 24, 2003 at 01:37:07PM +0200, Willem Jan Withagen wrote: > Hi, > > For some time now I have not been able to buildworld. > It always cramps on: > ===> lib/libpam/modules/pam_krb5 > rm -f .depend > mkdep -f > pend -a-I/usr/src5/src/lib/libpam/modules/pam_krb5/../../../../contrib/o > penpam/include -I/usr/src5/src/lib/libpam/modules/pam_krb5/../../libpam > /usr/src5/src/lib/libpam/modules/pam_krb5/pam_krb5.c > > /usr/src5/src/lib/libpam/modules/pam_krb5/pam_krb5.c:64:18: krb5.h: No such > file or directory > > I've removed the whole tree, re-cvsupped with src-all, removed make.conf, > > but no krb5.h to be found on my system. /usr/src/crypto/heimdal/lib/krb5/krb5.h Kris pgp0.pgp Description: PGP signature
Re: matcd rises from the ashes!
On Tue, Jun 24, 2003 at 08:31:44AM -0400, Paul Mather wrote: > licensing problems have been fixed. (I notice the original 10-point > license has shrunk to only 3 in the latest version.) So, could we > please (pretty please) have matcd also magically reappear in 4-STABLE? Frank Durda is back, and has re-written the driver to work in 5.x > nice (but not essential) if I could upgrade it to 4.8-STABLE so it was > at the same level as my other FreeBSD 4 box. (I notice from the edit > history in matcd.c that the original author of the driver is actively > developing it for FreeBSD 5, so maybe he could MFC his license changes > [re: edit <40> in the change log] back to 4-STABLE??) I don't know what his plans are for 4.x, why not ask him directly? -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: where is rogue?
Tilman Linneweh writes: > BTW, there are some open PRs regarding the freebsd-games. Currently they are > all assigned to freebsd-ports-bugs.=20 > > Does anyone volunteer to handle these, or are there plans to put the games > sources in a CVS somewhere (projects repository?).=20 The port carries a copy of the repository with it. Anyone may fix this port, I'm not holding a lock. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildproblem
On Tuesday 24 June 2003 04:37 am, Willem Jan Withagen wrote: > Hi, > > For some time now I have not been able to buildworld. > It always cramps on: > ===> lib/libpam/modules/pam_krb5 > rm -f .depend > mkdep -f > pend -a > -I/usr/src5/src/lib/libpam/modules/pam_krb5/../../../../contrib/o > penpam/include -I/usr/src5/src/lib/libpam/modules/pam_krb5/../../libpam > /usr/src5/src/lib/libpam/modules/pam_krb5/pam_krb5.c > > /usr/src5/src/lib/libpam/modules/pam_krb5/pam_krb5.c:64:18: krb5.h: No such > file or directory > > I've removed the whole tree, re-cvsupped with src-all, removed make.conf, > > but no krb5.h to be found on my system. > > Any suggestions?? > I just finished cvsuping and updating my system. I didn't have any problem. So, I have to assume that you did something different. I cvsup src-all, and I don't have any "don't builds" in my /etc/make.conf. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Buildproblem
Hi, For some time now I have not been able to buildworld. It always cramps on: ===> lib/libpam/modules/pam_krb5 rm -f .depend mkdep -f pend -a-I/usr/src5/src/lib/libpam/modules/pam_krb5/../../../../contrib/o penpam/include -I/usr/src5/src/lib/libpam/modules/pam_krb5/../../libpam /usr/src5/src/lib/libpam/modules/pam_krb5/pam_krb5.c /usr/src5/src/lib/libpam/modules/pam_krb5/pam_krb5.c:64:18: krb5.h: No such file or directory I've removed the whole tree, re-cvsupped with src-all, removed make.conf, but no krb5.h to be found on my system. Any suggestions?? --WjW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-06-24 09:45:12 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-24 09:45:12 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-24 09:47:50 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-06-24 10:40:01 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Jun 24 10:40:02 GMT 2003 >>> Kernel build for GENERIC completed on Tue Jun 24 10:49:01 GMT 2003 TB --- 2003-06-24 10:49:01 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-24 10:49:01 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 24 10:49:01 GMT 2003 [...] touch opt_quota.h touch opt_suiddir.h awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/dev -I@/../include -I/tmp/usr/include /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_alloc.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_balloc.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_bmap.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_ihash.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_inode.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_inode_cnv.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_linux_balloc.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_linux_ialloc.c /vol/! vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_lookup.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_subr.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_vfsops.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_vnops.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/gnu/ext2fs/ext2_linux_balloc.c:50:2: #error Provide a bitops.h file, please! /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/gnu/ext2fs/ext2_linux_ialloc.c:52:2: #error please provide bit operation functions mkdep: compile failed *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/ext2fs. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-24 10:50:53 - /usr/bin/make returned exit code 1 TB --- 2003-06-24 10:50:53 - ERROR: failed to build lint kernel TB --- 2003-06-24 10:50:53 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi patch for dell laptop?
On Mon, 23 Jun 2003, Scott Lambert wrote: > On Mon, Jun 23, 2003 at 10:38:26AM -1000, Vincent Poy wrote: > > Speaking about ACPI, has anyone figured out how to close the lid > > without suspending? I remember before, when the lid was closed, it would > > suspend even with sysctl set to not suspend and the screen stays on and > > when you resume, you can type but the screen freezes and doesn't update. > > Setting hw.acpi.lid_switch_state=NONE in /etc/sysctl.conf keeps my > Toshiba from suspending on lid close. Is that the sysctl you are > referring to as not working? Yep, on my IBM ThinkPad 770Z and A31P, sysctl -w hw.acpi.lid_switch_state=NONE works fine but on the Dell Inspiron 8200, it doesn't work at all. The screen doesn't turn off and the machine suspends and then when you resume the machine, the screen appears to not update but the commands you type on the keyboard still make it. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] [EMAIL PROTECTED] - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
