Re: ``Resource temporarily unavailable'' in vi
Mikhail Teterin writes: > Every once in a while, a vi-session dies on me with: > > input: Resource temporarily unavailable > > What does it mean, why does it happen, and how can I prevent it? > > Thanks a lot! > > -mi > > P.S. Running recent -current. I'm seeing this on current. I use bash, and the machine is not loaded. The heaviest process is spamassassin. There isn't even X running on the box. 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: buildkernel error with -CURRENT on moby with newly gcc 3.3.1
Jens Rehsack wrote:
> Hi,
>
> I tried to update a machine which will become a webserver in
> near future. I received following error in buildkernel:
>
> [...]
>
> cc -c -O -pipe -march=pentium4 -Wall \
> -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
> -Wmissing-prototypes -Wpointer-arith -Winline \
> -Wcast-qual-fformat-extensions -std=c99 -nostdinc \
> -I- -I. -I/usr/src/sys -I/usr/src/sys/dev \
> -I/usr/src/sys/contrib/dev/acpica \
> -I/usr/src/sys/contrib/ipfilter \
> -I/usr/src/sys/contrib/dev/ath \
> -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL \
> -include opt_global.h -fno-common \
> -mno-align-long-strings \
> -mpreferred-stack-boundary=2 -ffreestanding \
> /usr/src/sys/dev/ata/ata-all.c
> {standard input}: Assembler messages:
> {standard input}:7652: Error: invalid character '_' in mnemonic
> *** Error code 1
>
> Stop in /usr/obj/usr/src/sys/MOBY.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
I made some research (as good as I could) and found out/assumed sth.:
1) #APP and #NO_APP will be placed by cc around inline assembly
and forces the assembler to reformat spaces as required to parse
code well.
2) in /usr/obj/usr/src/sys/MOBY/ata-all.s (generated by cc -S)
are 209 #APP/#NO_APP pairs are used, but only above described
one fails.
3) in theory, the error described by me couldn't happen
4) the asm instruction lock ; x ; causes the processor to lock the
execution of instruction x.
b) lock ; x ; y ; cause the processor to lock x and executes y normal
c) "lock ; x ; y ;" could be written as "lock\n\tx\n\t\y\n\t" with
same generated binary code
5) if in /usr/src/sys/i386/include/atomic.h the line
" movzbl %%al,%0 ; "
is changed into
" movzbl %%al,%0\n\t" ,
the ata-all.c is compiled without any warning.
Regards,
Jens
--
L i W W W i Jens Rehsack
LW W W
L i W W W W i nnnLiWing IT-Services
L iW W W Wi n n g g
i W W i n n g gFriesenstraße 2
06112 Halle
g
g g
Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: <[EMAIL PROTECTED]>
Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
buildkernel error with -CURRENT on moby with newly gcc 3.3.1
Hi,
I tried to update a machine which will become a webserver in
near future. I received following error in buildkernel:
[...]
cc -c -O -pipe -march=pentium4 -Wall \
-Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline \
-Wcast-qual-fformat-extensions -std=c99 -nostdinc \
-I- -I. -I/usr/src/sys -I/usr/src/sys/dev \
-I/usr/src/sys/contrib/dev/acpica \
-I/usr/src/sys/contrib/ipfilter \
-I/usr/src/sys/contrib/dev/ath \
-I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL \
-include opt_global.h -fno-common \
-mno-align-long-strings \
-mpreferred-stack-boundary=2 -ffreestanding \
/usr/src/sys/dev/ata/ata-all.c
{standard input}: Assembler messages:
{standard input}:7652: Error: invalid character '_' in mnemonic
*** Error code 1
Stop in /usr/obj/usr/src/sys/MOBY.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
The uname -a output is:
FreeBSD moby.helpers.liwing.de 5.1-CURRENT FreeBSD 5.1-CURRENT #0:
Mon Jul 14 11:11:54 GMT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MOBY i386
The lines around the location are:
ata_enclosure_status:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl$24, %esp
movl8(%ebp), %edi
movl$6, -16(%ebp)
testb $8, 20(%edi)
ds ; je .L2817
movl(%edi), %eax
movl$1, 4(%esp)
movl%eax, (%esp)
call*248(%eax)
movl(%edi), %ecx
movl$0, %eax
movl$128, %edx
#APP
lock ; cmpxchgl %edx,244(%ecx) ;
setz %al ; movzbl %al,%eax ; 1: #
atomic_cmpset_int
#NO_APP
testl %eax, %eax
jne .L2830
movl$0, %esi
movl$128, %ebx
.L2822:
The line 7652 is the "#NO_APP". I must blame myself and say, that I
don't know where #NO_APP stands for, so I don't have any idea where the
error comes from nor how it could be fixed.
The error doesn't appear compiling the file using -march=pentium3, where
the begin of "ata_enclosure_status" looks like:
ata_enclosure_status:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl$24, %esp
movl8(%ebp), %edi
movl$6, -16(%ebp)
testb $8, 20(%edi)
je .L2817
movl(%edi), %eax
movl$1, 4(%esp)
movl%eax, (%esp)
call*248(%eax)
movl(%edi), %ecx
movl$0, %eax
movl$128, %edx
#APP
lock ; cmpxchgl %edx,244(%ecx) ;
setz %al ; movzbl %al,%eax ; 1: #
atomic_cmpset_int
#NO_APP
testl %eax, %eax
jne .L2830
movl$0, %esi
movl$128, %ebx
.p2align 4,,15
.L2822:
Does anyone know what's going on here?
Regards,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overdone rescue cleaning as part of buildworld?
Gordon Tetlow wrote: Attached is the patch. It basically makes CRUNCH_PROGS into a per directory item and then only does a make obj on the per program directory. Tim Kientzle whined: Hmmm I do have a philosophical quibble ... Gordon Tetlow generously suggested: That could probably be solved with a bit of make-foo. I'll see if I can work that up. But I don't think it's going to be a huge priority. Don't bother. I was just whining. ;-) Realistically, the parallel build problem is the highest priority right now for /rescue. Your patch works. Let's commit it and move on. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on amd64/amd64
TB --- 2003-07-15 05:12:26 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-07-15 05:12:26 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-15 05:14:20 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> 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/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-07-15 06:13:13 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Building an up-to-date make(1) >>> Kernel build for GENERIC started on Tue Jul 15 06:13:13 GMT 2003 [...] dbdisply.o: In function `AcpiDbDisplayArguments': dbdisply.o(.text+0x544): undefined reference to `AcpiDmDisplayArguments' dbdisply.o: In function `AcpiDbDisplayResults': dbdisply.o(.text+0x5eb): undefined reference to `AcpiDmDisplayInternalObject' dbdisply.o: In function `AcpiDbDisplayResultObject': dbdisply.o(.text+0x76b): undefined reference to `AcpiDmDisplayInternalObject' dbdisply.o: In function `AcpiDbDisplayArgumentObject': dbdisply.o(.text+0x7b3): undefined reference to `AcpiDmDisplayInternalObject' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. TB --- 2003-07-15 06:18:17 - /usr/bin/make returned exit code 1 TB --- 2003-07-15 06:18:17 - ERROR: failed to build generic kernel TB --- 2003-07-15 06:18:17 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Process stats wrong under ULE
I'm seeing the following kind of behaviour under ULE on a UP machine (kernel updated earlier this evening). Notice that the total CPU% adds up to way more than 100%; indeed one single process is allegedly using more than 100% CPU, and (not clear from the top(1) output) the processes that are sleeping do not have their CPU% updated until the next time they run. Kris last pid: 707; load averages: 1.28, 1.02, 0.47 up 0+00:04:16 23:11:40 60 processes: 2 running, 57 sleeping, 1 stopped CPU states: 1.1% user, 97.3% nice, 0.5% system, 1.1% interrupt, 0.0% idle Mem: 62M Active, 42M Inact, 52M Wired, 1016K Cache, 73M Buf, 592M Free Swap: 256M Total, 256M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 570 dnetc139 20 1000K 804K RUN 2:27 100.78% 100.78% dnetc 420 root 1390 3492K 2444K select 0:01 39.06% 39.06% sshd 573 nobody 40 4676K 4204K sbwait 0:02 9.38% 9.38% perl 575 nobody 40 4676K 4204K sbwait 0:02 9.38% 9.38% perl 577 nobody 40 4676K 4204K sbwait 0:02 9.38% 9.38% perl 574 nobody 40 4676K 4204K sbwait 0:02 9.38% 9.38% perl 576 nobody 40 4676K 4204K sbwait 0:02 9.38% 9.38% perl 701 root 800 3744K 2440K STOP 0:01 5.47% 5.47% cvs 589 root 760 25552K 24952K select 0:08 4.69% 4.69% XFree86 705 kris 760 2312K 1620K RUN 0:01 3.91% 3.91% top 702 kris 200 1464K 1148K pause0:00 2.34% 2.34% tcsh 664 kris 200 1464K 1148K pause0:00 2.34% 2.34% tcsh 654 kris 200 1468K 1152K pause0:00 1.56% 1.56% tcsh 683 kris 200 1464K 1148K pause0:00 1.56% 1.56% tcsh 624 kris 760 5484K 4880K select 0:01 0.00% 0.00% xterm 614 kris 760 5928K 4492K select 0:01 0.00% 0.00% wmaker 572 nobody760 8596K 7900K select 0:01 0.00% 0.00% squid 663 kris 760 3700K 3036K select 0:00 0.00% 0.00% ssh 633 kris 80 2288K 1716K nanslp 0:00 0.00% 0.00% wmWeather 653 kris 760 2100K 1780K select 0:00 0.00% 0.00% screen 529 root 760 1216K 728K select 0:00 0.00% 0.00% moused 632 kris 80 2520K 1796K nanslp 0:00 0.00% 0.00% wmCalClock 257 root 760 1300K 860K select 0:00 0.00% 0.00% syslogd pgp0.pgp Description: PGP signature
Re: src/bin/ed/re.c: warning: declaration of `exp' shadows a globaldeclaration
On Tue, 15 Jul 2003, Jun Kuriyama wrote:
JK>
JK>With new gcc and -Wshadow, src/bin/ed/re.c shows this warning:
JK>
JK>cc -Wshadow -c re.c
JK>re.c: In function `get_compiled_pattern':
JK>re.c:44: warning: declaration of `exp' shadows a global declaration
JK>:0: warning: shadowed declaration is here
JK>
JK>It seems local variable exp is conflicted with exp(3) declaration. I
JK>don't know what name should be used...
I would call this a compiler bug. It shouldn't declare exp(3) when you
don't include math.h. As I understand the standard the names in math.h are
only reserved when you include math.h. I remember that an earlier version
of gcc had this bug, that was fixed then. Probably they unfixed it again.
What's the chance of getting this fixed?
harti
JK>
JK>
JK>Index: re.c
JK>===
JK>RCS file: /home/ncvs/src/bin/ed/re.c,v
JK>retrieving revision 1.19
JK>diff -u -r1.19 re.c
JK>--- re.c 30 Jun 2002 05:13:53 - 1.19
JK>+++ re.c 14 Jul 2003 23:42:41 -
JK>@@ -41,7 +41,7 @@
JK> pattern_t *
JK> get_compiled_pattern(void)
JK> {
JK>-static pattern_t *exp = NULL;
JK>+static pattern_t *expr = NULL;
JK> static char error[1024];
JK>
JK> char *exps;
JK>@@ -52,27 +52,27 @@
JK> errmsg = "invalid pattern delimiter";
JK> return NULL;
JK> } else if (delimiter == '\n' || *++ibufp == '\n' || *ibufp == delimiter) {
JK>-if (!exp)
JK>+if (!expr)
JK> errmsg = "no previous pattern";
JK>-return exp;
JK>+return expr;
JK> } else if ((exps = extract_pattern(delimiter)) == NULL)
JK> return NULL;
JK> /* buffer alloc'd && not reserved */
JK>-if (exp && !patlock)
JK>-regfree(exp);
JK>-else if ((exp = (pattern_t *) malloc(sizeof(pattern_t))) == NULL) {
JK>+if (expr && !patlock)
JK>+regfree(expr);
JK>+else if ((expr = (pattern_t *) malloc(sizeof(pattern_t))) == NULL) {
JK> fprintf(stderr, "%s\n", strerror(errno));
JK> errmsg = "out of memory";
JK> return NULL;
JK> }
JK> patlock = 0;
JK>-if ((n = regcomp(exp, exps, 0))) {
JK>-regerror(n, exp, error, sizeof error);
JK>+if ((n = regcomp(expr, exps, 0))) {
JK>+regerror(n, expr, error, sizeof error);
JK> errmsg = error;
JK>-free(exp);
JK>-return exp = NULL;
JK>+free(expr);
JK>+return expr = NULL;
JK> }
JK>-return exp;
JK>+return expr;
JK> }
JK>
JK>
JK>
JK>
JK>
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
More Broadcom BCM5705 updates
I have merged in some additional updates provided by Paul Saab: - Support the BCM5782 chip (5705 workalike, new PCI ID) - Increase firmware handshake timeout - Always check for GMII PHYs at PHY address 1 (required for some chips, doesn't hurt on the others) - Add ASIC rev numbers for 5705_A1, 5705_A2 and 5705_A3 There may be some additional performance tweaks needed, but this should get the device attached and working. As before, download the new code from: http://www.freebsd.org/~wpaul/Broadcom/5705 - Copy if_bge.c and if_bgereg.h to /sys/dev/bge - Copy miidevs and brgphy.c to /sys/dev/mii - Rebuild your kernel and/or if_bge.ko and miibus.ko modules -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Gcc compiling problems
On Tue, Jul 15, 2003 at 06:23:05AM +0200, Divacky Roman wrote: > I've just upgraded to -current and gcc cannot be compiled > here's whyI've just upgraded to -current and gcc cannot be compiled > here's why : Update and try again. Please monitor this list and the cvs commit logs if you plan to track -current. Kris pgp0.pgp Description: PGP signature
[-CURRENT tinderbox] failure on alpha/alpha
TB --- 2003-07-15 04:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-07-15 04:00:01 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-15 04:02:00 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> 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/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-07-15 05:05:56 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Building an up-to-date make(1) >>> Kernel build for GENERIC started on Tue Jul 15 05:05:57 GMT 2003 [...] cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -c __remlu.S building __reml.S from /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/alpha/divrem.m4 cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -c __reml.S sh /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/conf/newvers.sh GENERIC cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding vers.c linking kernel.debug kern_sig.o:/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/kern/kern_sig.c:1512: undefined reference to `thread_siginfo' kern_sig.o:/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/kern/kern_sig.c:1512: undefined reference to `thread_siginfo' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-07-15 05:12:25 - /usr/bin/make returned exit code 1 TB --- 2003-07-15 05:12:25 - ERROR: failed to build generic kernel TB --- 2003-07-15 05:12:25 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Gcc compiling problems
On Tue, 15 Jul 2003, Divacky Roman wrote: > I've just upgraded to -current and gcc cannot be compiled > here's whyI've just upgraded to -current and gcc cannot be compiled > here's why : Try removing /usr/obj/* and rebuild. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Trouble with ACPI and ASUS MB
On Mon, 14 Jul 2003, Scott Robbins wrote: > It didn't. For the heck of it, I then tried recompiling the kernel with > the device acpi put back in, despite the possible dangers, but it didn't > work either. kldstat shows that the acip module is loaded. The error > that I get is ACPI timed out. > > ACPI power-off failed - timeout > The operating system has halted > Press any key to reboot Is this the only time you have problems? If so, I'd count yourself awfully lucky. > Some googling has indicated that this problem might be confined to ASUS > boards, but I'm not sure. My IRC friend suggested that I post the > problem here and see if anyone had solutions. This isn't enough information. We'd also need to see the dmesg from the offending machine, with any and all ACPI error messages that may be printed. Using acpidump to extract the DSDT is also helpful in case someone asks for it. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: buildkernel fails on -CURRENT
Fixed! sorry. - Original Message - From: "Greg J." <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 15, 2003 10:55 AM Subject: buildkernel fails on -CURRENT > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Here's the error message... > > cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. > -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica > -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath > -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h > -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 > -ffreestanding vers.c > linking kernel > kern_sig.o: In function `trapsignal': > kern_sig.o(.text+0x2d44): undefined reference to `thread_siginfo' > kern_thread.o: In function `thread_signal_add': > kern_thread.o(.text+0x2d86): undefined reference to `thread_siginfo' > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/KADAFI. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.2 (FreeBSD) > > iQEVAwUBPxNtIsVlXGSZ3LVMAQLxjAf/UbCSxkcy/X9S2h0EMqwcFoOTlth9h5jj > sdbdq3GfcRNaoxpepaX8zbVKnhIP1f+FJMcmGvEIpwN2y6Jhg1S+dE4e+MRgjYYe > 8cK9VLzR18uQsX9OM4ttwauUNQZNFviZ9tZacRs6qs6L4a0fkc/+MmiW9iXVxeEi > awQ9jOPK/8olwhEI+UEAf2bsFDF9fNAKYu5IKNJ8m2zzlO4X//M9ejMoM5labfKi > C4rDzw3APYIsaowoHuwEyBLcYS0vmHvpLRUszFmTMocetOO0Y/U9PrzjAE3+6Bsq > Nw8Vi7obXY/1obBQQWX8K5cGg/0OAaeuRChixoMZ6XQg61RWmurn6A== > =Lrsj > -END PGP SIGNATURE- > ___ > [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]"
Gcc compiling problems
I've just upgraded to -current and gcc cannot be compiled
here's whyI've just upgraded to -current and gcc cannot be compiled
here's why :
contrib/gcc/ggc.h:
including non-existent file gtype-desc.h
contrib/gcc/bitmap.c:
including non-existent file gt-bitmap.h
gnu/usr.bin/cc/cc_tools/Makefile:
.for F in attr codes config flags constants
insn-$F.h: gen$F ${MD_FILE}
./gen$F ${MD_FILE} > insn-$F.h
GENSRCS+= insn-$F.h
.endfor
is trying to access non-existant files, there is no ./gen*
I couldn't get any further...
all this seems to be result of updating to gcc 3.3.1-pre
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: newbus questions
On Mon, 14 Jul 2003, Nate Lawson wrote: > 3. It appears bus_alloc_resource() takes a range of values. If I know the > exact value to use, I request it via "value, value" instead of "0, ~0". > Is this correct? It's correct if you really know the values, unlike "0, ~0". The maximum value for a resource is ULONG_MAX. This is also a magic value in conjunction with a value of 0 for the start of a resource and a value of 1 for the count (see the man page). ULONG_MAX can be spelled ~0ul to abbreviate and obfuscate the code a little. ULONG_MAX can't be spelled ~0, but this is what the man page description says to use for the magic value. ~0 is -1 on 2's complement machines and -0 on 1's complement machines. It just happens to become ULONG_MAX on some machines including 2's complement ones after bogus type conversions when it is passed to bus_alloc_resource. Most drivers use the bogus version of course. The examples in the man page are correct although the description isn't. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: newbus questions
On Mon, 14 Jul 2003, M. Warner Losh wrote: > Let's take a step back. What are you trying to do? I need to install a temporary EC handler before the namespace is evaluated. This is because various other ACPI routines will call the EC before acpi_ec_attach is called (just after sio1 attach on my laptop). The way to do this (according to the ACPI 2.0 spec and Linux code) is to read the ECDT and use its values for registers and the GPE bit until the proper attach routine is called. Here are the errors that are reported when acpica attempts to access the EC before it has been attached: acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00fdeb0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.FDC_._INI] (Node 0xc32e2020), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__._INI] (Node 0xc32d8160), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BAT0._STA] (Node 0xc32da960), AE_NOT_EXIST ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BAT0._STA] (Node 0xc32da960), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BAT1._STA] (Node 0xc32da7e0), AE_NOT_EXIST My current approach is to have a routine which is called early on (perhaps by the probe for acpi0 so it is before the $PIR enumeration). It finds the ECDT and sets up temporary mappings for the command and data registers. These registers are 8 bit IO ports (0x66 and 0x62 usually but the ECDT specifies these). I need to be able to call bus_alloc_resource() for those registers so that bus_space_read() can be used on them. So my questions basically are: 1. What's the most proper place to call the ECDT attach routine? (It's currently device_identify but that's not quite right). According to takawata-san, the best place now is acpi_attach(). That seems ok to me. 2. What's the most proper way to enable access to the command and data registers so early on, hopefully without bypassing newbus? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make release of CURRENT on 4.7 box
* Bruce Evans <[EMAIL PROTECTED]> [ Date: 2003-07-13 ]
[ w.r.t. Re: make release of CURRENT on 4.7 box ]
> On Sun, 13 Jul 2003, Tim Kientzle wrote:
>
> > Bruce Evans wrote:
> > > I think splitting it or making it exit after just setting variables
> > > in the userland case is the right fix. ...
> [it == newvers.sh]
> >
> > I think you're right, but don't see a very simple way to make that
> > work, especially given the surprising number of places
> > that newvers.sh is used.
>
> I think there aren't so many -- only kernel Makefiles and
> src/include/Makefile.
>
> There seems to be a simple way due to bitrot. $1 in newvers.sh is
> not set when newvers.sh is invoked from src/include/Makefile, but
> it seems to always be set when newvers.sh is invoked from kernel
> Makefiles, due to garbage in the latter. The garbage is now
> centralized in sys/conf/kern.post.mk:
>
> sh $S/conf/newvers.sh ${KERN_IDENT}
> ^
>
> This passes an unused variable to newvers.sh. Passing and use of
> this variable was removed in 4.4BSD-Lite1, but FreeBSD's kernel
> Makefiles are based on Net/2 and haven't caught up with this change
> yet, while FreeBSD's newvers.sh is based on the Lite1 so it has
> the change. This variable became needed again in newvers.sh last
> month, but it wasn't used; the make -V hack was used instead.
>
> Some relevant uses and non-uses of $1 in newvers.sh:
>
> %%%
> FreeBSD rev.1.1 (same as Net/2?)
> echo "char version[] = \"version: ${v} ($1) ${t}\";"
>
>
> FreeBSD-1.1.5:
> echo "const char version[] = \"${kernvers} ($1) #${v}: ${t}\\n [EMAIL
> PROTECTED]:${dir}\\n\";"
>
>
> 4.4BSD-Lite1:
> echo "char version[] = \"4.4BSD-Lite #${v}: ${t}\\n[EMAIL PROTECTED]:${d}\\n\";"
> >>vers.c
> [No $1's here or elsewhere in newvers.sh]
>
> -current:
> i=`make -V KERN_IDENT`
> ...
> char version[] = "${VERSION} #${v}: ${t}\\n[EMAIL PROTECTED]:${d}\\n";
> ...
> char kern_ident[] = "${i}";
> [No $1's here or elsewhere in newvers.sh, but I think $i is always the
> same as $1.]
> %%%
>
> So removing the make -V line and just using $1 should fix the main problem
> and the bitrot.
Go for it.
Thanx,
juli.
--
juli mallett. email: [EMAIL PROTECTED]; efnet: juli; aim: bsdflata;
i have lost my way home early - i don't care cause i won't stay there.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
buildkernel fails on -CURRENT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here's the error message... cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding vers.c linking kernel kern_sig.o: In function `trapsignal': kern_sig.o(.text+0x2d44): undefined reference to `thread_siginfo' kern_thread.o: In function `thread_signal_add': kern_thread.o(.text+0x2d86): undefined reference to `thread_siginfo' *** Error code 1 Stop in /usr/obj/usr/src/sys/KADAFI. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iQEVAwUBPxNtIsVlXGSZ3LVMAQLxjAf/UbCSxkcy/X9S2h0EMqwcFoOTlth9h5jj sdbdq3GfcRNaoxpepaX8zbVKnhIP1f+FJMcmGvEIpwN2y6Jhg1S+dE4e+MRgjYYe 8cK9VLzR18uQsX9OM4ttwauUNQZNFviZ9tZacRs6qs6L4a0fkc/+MmiW9iXVxeEi awQ9jOPK/8olwhEI+UEAf2bsFDF9fNAKYu5IKNJ8m2zzlO4X//M9ejMoM5labfKi C4rDzw3APYIsaowoHuwEyBLcYS0vmHvpLRUszFmTMocetOO0Y/U9PrzjAE3+6Bsq Nw8Vi7obXY/1obBQQWX8K5cGg/0OAaeuRChixoMZ6XQg61RWmurn6A== =Lrsj -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: newbus questions
In message: <[EMAIL PROTECTED]> Nate Lawson <[EMAIL PROTECTED]> writes: : I'm working on ECDT support for ACPI and ran into a couple newbus-related : questions. : : 1. I'm using the identify entry as a way to get called early on in the : boot process. However, this does not happen before $PIR evaluation. How : should I hook in a routine for pre-$PIR execution? You cannot with newbus. discovery of $PIR happens as part of the BIOS scans, of which pci bios is one. why do you need to do this? It seems like a very odd question. : 2. I need to call bus_alloc_resource() to get access to some io ports. : However, calling BUS_READ_IVAR in the identify routine gets a bad pointer : deref. So how do I get a handle to use for allocating the IO ports : (first arg of bus_alloc_resource)? You need a device and a parent device. If you do not have one, then you must get one. : 3. It appears bus_alloc_resource() takes a range of values. If I know the : exact value to use, I request it via "value, value" instead of "0, ~0". : Is this correct? Yes. However, typically the parent bus identifies these resources, and the child device swallows it. The child device typically has no say in the matter. However, the foo_identify routines can set what it thinks are the right addresses. : The framework for this code is in ec_identify() and ec_attach() in : sys/dev/acpica/acpi_ec.c. This really isn't a identify routine. You must hook into other things if you want to get access early. Let's take a step back. What are you trying to do? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: newbus questions
In message <[EMAIL PROTECTED]>, Nate Lawson wrote:
>I'm working on ECDT support for ACPI and ran into a couple newbus-related
>questions.
>
>1. I'm using the identify entry as a way to get called early on in the
>boot process. However, this does not happen before $PIR evaluation. How
>should I hook in a routine for pre-$PIR execution?
It may be called in
if (ACPI_FAILURE(status = AcpiInstallAddressSpaceHandler(ACPI_ROOT_OBJECT,
ACPI_ADR_SPACE_PCI_CONFIG,
ACPI_DEFAULT_HANDLER,
NULL, NULL))) {
device_printf(dev, "could not initialise PciConfig handler: %s\n", AcpiF
ormatException(status));
goto out;
at acpi_attach().
>2. I need to call bus_alloc_resource() to get access to some io ports.
>However, calling BUS_READ_IVAR in the identify routine gets a bad pointer
>deref. So how do I get a handle to use for allocating the IO ports
>(first arg of bus_alloc_resource)?
If you want to use IDENTIFY method, you have to imprement
'bus_driver_added' method on parent driver to initialize ivars in
device object.
>3. It appears bus_alloc_resource() takes a range of values. If I know the
>exact value to use, I request it via "value, value" instead of "0, ~0".
>Is this correct?
It is correct in that context. When parent driver enumlate device and
set the resorce for device, That is used for allocate 'default' resource.
>The framework for this code is in ec_identify() and ec_attach() in
>sys/dev/acpica/acpi_ec.c.
You may want to set up ACPI EC register space before ACPI name space is
probed. So I think it is possible to call the initialization routine
in acpi_attach() explicitly for the time being.
The generalized way is that we have to imprement simple ACPI table
parser other than DSDT that is used before ACPI-CA initialization.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
src/bin/ed/re.c: warning: declaration of `exp' shadows a globaldeclaration
With new gcc and -Wshadow, src/bin/ed/re.c shows this warning:
cc -Wshadow -c re.c
re.c: In function `get_compiled_pattern':
re.c:44: warning: declaration of `exp' shadows a global declaration
:0: warning: shadowed declaration is here
It seems local variable exp is conflicted with exp(3) declaration. I
don't know what name should be used...
Index: re.c
===
RCS file: /home/ncvs/src/bin/ed/re.c,v
retrieving revision 1.19
diff -u -r1.19 re.c
--- re.c30 Jun 2002 05:13:53 - 1.19
+++ re.c14 Jul 2003 23:42:41 -
@@ -41,7 +41,7 @@
pattern_t *
get_compiled_pattern(void)
{
- static pattern_t *exp = NULL;
+ static pattern_t *expr = NULL;
static char error[1024];
char *exps;
@@ -52,27 +52,27 @@
errmsg = "invalid pattern delimiter";
return NULL;
} else if (delimiter == '\n' || *++ibufp == '\n' || *ibufp == delimiter) {
- if (!exp)
+ if (!expr)
errmsg = "no previous pattern";
- return exp;
+ return expr;
} else if ((exps = extract_pattern(delimiter)) == NULL)
return NULL;
/* buffer alloc'd && not reserved */
- if (exp && !patlock)
- regfree(exp);
- else if ((exp = (pattern_t *) malloc(sizeof(pattern_t))) == NULL) {
+ if (expr && !patlock)
+ regfree(expr);
+ else if ((expr = (pattern_t *) malloc(sizeof(pattern_t))) == NULL) {
fprintf(stderr, "%s\n", strerror(errno));
errmsg = "out of memory";
return NULL;
}
patlock = 0;
- if ((n = regcomp(exp, exps, 0))) {
- regerror(n, exp, error, sizeof error);
+ if ((n = regcomp(expr, exps, 0))) {
+ regerror(n, expr, error, sizeof error);
errmsg = error;
- free(exp);
- return exp = NULL;
+ free(expr);
+ return expr = NULL;
}
- return exp;
+ return expr;
}
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: current iso snapshots
Howdy, My Thinkpads (i1200, TP600) work OK, but you can't use ACPI on them with the default DSDT. Press Space at the boot loader countdown, then issue: set hint.acpi.0.disabled=1 boot Your Thinkpad should then boot OK. AFAIK some newer functionality may be lost without ACPI support. If this works for you, then you want to add the following to /boot/loader.conf: hint.acpi.0.disabled=1 AFAICT getting ACPI working properly on a Thinkpad involves learning AML to modify the default DSDT to work correctly with acpica. I haven't got that far yet though. stinkpad - haven't heard that before. Appropriate term when trying to get 5.x running on them... Regards, Chris Knight Systems Administrator E-Easy Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.e-easy.com.au > -Original Message- > From: Andrew Thomson > Sent: Tuesday, 15 July 2003 10:31 > To: [EMAIL PROTECTED] > Subject: current iso snapshots > > > is there a definitive zone for snapshots of current?? > > i stumbled upon this but my local mirror doesn't have any.. > > lftp ntu.tw.freebsd.org:/FreeBSD/snapshots/i386/ISO-IMAGES> > > 5.1-RELEASE didn't like my stinkpad.. i'm ready to try anything!! ;) > > cheers, > > ajt. > > > ___ > [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]"
failed to set signal flags properly for ast()
I am getting dozens of these on my desktop machine since upgrading. Can someone please add some proper debugging information to this codepath so I can help to track them down? Kris pgp0.pgp Description: PGP signature
Re: compile error on moby with newly gcc 3.3.1
Jens Rehsack wrote:
Hi,
I tried to update a machine which will become a webserver in
near future. I received following error in buildkernel:
[...]
cc -c -O -pipe -march=pentium4 -Wall \
-Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline \
-Wcast-qual-fformat-extensions -std=c99 -nostdinc \
-I- -I. -I/usr/src/sys -I/usr/src/sys/dev \
-I/usr/src/sys/contrib/dev/acpica \
-I/usr/src/sys/contrib/ipfilter \
-I/usr/src/sys/contrib/dev/ath \
-I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL \
-include opt_global.h -fno-common \
-mno-align-long-strings \
-mpreferred-stack-boundary=2 -ffreestanding \
/usr/src/sys/dev/ata/ata-all.c
{standard input}: Assembler messages:
{standard input}:7652: Error: invalid character '_' in mnemonic
*** Error code 1
Stop in /usr/obj/usr/src/sys/MOBY.
*** Error code 1
Stop in /usr/src.
*** Error code 1
I made some research (as good as I could) and found out/assumed sth.:
1) #APP and #NO_APP will be placed by cc around inline assembly
and forces the assembler to reformat spaces as required to parse
code well.
2) in /usr/obj/usr/src/sys/MOBY/ata-all.s (generated by cc -S)
are 209 #APP/#NO_APP pairs are used, but only above described
one fails.
3) in theory, the error described by me couldn't happen
4) the asm instruction lock ; x ; causes the processor to lock the
execution of instruction x.
b) lock ; x ; y ; cause the processor to lock x and executes y normal
c) "lock ; x ; y ;" could be written as "lock\n\tx\n\t\y\n\t" with
same generated binary code
5) if in /usr/src/sys/i386/include/atomic.h the line
" movzbl %%al,%0 ; "
is changed into
" movzbl %%al,%0\n\t" ,
the ata-all.c is compiled without any warning.
Regards,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: current iso snapshots
On Tue, Jul 15, 2003 at 10:31:19AM +1000, Andrew Thomson wrote: > is there a definitive zone for snapshots of current?? http://snapshots.jp.freebsd.org/ -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
newbus questions
I'm working on ECDT support for ACPI and ran into a couple newbus-related questions. 1. I'm using the identify entry as a way to get called early on in the boot process. However, this does not happen before $PIR evaluation. How should I hook in a routine for pre-$PIR execution? 2. I need to call bus_alloc_resource() to get access to some io ports. However, calling BUS_READ_IVAR in the identify routine gets a bad pointer deref. So how do I get a handle to use for allocating the IO ports (first arg of bus_alloc_resource)? 3. It appears bus_alloc_resource() takes a range of values. If I know the exact value to use, I request it via "value, value" instead of "0, ~0". Is this correct? The framework for this code is in ec_identify() and ec_attach() in sys/dev/acpica/acpi_ec.c. Thanks, Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
current iso snapshots
is there a definitive zone for snapshots of current?? i stumbled upon this but my local mirror doesn't have any.. lftp ntu.tw.freebsd.org:/FreeBSD/snapshots/i386/ISO-IMAGES> 5.1-RELEASE didn't like my stinkpad.. i'm ready to try anything!! ;) cheers, ajt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Trouble with ACPI and ASUS MB
I installed 5.1 RELEASE on a box with an ASUS A7A266 motherboard. Not having done enough reading, I had put device apm in the kernel and added apmd_enable="YES" to /etc/rc.conf. The box wouldn't turn off in response to shutdown -p. I then looked through NOTES and added device acpi, which fixed the problem. However, on IRC, someone with far more knowledge than myself mentioned that this could be dangerous. As it is a test box, he asked that I cvsup CURRENT and see if adding acpi_load="YES" to /boot/loader.conf (and removing the apm stuff, as well as the device acpi) would fix the problem. It didn't. For the heck of it, I then tried recompiling the kernel with the device acpi put back in, despite the possible dangers, but it didn't work either. kldstat shows that the acip module is loaded. The error that I get is ACPI timed out. ACPI power-off failed - timeout The operating system has halted Press any key to reboot uname -a shows 5.1-CURRENT FreeBSD 5.1-CURRENT #5: Tue Jul 15 00:23 :/usr/src/sys/i386/compile/SRKERN Some googling has indicated that this problem might be confined to ASUS boards, but I'm not sure. My IRC friend suggested that I post the problem here and see if anyone had solutions. Hopefully, I have given enough information--if not, please let me know. In a nutshell, on RELEASE it would work if I included device acpi in the kernel, but this doesn't work in CURRENT. Please cc me as I'm not on this list. Thank you very much for any help you can give--or at least point me in the right direction to solve the issue. Most sincerely, -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Cordelia: Hi! You having fun? Angel: Sure. This is, uh... Cordelia: Your idea of hell. Angel: Actually, in hell you tend to know a lot of the people pgp0.pgp Description: PGP signature
Re: ``Resource temporarily unavailable'' in vi
On Tue, Jul 15, 2003 at 12:43:40AM +0200, Matthias Buelow wrote: > Mikhail Teterin writes: > > >Every once in a while, a vi-session dies on me with: > > > > input: Resource temporarily unavailable > > Are you running ksh93 per chance? I've seen this after I started an > OpenGL program such as xscreensaver-demo from ksh93 (however that > could have influenced the terminal settings or whatever is beyond my > current understanding.) I've seen this intermittently on both -CURRENT and with 4.7; whatever causes it seems to corrupt the state of the tty, as the only thing that seems to reset is entering/exiting gdb. I use ksh93. Andrew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ``Resource temporarily unavailable'' in vi
=>Every once in a while, a vi-session dies on me with: => => input: Resource temporarily unavailable =Are you running ksh93 per chance? I've seen this after I started an =OpenGL program such as xscreensaver-demo from ksh93 (however that =could have influenced the terminal settings or whatever is beyond my =current understanding.) I don't use ksh, but it does, indeed, happen when the machine is under heavy use (compiles and what-not -- xscreensaver-demo would, probably, qualify too). -mi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ``Resource temporarily unavailable'' in vi
- Original Message - From: "Matthias Buelow" <[EMAIL PROTECTED]> To: "Mikhail Teterin" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, July 14, 2003 3:43 PM Subject: Re: ``Resource temporarily unavailable'' in vi > Mikhail Teterin writes: > > >Every once in a while, a vi-session dies on me with: > > > > input: Resource temporarily unavailable > > Are you running ksh93 per chance? I've seen this after I started an > OpenGL program such as xscreensaver-demo from ksh93 (however that > could have influenced the terminal settings or whatever is beyond my > current understanding.) I am running ksh93 and have seen this, too, although not often and not recently (in the past month) on 4-stable. Joshua ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ivar changes in newbus?
This is a complaint from the new compiler. That's what changed. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overdone rescue cleaning as part of buildworld?
On Mon, Jul 14, 2003 at 03:48:33PM -0700, Tim Kientzle wrote:
> Gordon Tetlow wrote:
> >Attached is the patch. It basically makes CRUNCH_PROGS into a per
> >directory item and then only does a make obj on the per program
> >directory.
>
> Hmmm I do have a philosophical quibble with your
> approach: My original intent for this Makefile was
> that the top part was rescue-specific and the bottom
> part would be sufficiently generic to be used in other
> crunchgen-based projects.
>
> Your patches embed a certain amount of /rescue-specific knowledge
> into the generic portion of the Makefile. For example,
> >+cd $(.CURDIR)/../../${D}/${P}
> makes a prett strong assumption about the relative
> locations of the crunchgen-using source directory
> and its components.
That could probably be solved with a bit of make-foo. I'll see if I
can work that up. But I don't think it's going to be a huge priority.
-gordon
pgp0.pgp
Description: PGP signature
Re: Overdone rescue cleaning as part of buildworld?
Gordon Tetlow wrote:
Attached is the patch. It basically makes CRUNCH_PROGS into a per
directory item and then only does a make obj on the per program
directory.
Hmmm I do have a philosophical quibble with your
approach: My original intent for this Makefile was
that the top part was rescue-specific and the bottom
part would be sufficiently generic to be used in other
crunchgen-based projects.
Your patches embed a certain amount of /rescue-specific knowledge
into the generic portion of the Makefile. For example,
+ cd $(.CURDIR)/../../${D}/${P}
makes a prett strong assumption about the relative
locations of the crunchgen-using source directory
and its components.
The advantage of your approach is that you are
making the subdirectory handling very tight.
Essentially, you are listing exactly the
subdirectories to be handled, where my approach
is a bit sloppier.
The advantage of my approach is that it is less
tied to the particulars of "building /rescue as
part of the FreeBSD source code."
But, this is only a philosophical objection, and no
doubt others will see it differently. As you seem
willing to be responsible for this code, you should do
it in a way that makes you comfortable.
In short, go for it.
Tim
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ``Resource temporarily unavailable'' in vi
Mikhail Teterin writes: >Every once in a while, a vi-session dies on me with: > > input: Resource temporarily unavailable Are you running ksh93 per chance? I've seen this after I started an OpenGL program such as xscreensaver-demo from ksh93 (however that could have influenced the terminal settings or whatever is beyond my current understanding.) -- Matthias Buelow; [EMAIL PROTECTED],informatik.uni-wuerzburg.de} ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ``Resource temporarily unavailable'' in vi
On Mon, Jul 14, 2003 at 06:08:32PM -0400, Mikhail Teterin wrote: > Every once in a while, a vi-session dies on me with: > > input: Resource temporarily unavailable > > What does it mean, why does it happen, and how can I prevent it? I suspect vi's not handling an EAGAIN error return. I get this on -stable when ripping a cd with grip/cdda2wav. Are you doing something that runs at very high priority when it happens? Judging from the comments in /usr/src/sys/errno.h, it could also be that there is a resource deadlock and vi is not translating the errno correctly. Anyway, pending a fix in vi to handle retryable errors, the workaround is not to do whatever it is that you're doing at the same time. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overdone rescue cleaning as part of buildworld?
On Mon, Jul 14, 2003 at 03:15:01PM -0700, Tim Kientzle wrote:
> Gordon Tetlow wrote:
> >On Mon, Jul 14, 2003 at 12:44:05PM -0700, Tim Kientzle wrote:
> >>Gordon Tetlow wrote:
> On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote:
> >It appears /rescue is cleaning for way too much as part of buildworld.
> >For instance, groff is NOT part of /rescue (or we have other things to
> >discuss. :) This adds a bit of time to buildworld, can it be removed?
>
> >>Yeah, I took a few shortcuts; /rescue does build far more in
> >>OBJDIR than it needs to, and similarly cleans much more than it needs
> >>to. (Those extra dirs are never populated, but building and cleaning
> >>them does still take time.) I believe the attached patch addresses
> >>this issue; it trims down /usr/obj/usr/src/rescue/rescue/usr/src/... to
> >>just the directories actually needed.
> >
> >This solution is kinda hackish, I have a more generic solution that makes
> >it easier to add programs without having to specifically add
> >CRUNCH_SRCDIR_foo to every program outside of src/bin and src/sbin. I'm
> >hoping to iron out the wrinkles today and post the patches. Other than
> >that the patch is pretty much complete.
>
> Great! Looking forward to it.
Attached is the patch. It basically makes CRUNCH_PROGS into a per
directory item and then only does a make obj on the per program
directory. I've incorporated the CRUNCH_SRCDIR_foo stuff you had
although I had come up with a similar solution.
It's lightly tested, some more eyes looking at it would be useful.
I'm currently running it through a buildworld.
-gordon
--- //depot/vendor/freebsd/src/rescue/rescue/Makefile 2003/07/11 10:38:05
+++ //depot/user/gordon/dynamic/src/rescue/rescue/Makefile 2003/07/14 13:04:49
@@ -1,4 +1,4 @@
-#$FreeBSD: src/rescue/rescue/Makefile,v 1.6 2003/07/11 16:57:43 gordon Exp $
+#$FreeBSD: src/rescue/rescue/Makefile,v 1.5 2003/06/30 21:13:56 gordon Exp $
# @(#)Makefile8.1 (Berkeley) 6/2/93
PROG= rescue
@@ -66,9 +66,9 @@
# WARNING: Changing this list may require adjusting
# /usr/include/paths.h as well! You were warned!
#
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../bin $(.CURDIR)/../../usr.bin
-CRUNCH_PROGS=cat chflags chio chmod cp date dd df domainname echo ed \
-expr getfacl hostname kenv kill ln ls mkdir mv pax ps pwd \
+CRUNCH_SRCDIRS+=bin
+CRUNCH_PROGS_bin=cat chflags chio chmod cp date dd df domainname echo \
+ed expr getfacl hostname kenv kill ln ls mkdir mv pax ps pwd \
realpath rm rmdir setfacl sh sleep stty sync test
CRUNCH_LIBS+=-lcrypt -lcrypto -ledit -lkvm -ll -lm -ltermcap -lutil
@@ -82,18 +82,18 @@
CRUNCH_ALIAS_ed= red
.if !defined(NO_RCMNDS)
-CRUNCH_PROGS+= rcp
+CRUNCH_PROGS_bin+= rcp
.endif
.if !defined(NO_TCSH)
-CRUNCH_PROGS+= csh
+CRUNCH_PROGS_bin+= csh
CRUNCH_ALIAS_csh= -csh tcsh -tcsh
CRUNCH_SUPPRESS_LINK_-csh=1
CRUNCH_SUPPRESS_LINK_-tcsh=1
.endif
#Is rmail of any use at all here? I think not.
-#CRUNCH_PROGS+= rmail
+#CRUNCH_PROGS_bin+= rmail
###
# Programs from standard /sbin
@@ -104,8 +104,8 @@
# Note that mdmfs and shutdown have their own private 'pathnames.h'
# headers in addition to the standard 'paths.h' header.
#
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../sbin
-CRUNCH_PROGS+=atm adjkerntz atacontrol badsect bsdlabel camcontrol \
+CRUNCH_SRCDIRS+=sbin
+CRUNCH_PROGS_sbin=atm adjkerntz atacontrol badsect bsdlabel camcontrol \
ccdconfig clri comcontrol conscontrol devfs dmesg dump \
dumpfs dumpon fore_dnld fsck fsck_ffs fsck_msdosfs fsdb \
fsirand gbde growfs ifconfig ilmid init ip6fw ipf ipfs ipfstat \
@@ -124,7 +124,7 @@
-lgeom -lmd -lreadline -lsbuf -lufs -lz
.if ${MACHINE_ARCH} == "i386"
-CRUNCH_PROGS+= cxconfig fdisk
+CRUNCH_PROGS_sbin+= cxconfig fdisk
CRUNCH_ALIAS_bsdlabel= disklabel
#CRUNCH_PROGS+= mount_nwfs mount_smbfs
#CRUNCH_LIBS+= -lncp -lsmb
@@ -135,11 +135,11 @@
.endif
.if ${MACHINE_ARCH} == "ia64"
-CRUNCH_PROGS+= mca gpt fdisk
+CRUNCH_PROGS_sbin+= mca gpt fdisk
.endif
.if ${MACHINE_ARCH} == "sparc64"
-CRUNCH_PROGS+= sunlabel
+CRUNCH_PROGS_sbin+= sunlabel
.endif
.if ${MACHINE_ARCH} == "alpha"
@@ -147,7 +147,7 @@
.endif
.if ${MACHINE_ARCH} == "amd64"
-CRUNCH_PROGS+= fdisk
+CRUNCH_PROGS_sbin+= fdisk
CRUNCH_ALIAS_bsdlabel= disklabel
.endif
@@ -162,26 +162,26 @@
CRUNCH_ALIAS_mount_std= mount_devfs mount_fdescfs mount_linprocfs mount_procfs
# dhclient has historically been troublesome...
-CRUNCH_PROGS+=dhclient
+CRUNCH_PROGS_sbin+=dhclient
CRUNCH_BUILDOPTS_dhclient=-DRELEASE_CRUNCH -Dlint
##
# Programs from stock /usr/bin
#
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../usr.bin
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../gnu/usr.bin
+CRUNCH_SRCDIRS+=usr.bin
+CRUNCH_SRCDIRS+=gnu/usr.bin
-CRUNCH_PROGS+=wall
+CRUNCH_PROGS_usr.bin+=wall
-C
Re: Overdone rescue cleaning as part of buildworld?
Gordon Tetlow wrote: On Mon, Jul 14, 2003 at 12:44:05PM -0700, Tim Kientzle wrote: Gordon Tetlow wrote: On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote: It appears /rescue is cleaning for way too much as part of buildworld. For instance, groff is NOT part of /rescue (or we have other things to discuss. :) This adds a bit of time to buildworld, can it be removed? Yeah, I took a few shortcuts; /rescue does build far more in OBJDIR than it needs to, and similarly cleans much more than it needs to. (Those extra dirs are never populated, but building and cleaning them does still take time.) I believe the attached patch addresses this issue; it trims down /usr/obj/usr/src/rescue/rescue/usr/src/... to just the directories actually needed. This solution is kinda hackish, I have a more generic solution that makes it easier to add programs without having to specifically add CRUNCH_SRCDIR_foo to every program outside of src/bin and src/sbin. I'm hoping to iron out the wrinkles today and post the patches. Other than that the patch is pretty much complete. Great! Looking forward to it. Do take a look, though at the edits near the end of that patch file. There are a couple of corrections there that actually complete the support for CRUNCH_SRCDIR_foo, and should be included even if you solve this particular problem in a more sophisticated way. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
``Resource temporarily unavailable'' in vi
Every once in a while, a vi-session dies on me with: input: Resource temporarily unavailable What does it mean, why does it happen, and how can I prevent it? Thanks a lot! -mi P.S. Running recent -current. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help diagnosing NIS breakage ?
> > > In our implementation, the NIS server is ActiveDirectory with > > > ServicesForUnix 3.0 :) > > > > Ok, first, shame on you for waiting until now to reveal this > > piece of information. (Although, I'm coming into this thread > > late, so if you mentioned it in a previous message and I > > wasn't able to find it, then I apologize. But if you didn't > > mention it, *THWAP*.) > > > > On a client bound to this server, please do: > > % ypwhich -m > > Thanks for getting back to me on this. First off, apologies if I'd failed to > mention the server before...Now, on a -CURRENT NIS client (with rev 1.81 > getpwent.c): > $ ypwhich -m > shadow dc3 > passwd.byuid dc3 [...] Ok, so it does support the YPPROC_MASTER procedure. Let's try something a little different. This time, do: % ypwhich -m master.passwd.byname And show the results. Might as well try ypwhich -m master.passwd.byuid too, though the result will probably be the same. > And to elaborate... [...] > > Shall I patch getpwent.c (rev 1.82) with your diff and see what happens ? If you could, please. Though I'm curious to know just what was causing the failure in the first place. Clearly YPPROC_MASTER on maps that exist seems to work (otherwise ypwhich would have complained like gangbusters), so maybe it's generating some sort of non-standard error on maps that don't exist. The fact that it fails for root means it must have something to do with probing for the master.passwd.by* maps, but I'm not sure what yet. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
compile error on moby with newly gcc 3.3.1
Hi,
I tried to update a machine which will become a webserver in
near future. I received following error in buildkernel:
[...]
cc -c -O -pipe -march=pentium4 -Wall \
-Wredundant-decls -Wnested-externs -Wstrict-prototypes \
-Wmissing-prototypes -Wpointer-arith -Winline \
-Wcast-qual-fformat-extensions -std=c99 -nostdinc \
-I- -I. -I/usr/src/sys -I/usr/src/sys/dev \
-I/usr/src/sys/contrib/dev/acpica \
-I/usr/src/sys/contrib/ipfilter \
-I/usr/src/sys/contrib/dev/ath \
-I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL \
-include opt_global.h -fno-common \
-mno-align-long-strings \
-mpreferred-stack-boundary=2 -ffreestanding \
/usr/src/sys/dev/ata/ata-all.c
{standard input}: Assembler messages:
{standard input}:7652: Error: invalid character '_' in mnemonic
*** Error code 1
Stop in /usr/obj/usr/src/sys/MOBY.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
The lines around the location are:
ata_enclosure_status:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl$24, %esp
movl8(%ebp), %edi
movl$6, -16(%ebp)
testb $8, 20(%edi)
ds ; je .L2817
movl(%edi), %eax
movl$1, 4(%esp)
movl%eax, (%esp)
call*248(%eax)
movl(%edi), %ecx
movl$0, %eax
movl$128, %edx
#APP
lock ; cmpxchgl %edx,244(%ecx) ;
setz %al ; movzbl %al,%eax ; 1: #
atomic_cmpset_int
#NO_APP
testl %eax, %eax
jne .L2830
movl$0, %esi
movl$128, %ebx
.L2822:
The line 7652 is the "#NO_APP". I must blame myself and say, that I
don't know where #NO_APP stands for, so I don't have any idea where the
error comes from nor how it could be fixed.
The error doesn't appear compiling the file using -march=pentium3, where
the begin of "ata_enclosure_status" looks like:
ata_enclosure_status:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl$24, %esp
movl8(%ebp), %edi
movl$6, -16(%ebp)
testb $8, 20(%edi)
je .L2817
movl(%edi), %eax
movl$1, 4(%esp)
movl%eax, (%esp)
call*248(%eax)
movl(%edi), %ecx
movl$0, %eax
movl$128, %edx
#APP
lock ; cmpxchgl %edx,244(%ecx) ;
setz %al ; movzbl %al,%eax ; 1: #
atomic_cmpset_int
#NO_APP
testl %eax, %eax
jne .L2830
movl$0, %esi
movl$128, %ebx
.p2align 4,,15
.L2822:
Does anyone know what's going on here?
Regards,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Broadcom NetXtreme BCM5705M support
Of all the gin joints in all the towns in all the world, Boris Georgiev had to walk into mine and say: > Kenneth, > > As I already posted William, I have bad news - it doesn't work for me. I > rebuilt kernel yesterday with > the patched sources and the only thing that happened is that the kernel > recognised the LAN card and > after that it tried to upload the firmware on the NIC chip, but > unsuccessfully. Uh First of all, the driver does not load any firmware into the chip. Second, you're not supposed to tell me your interpretation of what happened: you're supposed to cut&paste the messages into an e-mail so that I can see for myself what happened. Please show me all of the information that led you to your conclusion that this alleged firmware upload failed. > It gave me out > an timeout message and didn't load the driver at all. I am sorry that at > this time I cannot send > the exact message from the kernel, but the notbook is at my office, so I > will post it > tomorrow if the output will help for finding out what the problem is. > Best regards, Ok, note to all reading this: if I ask for information and you don't have the information available, don't bother sending me an e-mail just to tell me that you don't have the information available. Wait until you do have the information available, and then e-mail me. You'll save precious time and electrons. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Vim: Caught deadly signal BUS (after -current update with newgcc)
On Mon, Jul 14, 2003 at 10:38:44PM +0200, Thorsten Greiner wrote: > > > You can work around this by unsetting SESSION_MANAGER in your > > > environment. I have no idea what the root cause is... > > > > Where can I get rid of this variable ? I see no easy way. > > Currently I use gvim as default text editor within KDE > > environment ... > > > > In an xterm or such I could disable it, but how for KDE ?? > > As far as I understand it, this variable is set by the session management of the > respective desktop (KDE in your case, GNOME in mine). Maybe you can workaround the > problem by using a small shell script which unsets SESSION_MANAGER and than calls > gvim? Yes I will try to write a wrapper script around gvim. This way ... mv vim vim.bin cat > vim <<- EOF unset SESSION_MANAGER vim.bin EOF chmod 555 vim Andreas /// -- Andreas Klemm - Powered by FreeBSD 4.8-STABLE Need a magic printfilter today ? -> http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Vim: Caught deadly signal BUS (after -current update with newgcc)
> > You can work around this by unsetting SESSION_MANAGER in your > > environment. I have no idea what the root cause is... > > Where can I get rid of this variable ? I see no easy way. > Currently I use gvim as default text editor within KDE > environment ... > > In an xterm or such I could disable it, but how for KDE ?? As far as I understand it, this variable is set by the session management of the respective desktop (KDE in your case, GNOME in mine). Maybe you can workaround the problem by using a small shell script which unsets SESSION_MANAGER and than calls gvim? Regards -Thorsten Nur bei WEB.DE Testsieger FreeMail testen und damit 1 qm Regenwald schuetzen. Jetzt anmelden und mithelfen! http://user.web.de/Regenwald ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GCC 3.3.1, new warnings with
On Monday, July 14, 2003, at 01:33PM, Terry Lambert <[EMAIL PROTECTED]> wrote: >David Leimbach wrote: >> This is a good policy in general, however, one could easily argue that >> what is trying to be determined with signedness and such being >> less-than-compared >> to 0 isn't really a big deal and possibly the only way to implement this >> numeric_limits::digits thing without any type introspection which >> C++ currently >> lacks. >> >> The following would work for example in a template function: > >[ ... ] > True... but I don't think I was talking about a one-shot disabling of the message. I was thinking more about how a compliant C++ compiler can determine the signedness of a datatype without type introspection or type metadata available at compile time. [which seems to be what numeric_limits is all about doesn't it?] Dave >Gcc needs a #pragma to disable specific warnings as a one-shot. > >This was discussed in detail on the GCC mailing list. > >-- Terry > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re:
On Mon, Jul 14, 2003 at 09:51:25PM +0200, Thorsten Greiner wrote: > Andreas wrote: > > [EMAIL PROTECTED] ~ vim > > Vim: Caught deadly signal BUS > > Vim: Finished. > > Bus error (core dumped) > > You can work around this by unsetting SESSION_MANAGER in your > environment. I have no idea what the root cause is... Where can I get rid of this variable ? I see no easy way. Currently I use gvim as default text editor within KDE environment ... In an xterm or such I could disable it, but how for KDE ?? Andreas /// -- Andreas Klemm - Powered by FreeBSD 4.8-STABLE Need a magic printfilter today ? -> http://www.apsfilter.org/ ___ [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-07-14 18:42:18 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-07-14 18:42:18 - 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-07-14 18:44:34 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> 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 >>> stage 4: building everything.. TB --- 2003-07-14 19:44:57 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Building an up-to-date make(1) >>> Kernel build for GENERIC started on Mon Jul 14 19:44:57 GMT 2003 >>> Kernel build for GENERIC completed on Mon Jul 14 19:59:21 GMT 2003 TB --- 2003-07-14 19:59:21 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-14 19:59:21 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Building an up-to-date make(1) >>> Kernel build for LINT started on Mon Jul 14 19:59:22 GMT 2003 [...] dbdisply.o: In function `AcpiDbDisplayArguments': dbdisply.o(.text+0x69c): undefined reference to `AcpiDmDisplayArguments' dbdisply.o: In function `AcpiDbDisplayResults': dbdisply.o(.text+0x772): undefined reference to `AcpiDmDisplayInternalObject' dbdisply.o: In function `AcpiDbDisplayResultObject': dbdisply.o(.text+0x99c): undefined reference to `AcpiDmDisplayInternalObject' dbdisply.o: In function `AcpiDbDisplayArgumentObject': dbdisply.o(.text+0xa0c): undefined reference to `AcpiDmDisplayInternalObject' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** 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-07-14 20:11:51 - /usr/bin/make returned exit code 1 TB --- 2003-07-14 20:11:51 - ERROR: failed to build lint kernel TB --- 2003-07-14 20:11:51 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi not working
On Mon, 14 Jul 2003, David Hill wrote: > Hello - > My machine is a Dell Inspiron 2650 notebook. > > wind# kldstat > Id Refs AddressSize Name > 18 0xc010 3c4414 kernel > 21 0xc04c5000 4b440acpi.ko > 32 0xc28f9000 18000linux.ko > 41 0xc2914000 186000 nvidia.ko > wind# acpiconf -e > wind# acpiconf -d > wind# acpiconf -e I think at this point, you're on your own. I'm not sure ACPI can be repeatedly disabled and enabled: > acpi0: attempt to register more than one interrupt handler > ACPI-0210: *** Error: Unable to install System Control Interrupt Handler, > AE_ALREADY_EXISTS -d isn't removing the interrupt handler, which isn't suprising. Your system started up OK with ACPI so the answer to this will be: Don't do that. AE_REGION_LIMIT errors are almost always bugs in the DSDT. You can probably fix it yourself. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Belkin USB2serial F5U103
On Mon, 14 Jul 2003, Guenter Doerrhoefer wrote: > According to the release note the Belkin F5U103 should be supported. I > could not get it to operate, the device is recognized but cannot be > configured. Anyone got the Belkin to cooperate with 5.2-current? Heh, this reminded me to actually test the driver. It looks like there's an off-by-1 error in the speed setting code. With my Mac set to 38400, I have to set the -current box to 19200 in cu to get it to communicate properly. (This is testing with the F5U103 in my PC and my PowerBook with a Keyspan adapter, connected with a null modem cable. I run a terminal on both ends.) I'm debugging this and will report back shortly, unless the ubsa maintainers want to chip in. > Hint for programming: The port UCOMn mounted by the USBA-driver must > remain open after settings are made, otherwise the settings are lost > when port is closed. This is standard BSD serial device behavior. Annyoingly, ucom does not provide initial-setting devices and the like so you can't set a default. It would be a nice feature to add. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
freebsd-current@freebsd.org
Andreas wrote: > [EMAIL PROTECTED] ~ vim > Vim: Caught deadly signal BUS > Vim: Finished. > Bus error (core dumped) You can work around this by unsetting SESSION_MANAGER in your environment. I have no idea what the root cause is... Regards -Thorsten Nur bei WEB.DE Testsieger FreeMail testen und damit 1 qm Regenwald schuetzen. Jetzt anmelden und mithelfen! http://user.web.de/Regenwald ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overdone rescue cleaning as part of buildworld?
On Mon, Jul 14, 2003 at 12:44:05PM -0700, Tim Kientzle wrote: > Gordon Tetlow wrote: > >On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote: > >>On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote: > >>>It appears /rescue is cleaning for way too much as part of buildworld. > >>>For instance, groff is NOT part of /rescue (or we have other things to > >>>discuss. :) This adds a bit of time to buildworld, can it be removed? > > Yeah, I took a few shortcuts; /rescue does build far more in > OBJDIR than it needs to, and similarly cleans much more than it needs > to. (Those extra dirs are never populated, but building and cleaning > them does still take time.) I believe the attached patch addresses > this issue; it trims down /usr/obj/usr/src/rescue/rescue/usr/src/... to > just the directories actually needed. This solution is kinda hackish, I have a more generic solution that makes it easier to add programs without having to specifically add CRUNCH_SRCDIR_foo to every program outside of src/bin and src/sbin. I'm hoping to iron out the wrinkles today and post the patches. Other than that the patch is pretty much complete. -gordon pgp0.pgp Description: PGP signature
Re: Overdone rescue cleaning as part of buildworld?
Gordon Tetlow wrote:
On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote:
On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote:
It appears /rescue is cleaning for way too much as part of buildworld.
For instance, groff is NOT part of /rescue (or we have other things to
discuss. :) This adds a bit of time to buildworld, can it be removed?
Yeah, I took a few shortcuts; /rescue does build far more in
OBJDIR than it needs to, and similarly cleans much more than it needs
to. (Those extra dirs are never populated, but building and cleaning
them does still take time.) I believe the attached patch addresses
this issue; it trims down /usr/obj/usr/src/rescue/rescue/usr/src/... to
just the directories actually needed.
David's claim that /rescue is more than doubling the build time is
surprising, though. Compiling all of /bin and /sbin (which is more-or-less
what /rescue consists of) should not take more time than building the
entire system including /bin and /sbin. Perhaps something else is
going on here?
I've already started this process and I have some work in a local tree
to depessimize the build dramatically. Thank you for the reminder. Would
you be interested in taking a look at the patches?
Gordon,
I apologize that my shortcuts are causing you more work.
If you've already solved these problems, feel free to ignore
this and commit your work. On the other hand, since I _do_
understand how /rescue is built, I thought I might be able
to save you some effort by feeding you fixes for this.
I'm waiting on a buildworld with this patch to finish. I'll
let you know if anything goes awry, but I believe it works.
(Unfortunately, I _don't_ understand the parallel build
issue. I strongly suspect that it only impacts dhclient,
which has some rather unique build architecture. The
draconian solution would be to carve dhclient out of the
rescue crunchgen and build it separately, or just
statically link the official copy in /sbin and put
off the whole issue. I find both of these approaches
expedient but unsatisfying.)
Tim
Index: Makefile
===
RCS file: /usr/cvs/FreeBSD-CVS/src/rescue/rescue/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- Makefile30 Jun 2003 21:13:56 - 1.5
+++ Makefile14 Jul 2003 19:25:02 -
@@ -64,7 +64,7 @@
# WARNING: Changing this list may require adjusting
# /usr/include/paths.h as well! You were warned!
#
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../bin $(.CURDIR)/../../usr.bin
+CRUNCH_SRCDIRS+=$(.CURDIR)/../../bin
CRUNCH_PROGS=cat chflags chio chmod cp date dd df domainname echo ed \
expr getfacl hostname kenv kill ln ls mkdir mv pax ps pwd \
realpath rm rmdir setfacl sh sleep stty sync test
@@ -99,9 +99,6 @@
# WARNING: Changing this list may require adjusting
# /usr/include/paths.h as well! You were warned!
#
-# Note that mdmfs and shutdown have their own private 'pathnames.h'
-# headers in addition to the standard 'paths.h' header.
-#
CRUNCH_SRCDIRS+=$(.CURDIR)/../../sbin
CRUNCH_PROGS+=atm adjkerntz atacontrol badsect bsdlabel camcontrol \
ccdconfig clri comcontrol conscontrol devfs dmesg dump \
@@ -159,28 +156,32 @@
CRUNCH_ALIAS_fsck_ffs=fsck_4.2bsd fsck_ufs
CRUNCH_ALIAS_mount_std= mount_devfs mount_fdescfs mount_linprocfs mount_procfs
-# dhclient has historically been troublesome...
+# dhclient is troublesome...
CRUNCH_PROGS+=dhclient
CRUNCH_BUILDOPTS_dhclient=-DRELEASE_CRUNCH -Dlint
##
# Programs from stock /usr/bin
#
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../usr.bin
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../gnu/usr.bin
CRUNCH_PROGS+=wall
+CRUNCH_SRCDIR_wall+=$(.CURDIR)/../../usr.bin/wall
CRUNCH_PROGS+=gzip
+CRUNCH_SRCDIR_gzip+=$(.CURDIR)/../../gnu/usr.bin/gzip
CRUNCH_ALIAS_gzip=gunzip gzcat zcat
CRUNCH_PROGS+=bzip2
+CRUNCH_SRCDIR_bzip2+=$(.CURDIR)/../../usr.bin/bzip2
CRUNCH_ALIAS_bzip2=bunzip2 bzcat
CRUNCH_LIBS+=-lbz2
CRUNCH_PROGS+=tar
+CRUNCH_SRCDIR_tar+=$(.CURDIR)/../../gnu/usr.bin/tar
+
CRUNCH_PROGS+=vi
CRUNCH_ALIAS_vi=ex
+CRUNCH_SRCDIR_vi+=$(.CURDIR)/../../usr.bin/vi
##
# The following is pretty nearly a generic crunchgen-handling makefile
@@ -244,8 +245,6 @@
$(OUTPUTS): $(CONF)
MAKEOBJDIRPREFIX=${CRUNCHOBJS} crunchgen -q -m $(OUTMK) -c $(OUTC) $(CONF)
-# -m here forces make to treat the bsd.prog.mk and bsd.lib.mk in
-# this directory as overrides for the standard shared ones.
$(PROG): $(OUTPUTS)
MAKEOBJDIRPREFIX=${CRUNCHOBJS} make -f $(OUTMK)
@@ -260,14 +259,34 @@
.for D in $(CRUNCH_SRCDIRS)
cd ${D} && MAKEOBJDIRPREFIX=${CANONICALOBJDIR} make ${.TARGET}
.endfor
+.for P in $(CRUNCH_PROGS)
+.ifdef CRUNCH_SRCDIR_${P}
+ cd ${CRUNCH_SRCDIR_${P}} && \
+ MAKEOBJDIRPREFIX=${CANONICALOBJDIR} make ${.TARGET}
+.endif
+.endfor
clean:
Re: Vim: Caught deadly signal BUS (after -current update with newgcc)
On Mon, Jul 14, 2003 at 09:13:20PM +0200, Andreas Klemm wrote: > After -current update (with gcc version 3.3.1) and make world > vim gets bus error ... > > I will rebuild the world and report, if it makes a difference. > Same behaviour on comparable machines after compiler update ?? > > [EMAIL PROTECTED] ~ vim > Vim: Caught deadly signal BUS > Vim: Finished. > Bus error (core dumped) > [EMAIL PROTECTED] ~ > I have the same error (however without coredump) on a -current predating the new gcc import. The problem occurred today after a portupgrade to the newest gvim version. I just tried again, and am surprised to find that gvim works now, however on a remote X display. Tomorrow I'll restart the X server on that machine to see if it makes a difference on the local display. Karel. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
acpi not working
Hello - My machine is a Dell Inspiron 2650 notebook. wind# kldstat Id Refs AddressSize Name 18 0xc010 3c4414 kernel 21 0xc04c5000 4b440acpi.ko 32 0xc28f9000 18000linux.ko 41 0xc2914000 186000 nvidia.ko wind# acpiconf -e wind# acpiconf -d wind# acpiconf -e acpi0: attempt to register more than one interrupt handler ACPI-0210: *** Error: Unable to install System Control Interrupt Handler, AE_ALREADY_EXISTS ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPCB.ACAD._PSR] (Node 0xc25e7740), AE_AML_REGION_LIMIT ACPI-0438: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPCB.BAT1._BST] (Node 0xc25e95c0), AE_NO_HARDWARE_RESPONSE ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPCB.ACAD._PSR] (Node 0xc25e7740), AE_AML_REGION_LIMIT acpiconf: enable failed: Device not configured wind# wind# dmesg -a Copyright (c) 1992-2003 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.1-CURRENT #0: Mon Jul 14 12:28:47 EDT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/WIND Preloaded elf kernel "/boot/kernel/kernel" at 0xc0512000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc051226c. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1695005672 Hz CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz (1695.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febf9ff real memory = 267911168 (255 MB) avail memory = 254590976 (242 MB) Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fdf40 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_cpu0: port 0x530-0x537 on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 29 INTA is routed to irq 10 pcib0: slot 29 INTB is routed to irq 11 pcib0: slot 31 INTB is routed to irq 10 pcib0: slot 31 INTB is routed to irq 10 pcib0: slot 31 INTB is routed to irq 10 agp0: mem 0xec00-0xefff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib1: slot 0 INTA is routed to irq 10 pci1: at device 0.0 (no driver attached) uhci0: port 0x1800-0x181f irq 10 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Primax Electronics product 0x4d03, rev 1.00/4.41, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 pcib2: slot 1 INTA is routed to irq 10 pcib2: slot 4 INTA is routed to irq 10 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x3000-0x307f mem 0xe800-0xe87f irq 10 at device 1.0 on pci2 xl0: Ethernet address: 00:08:74:3f:d1:e3 miibus0: on xl0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto cbb0: irq 10 at device 4.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1840-0x184f,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0x1880-0x18bf,0x1c00-0x1cff irq 10 at device 31.5 on pci0 pcm0: pci0: at device 31.6 (no driver attached) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 acpi_acad0: on acpi0 acpi_ec0: port 0x66,0x62 on acpi0 acpi_cmbat0: on acpi0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 orm0: at iomem 0xdc000-0xd,0xce000-0xce7ff,0xc-0xcdfff on isa0 pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPCB.ACAD._PSR] (Node 0xc
Re: Overdone rescue cleaning as part of buildworld?
On Mon, Jul 14, 2003 at 01:53:29PM -0400, Garance A Drosihn wrote: > At 9:09 AM -0700 7/14/03, Gordon Tetlow wrote: > >On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote: > > > Gordon, 'make world' times have climbed up to over 1 hour > > > on a machine that used to do it in 25 minutes. Can you > > > please commit to understanding how /resuce is build and > >optimizing it before 5.2-RELEASE. > > > >I've already started this process and I have some work ... > > Btw, when I was doing a buildworld this weekend, I noticed > the following error in the section that builds /rescue. Has > anyone else noticed this? It may be easy to miss, because > 'make buildworld' does not abort at the error. The following > is some information I sent to Tim Kientzle <[EMAIL PROTECTED]> > early this morning, but I thought I'd send it to the list just > to see if anyone else has seen this problem. Perhaps it is > due to something at my end of things. > > For me, 'make buildworld' goes through: >===> rescue/rescue/dhcpctl >===> rescue/rescue/client >===> rescue/rescue/omshell > > successfully, and then while building: > ===> rescue/rescue/common > > Here is the last few lines I get: > > cc -O -pipe -mcpu=pentiumpro -DIN_GCC -DHAVE_CONFIG_H > -DPREFIX=\"/usr\" > -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools > -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config > -DHAVE_CONFIG_H -DTARGET_NAME=\"i386-undermydesk-freebsd\" -DIN_GCC > -c /usr/src/contrib/gcc/make-temp-file.c > make: don't know how to make > /usr/obj/usr/src/rescue/rescue//usr/src/sbin/dhclient/client/clparse.o. > Stop > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > > Now, after those Error's, make seems to go merrily along, and > makes bunch of other stuff. It looks like it even gets to the > end of the buildworld OK. However the way I do buildworld's > notices those '*** Error' lines, and it starts waving flags at > me. I am generally reluctant to ignore those flags... > > I did a bunch of cvsup's and cross-checks to make sure I had > the correct up-to-the-minute sources. I had also removed > all of /usr/obj/usr/src in case I had old cruft there (well, > actually I did that just because of the new gcc import...). > I rebuilt with -DNORESCUE and the buildworld finished OK. > > I am building with -j5 on a dual-processor Athlon system, if > that is significant. I am not doing any cross-build. I've heard some reports of this specifically with -j flag. I'll see if I can look at it once I finish depessimizing the build. -gordon pgp0.pgp Description: PGP signature
Re: GDB - do we dare?
Date: Sun, 13 Jul 2003 16:49:12 -0700 From: "David O'Brien" <[EMAIL PROTECTED]> On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote: >Date: Fri, 11 Jul 2003 15:50:02 -0700 >From: Marcel Moolenaar <[EMAIL PROTECTED]> > >Gang, > >With the gcc(1) dust not even settled yet, I like to get some feedback >on gdb(1). AFAICT, this is the deal: > >o Both ia64 and amd64 need gdb(1) support before they can become a > tier 1 platform. I think this implies upgrading to 5.3 the least. > > Upgrading to 5.3 for amd64 won't really help. While 5.3 included > support for amd64, I'm told it is seriously broken. Since then, I've > almost completely reworked GDB's amd64 target, to bring it in line > with the i386 target, and adapt it to some major architectural changes > in GDB. Based on that work, I've finished a FreeBSD/amd64 port > yesterday. I'll try to get it on GDB's 6.0 release branch. However, > backporting it to 5.3 would be a major PITA and IMHO a tremendous > waste of effort. Not sure about that. I wish you would touch base with SuSE. AMD has had SuSE do quite a lot of work to make GDB 5.3 very usable on AMD64. I know there are parts of the work SuSE has yet to send to the GDB lists. I am worried that FreeBSD's AMD64 bits will be too different from the Linux ones and FreeBSD won't be able to leverage the work AMD is paying SuSE to do. I'll ask Andreas about it. Rest assured that FreeBSD will benefit from all the work that's being done on AMD64 Linux. I'm working closely with both Andreas and Michal from SuSE to get their work integrated as soon as possible although I've let some of the patches they submitted slip through the cracks. However, FreeBSD/sparc64 isn't properly supported in FSF GDB either. When Jason Thorpe added NetBSD/sparc64 support he did it very NetBSD specific rather than do it in a more general BSD/sparc64 way that all the BSD's could leverage. Generalizing his bits is needed in the FSF GDB bits. I noticed, and have been working on this. Following Jason's track isn't too difficult, and things can be made more generic rather easily. I'll try to get my work integrated before the 6.0 release. Unfortunately, GDB's sparc target has been unmaintained for quite some time now. Because of architectural changes in GDB the code has become a big mess of deprecated interfaces, and is almost unmaintainable right now. I'll do my best to improve things but I can't guarantee that all problems will be fixed before the 6.0 release. > I'm not really familliar with the support for debugging FreeBSD > kernels in GDB since that support is not in the FSF tree. Is there > any chance that this code will be contributed back? Probably not, but I'd love it if you would take a look at it -- the times I've talked about to GDB guys hasn't been encouraging. How can we work to get the bits in /usr/src/gnu/usr.bin/binutils/gdb made part of stock FSF GDB (along with our diffs from the FSF vendor branch in /usr/src/contrib/gdb)? I've been snatching idea's from those places and incorporated them in the FSF sources already. For larger chunks of code the status of its copyright cleared up. Most of the code is definetly up to the standards, and could be integrated without major changes. I can do that. > This would involve a copyright assignment, which could prove to be a > major obstacle. We (I) can work to address this issue. Thanks. > A2 I'm volunteering to help out here. As the i386 target maintainer >and FreeBSD host/native maintainer, I seem to have sufficient >background in GDB I guess ;-). For almost two years now, I've been >using FreeBSD/i386 as my primary (development) platform, and I hope >at least some people have noticed that the upstream GDB works much >better on FreeBSD/i386 and FreeBSD/Alpha now. Now that I've got it >working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot. Others may hate me for this, but getting stock GDB working on sparc64 is of higher priority as it is a Tier-1 platform and we have more sparc64 users than ia64. Or maybe, you can help back me on the gdb-patches mailing list and I can revive Jake's and my patches for sparc64. I'll try to do that. As I said above, I've already been doing some work, and I think I've most of the FreeBSD-specific code fleshed out now (sharing things common with NetBSD). But if you find anything missing after I check things in, I'll try to back you, and approve patches myself if necessary. >releases, I'm dedicated to FreeBSD, and I'm certainly willing to do >work on integrating new versions of GDB into the FreeBSD tree. I'm more than willing to mentor you what it takes to do a GDB import into FreeBSD. Thanks! Mark ___ [EMAIL PROTECTED] mai
Vim: Caught deadly signal BUS (after -current update with new gcc)
After -current update (with gcc version 3.3.1) and make world vim gets bus error ... I will rebuild the world and report, if it makes a difference. Same behaviour on comparable machines after compiler update ?? [EMAIL PROTECTED] ~ vim Vim: Caught deadly signal BUS Vim: Finished. Bus error (core dumped) [EMAIL PROTECTED] ~ Andreas /// -- Andreas Klemm - Powered by FreeBSD 4.8-STABLE Need a magic printfilter today ? -> http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help diagnosing NIS breakage ?
> In our implementation, the NIS server is ActiveDirectory with ServicesForUnix > 3.0 :) Ok, first, shame on you for waiting until now to reveal this piece of information. (Although, I'm coming into this thread late, so if you mentioned it in a previous message and I wasn't able to find it, then I apologize. But if you didn't mention it, *THWAP*.) On a client bound to this server, please do: % ypwhich -m and show us the results. The ypwhich(8) utility will obtain a list of all the NIS maps being served by your server host and try to do a YPPROC_MASTER on each one to learn the name of its master server. It's possible that the Services For Unix implementation of NIS does not implement the YPPROC_MASTER procedure because the 'master' server in this case is CaptiveDirectory rather than an actual NIS master server (which means trying to do normal NIS master server things like yppasswd updates wouldn't work). If this is the case, then ypwhich should return an error for each map. I don't remember if ypwhich prints out the whole error status, but the expected underlying RPC error would be RPC_PROCUNAVAIL (procedure not available). This complicates matters a bit. When testing for the master.passwd maps, you can use the following logic: - If you call yp_order() on the master.passwd.byname map and the NIS server says YPERR_MAP (no such map), then you know that the server supports the YPPROC_ORDER procedure, but it doesn't have the master.passwd.byname map. So either it's not a FreeBSD server, or it is a FreeBSD server but the administrator has chosen not to serve the master.passwd maps. In either case, you should roll over to the normal passwd map lookup. - If you call yp_order() and get back YPERR_YPERR, that means there was an underlying RPC error (i.e. RPC_PROCUNAVAIL) which indicates the server doesn't support the YPPROC_ORDER procedure. The Sun NIS+ server in YP compat mode is one example of this. The FreeBSD ypserv does implement YPPROC_ORDER, so this error means you are not talking to a FreeBSD server, and again, you would roll over to the normal passwd map lookup. - When you get to the passwd map lookup, you probably shouldn't be attempting to do either a yp_master() or yp_order() poll on the map. You should just attempt a lookup. The yp_order() trick was something I introduced for the sole purpose of trying to determine if the server on the other end had master.passwd maps on it (i.e. it was a FreeBSD server). The nis_map() function in -current is analagous to the _havemaster() function in -stable, but _havemaster() was only meant to test for the master.passwd maps, whereas nis_map() checks master.passwd maps and then, if that fails, checks for passwd maps too. I don't think this is the correct approach: you should only attempt a yp_order() on the master.passwd.by* maps, and if that doesn't work, you let the nis_lookup() function do the yp_first()/yp_next()/yp_match() and return an error if necessary. I have a diff to do this at: http://www.freebsd.org/~wpaul/getpwent.diff > > I think this is exposing a bug in our NIS implementation, > > but don't know enough about it to be sure. I think backing it out > > just hides the bug again. As a work-around, we could try yp_order > > first, and if that fails, try yp_master. It's not a bug in our implementation, it's implementation weirdness in the server. :) -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Error building /rescue on -current
John-Mark Gurney wrote:
I happen to notice an interesting problem on my build.. (-j3 on a sparc64
box):
make: don't know how to make /usr/obj/usr/src/world/src/rescue/rescue//usr/src/w
orld/src/sbin/dhclient/client/clparse.o. Stop
*** Error code 2
notice the rescue//usr. I'm not sure what to make of it, but it seems
like this might confuse it. Also, why are we sticking obj files for rescue
in the source dir of the program? shouldn't they be in the rescue dir?
(so that they don't get globbered when the regular build happens.)
The // is a non-issue.
The obj files are going into ${.OBJDIR}. If they're
showing up in the source dir of the program, then
you haven't built the /usr/obj/usr/src/rescue directory
tree. You should either:
* define RESCUE during buildworld
* cd /usr/src/rescue && make obj
Tim Kientzle
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on amd64/amd64
TB --- 2003-07-14 17:34:02 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-07-14 17:34:02 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-14 17:37:16 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> 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/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-07-14 18:37:13 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Building an up-to-date make(1) >>> Kernel build for GENERIC started on Mon Jul 14 18:37:14 GMT 2003 [...] dbdisply.o: In function `AcpiDbDisplayArguments': dbdisply.o(.text+0x544): undefined reference to `AcpiDmDisplayArguments' dbdisply.o: In function `AcpiDbDisplayResults': dbdisply.o(.text+0x5eb): undefined reference to `AcpiDmDisplayInternalObject' dbdisply.o: In function `AcpiDbDisplayResultObject': dbdisply.o(.text+0x76b): undefined reference to `AcpiDmDisplayInternalObject' dbdisply.o: In function `AcpiDbDisplayArgumentObject': dbdisply.o(.text+0x7b3): undefined reference to `AcpiDmDisplayInternalObject' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. TB --- 2003-07-14 18:42:18 - /usr/bin/make returned exit code 1 TB --- 2003-07-14 18:42:18 - ERROR: failed to build generic kernel TB --- 2003-07-14 18:42:18 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GCC 3.3.1, new warnings with
David Leimbach wrote: > This is a good policy in general, however, one could easily argue that > what is trying to be determined with signedness and such being > less-than-compared > to 0 isn't really a big deal and possibly the only way to implement this > numeric_limits::digits thing without any type introspection which > C++ currently > lacks. > > The following would work for example in a template function: [ ... ] Gcc needs a #pragma to disable specific warnings as a one-shot. This was discussed in detail on the GCC mailing list. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help diagnosing NIS breakage ?
In our implementation, the NIS server is ActiveDirectory with ServicesForUnix 3.0 :) > -Original Message- > From: Daniel Eischen [mailto:[EMAIL PROTECTED] > Sent: Monday, July 14, 2003 2:13 PM > To: Robin P. Blanchard > Cc: John De Boskey; [EMAIL PROTECTED]; Jacques A. Vidrine > Subject: RE: Help diagnosing NIS breakage ? > > > On Mon, 14 Jul 2003, Robin P. Blanchard wrote: > > > That did it > > > > Using latest -CURRENT sources, but backing out to > > src/lib/libc/gen/getpwent.c,v 1.81 gets NIS clients working again. > > Re-sync this in CVS ? > > The change (rev 1.82) to getpwent.c allows FreeBSD NIS > clients to work with Solaris NIS+ servers running in YP > compatibility mode. Without the change, FreeBSD clients in > such an environment can't log in. > > I think this is exposing a bug in our NIS implementation, > but don't know enough about it to be sure. I think backing it out > just hides the bug again. As a work-around, we could try yp_order > first, and if that fails, try yp_master. > > -- > Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: acpica 0619 in the tree
On Mon, Jul 14, 2003 at 10:43:33AM -0700, Nate Lawson wrote: > > > > > > A fix has been tested and committed. > > > > dmobject.c has not been added to sys/conf/files.* > > Thanks, that has been committed. Thanks :-) -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Help diagnosing NIS breakage ?
On Mon, 14 Jul 2003, Robin P. Blanchard wrote: > That did it > > Using latest -CURRENT sources, but backing out to > src/lib/libc/gen/getpwent.c,v 1.81 gets NIS clients working again. Re-sync > this in CVS ? The change (rev 1.82) to getpwent.c allows FreeBSD NIS clients to work with Solaris NIS+ servers running in YP compatibility mode. Without the change, FreeBSD clients in such an environment can't log in. I think this is exposing a bug in our NIS implementation, but don't know enough about it to be sure. I think backing it out just hides the bug again. As a work-around, we could try yp_order first, and if that fails, try yp_master. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Help diagnosing NIS breakage ?
That did it Using latest -CURRENT sources, but backing out to src/lib/libc/gen/getpwent.c,v 1.81 gets NIS clients working again. Re-sync this in CVS ? Thanks everyone. --- Robin P. Blanchard Systems Integration Specialist Georgia Center for Continuing Education fon: 706.542.2404 <|> fax: 706.542.6546 --- > -Original Message- > From: Daniel Eischen [mailto:[EMAIL PROTECTED] > Sent: Monday, July 14, 2003 8:57 AM > To: Robin P. Blanchard > Cc: John De Boskey; [EMAIL PROTECTED]; Jacques A. Vidrine > Subject: RE: Help diagnosing NIS breakage ? > > > On Mon, 14 Jul 2003, Robin P. Blanchard wrote: > > > Ok...Been systematically stepping through the sources to locate the > > point at which NIS became broken. Here are the results: > > > > -CURRENT src date report > > --- --- > > 2003.06.18.00.00.00 success > > 2003.06.25.00.00.00 success > > 2003.06.26.00.00.00 success > > 2003.06.27.00.00.00 sucesss > > 2003.06.28.00.00.00 failure > > 2003.07.01.00.00.00 failure > > 2003.07.09.00.00.00 failure > > latest (last night) failure > > > > So, something between 27 and 28 June resulted in this NIS breakage. > > Hopefully this will jog someone's memory and give ideas as > to my/our > > next step as to diagnosing/repairing what's wrong here. I > have a test > > box with src's and obj 's from both 27 and 28 june availabe for > > testing, should someone like to ssh in and poke around. > > Try backing out rev 1.82 of src/lib/libc/gen/getpwent.c. > > If that works, then perhaps there is something wrong > with FreeBSD's yp_master (on server end). > > -- > Dan Eischen > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Error building /rescue on -current
Tim Kientzle wrote this message on Mon, Jul 14, 2003 at 10:50 -0700: > So far, every report of this problem has had these two > elements in common: > > * parallel builds > * dhclient/client/clparse.o > > I've tried tracing through the crunchgen-generated Makefile for > /rescue (/usr/obj/usr/src/rescue/rescue/rescue.mk) and the > dhclient makefile (/usr/src/sbin/dhclient/Makefile) and have yet > to come up with anything. (To be honest, I haven't even managed > to reproduce this problem.) Both of these makefiles are pretty > peculiar, and I had the devil of a time getting it to work correctly > for serial builds, so I shouldn't be surprised that it's causing > problems. > > Maybe someone who understands parallel make better than I do > could suggest something to look for? I happen to notice an interesting problem on my build.. (-j3 on a sparc64 box): make: don't know how to make /usr/obj/usr/src/world/src/rescue/rescue//usr/src/w orld/src/sbin/dhclient/client/clparse.o. Stop *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 notice the rescue//usr. I'm not sure what to make of it, but it seems like this might confuse it. Also, why are we sticking obj files for rescue in the source dir of the program? shouldn't they be in the rescue dir? (so that they don't get globbered when the regular build happens.) -- 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: Overdone rescue cleaning as part of buildworld?
At 9:09 AM -0700 7/14/03, Gordon Tetlow wrote: On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote: > Gordon, 'make world' times have climbed up to over 1 hour > on a machine that used to do it in 25 minutes. Can you > please commit to understanding how /resuce is build and optimizing it before 5.2-RELEASE. I've already started this process and I have some work ... Btw, when I was doing a buildworld this weekend, I noticed the following error in the section that builds /rescue. Has anyone else noticed this? It may be easy to miss, because 'make buildworld' does not abort at the error. The following is some information I sent to Tim Kientzle <[EMAIL PROTECTED]> early this morning, but I thought I'd send it to the list just to see if anyone else has seen this problem. Perhaps it is due to something at my end of things. For me, 'make buildworld' goes through: ===> rescue/rescue/dhcpctl ===> rescue/rescue/client ===> rescue/rescue/omshell successfully, and then while building: ===> rescue/rescue/common Here is the last few lines I get: cc -O -pipe -mcpu=pentiumpro -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DHAVE_CONFIG_H -DTARGET_NAME=\"i386-undermydesk-freebsd\" -DIN_GCC -c /usr/src/contrib/gcc/make-temp-file.c make: don't know how to make /usr/obj/usr/src/rescue/rescue//usr/src/sbin/dhclient/client/clparse.o. Stop *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 Now, after those Error's, make seems to go merrily along, and makes bunch of other stuff. It looks like it even gets to the end of the buildworld OK. However the way I do buildworld's notices those '*** Error' lines, and it starts waving flags at me. I am generally reluctant to ignore those flags... I did a bunch of cvsup's and cross-checks to make sure I had the correct up-to-the-minute sources. I had also removed all of /usr/obj/usr/src in case I had old cruft there (well, actually I did that just because of the new gcc import...). I rebuilt with -DNORESCUE and the buildworld finished OK. I am building with -j5 on a dual-processor Athlon system, if that is significant. I am not doing any cross-build. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Error building /rescue on -current
Garance A Drosihn wrote: Has anyone mentioned problems in buildworld in the building of the new /rescue directory? Yes, they have. make: don't know how to make /usr/obj/usr/src/rescue/rescue//usr/src/sbin/dhclient/client/clparse.o. Stop *** Error code 2 I am building with -j5 on a dual-processor i386 system, if that's significant. So far, every report of this problem has had these two elements in common: * parallel builds * dhclient/client/clparse.o I've tried tracing through the crunchgen-generated Makefile for /rescue (/usr/obj/usr/src/rescue/rescue/rescue.mk) and the dhclient makefile (/usr/src/sbin/dhclient/Makefile) and have yet to come up with anything. (To be honest, I haven't even managed to reproduce this problem.) Both of these makefiles are pretty peculiar, and I had the devil of a time getting it to work correctly for serial builds, so I shouldn't be surprised that it's causing problems. Maybe someone who understands parallel make better than I do could suggest something to look for? Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: acpica 0619 in the tree
On Mon, 14 Jul 2003, Marcel Moolenaar wrote: > On Mon, Jul 14, 2003 at 10:21:56AM -0700, Nate Lawson wrote: > > > The first thing to do is to add the new file dmobject.c to the debugging > > > section in the modules/acpi/Makefile. > > > However, there are some more hairy things that prevent it from simply just > > > working that I am looking into now. > > > > A fix has been tested and committed. > > dmobject.c has not been added to sys/conf/files.* Thanks, that has been committed. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
firewire problem on 5.1-RELEASE
Hi guys, there's some new bug in firewire driver in 5.1-RELASE. When I connect camera to ma Dell Precision 530 box via firewire I get following messages: fwohci0: BUS reset fwohci0: node_id=0x0800ffc0, gen=37, Bus reset failure fwohci0: node_id=0x8800ffc0, gen=77, non CYCLEMASTER mode fwohci0: SID Error fwohci0: phy int fwohci0: node_id=0x8800ffc0, gen=197, non CYCLEMASTER mode fwohci0: SID Error fwohci0: phy int fwohci0: node_id=0x8800ffc0, gen=61, non CYCLEMASTER mode fwohci0: SID Error fwohci0: phy int fwohci0: node_id=0x0800ffc0, gen=181, Bus reset failure fwohci0: phy int fwohci0: node_id=0x0800ffc0, gen=5, Bus reset failure fwohci0: phy int fwohci0: node_id=0x0800ffc0, gen=85, Bus reset failure fwohci0: phy int fwohci0: node_id=0x0800ffc0, gen=165, Bus reset failure fwohci0: phy int fwohci0: node_id=0x0800ffc0, gen=245, Bus reset failure fwohci0: phy int fwohci0: node_id=0x0800ffc0, gen=68, Bus reset failure fwohci0: phy int fwohci0: node_id=0x0800ffc0, gen=148, Bus reset failure fwohci0: phy int fwohci0: node_id=0x0800ffc0, gen=228, Bus reset failure fwohci0: phy int fwohci0: node_id=0x0800ffc0, gen=52, Bus reset failure fwohci0: phy int fwohci0: node_id=0x0800ffc0, gen=132, Bus reset failure fwohci0: phy int fwohci0: node_id=0xc800ffc0, gen=172, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) fwohci0: phy int fwohci0: BUS reset fwohci0: node_id=0x8800ffc0, gen=174, non CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 0 (me) firewire0: root node is not cycle master capable firewire0: bus manager 0 (me) fwohci0: BUS reset fwohci0: node_id=0x8800ffc0, gen=174, non CYCLEMASTER mode fw_xfer_done: pending firewire0: 2 nodes, maxhop <= 1, cable IRM = 0 (me) firewire0: root node is not cycle master capable firewire0: bus manager 0 (me) fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=175, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) fw_attach_dev: 1 pending handlers called fwohci0: BUS reset fwohci0: node_id=0x8800ffc0, gen=177, non CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 fwohci0: BUS reset fwohci0: node_id=0x8800ffc0, gen=177, non CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 firewire0: bus manager 0 (me) firewire0: New S100 device ID:8564790a After this when I try to read from camera I get following: fwohci0: IR DMA overrun (0x40008011) fwohci0: IR DMA overrun (0x40008011) fwohci0: IR DMA overrun (0x40008011) fwohci0: IR DMA overrun (0x40008011) Can anybody help me? It used to work in 5.0-RELEASE so I suppose it to be a new bug. Thanks, Petr PS: Keep me in Cc: of your answer since I'm not a list member and I won't be able to react promptly otherwise. P. Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZMasaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-541512213 fax: +420-541212747 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Making a disk bootable...
John-Mark Gurney wrote: > Ian Freislich wrote this message on Mon, Jul 14, 2003 at 18:48 +0200: > > I've just tried this dd'ing /dev/zero over the front of the disk > > first to no avail (the probed geometry is the geometry that fdisk > > used anyway). I also tried your much loved ficticious geometry of > > 255H 64S and that didn't work. It's a RPITA. In the end I dangerously > > dedicated the disk and that works. > > One thing you might of been missing is making sure that the type in > the disklabel was set properly. For scsi, it must be SCSI, and for > IDE it must be IDE or ESDI. I had problems with this too. I think all that stuff is no longer in the disklabel: [brane-dead] / # disklabel /dev/da0s1 # /dev/da0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 26214404.2BSD 1024 8192 32776 b: 1048576 262144 swap c: 9240unused0 0 # "raw" part, don't edit e: 2097152 13107204.2BSD 1024 8192 46248 f: 5481052 34078724.2BSD 1024 8192 46248 Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: acpica 0619 in the tree
On Mon, Jul 14, 2003 at 10:21:56AM -0700, Nate Lawson wrote: > > > > The first thing to do is to add the new file dmobject.c to the debugging > > section in the modules/acpi/Makefile. > > However, there are some more hairy things that prevent it from simply just > > working that I am looking into now. > > A fix has been tested and committed. dmobject.c has not been added to sys/conf/files.* -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: acpica 0619 in the tree
On Mon, 14 Jul 2003, Mark Santcroos wrote: > I wasn't able to test the update before it was committed, but it doesn't > have any runtime regressions for me so far, so that's good! Good. So far things look ok, no reports of new regression. > However, something I haven't seen reported before, is that it breaks for > the ACPI_DEBUG case. (Which I have in /etc/make.conf) > > The first thing to do is to add the new file dmobject.c to the debugging > section in the modules/acpi/Makefile. > However, there are some more hairy things that prevent it from simply just > working that I am looking into now. A fix has been tested and committed. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ivar changes in newbus?
I'm getting these warnings when building sys/modules/acpi: cc -O -pipe -mcpu=pentiumpro -I/home/src/sys/modules/acpi/../../contrib/dev/acpica -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I/home/src/sys/modules/acpi/../../contrib/dev/acpica -I. -I@ -I@/dev -I@/../include -I/usr/include -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /home/src/sys/modules/acpi/../../i386/acpica/acpi_wakeup.c bus_if.h:39: warning: inlining failed in call to `BUS_READ_IVAR' @/dev/acpica/acpivar.h:194: warning: called from here bus_if.h:50: warning: inlining failed in call to `BUS_WRITE_IVAR' @/dev/acpica/acpivar.h:206: warning: called from here bus_if.h:39: warning: inlining failed in call to `BUS_READ_IVAR' @/dev/acpica/acpivar.h:215: warning: called from here bus_if.h:50: warning: inlining failed in call to `BUS_WRITE_IVAR' @/dev/acpica/acpivar.h:227: warning: called from here bus_if.h:39: warning: inlining failed in call to `BUS_READ_IVAR' @/dev/acpica/acpivar.h:236: warning: called from here bus_if.h:50: warning: inlining failed in call to `BUS_WRITE_IVAR' @/dev/acpica/acpivar.h:248: warning: called from here bus_if.h:39: warning: inlining failed in call to `BUS_READ_IVAR' @/dev/acpica/acpivar.h:194: warning: called from here All the files that include bus_if.h get these. Ideas? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Making a disk bootable...
Ian Freislich wrote this message on Mon, Jul 14, 2003 at 18:48 +0200: > I've just tried this dd'ing /dev/zero over the front of the disk > first to no avail (the probed geometry is the geometry that fdisk > used anyway). I also tried your much loved ficticious geometry of > 255H 64S and that didn't work. It's a RPITA. In the end I dangerously > dedicated the disk and that works. One thing you might of been missing is making sure that the type in the disklabel was set properly. For scsi, it must be SCSI, and for IDE it must be IDE or ESDI. I had problems with this too. -- 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: Making a disk bootable...
Mark Murray wrote: > Hi Ian! > > Ian Freislich writes: > > I've used fdisk to create one slice (da0s1). I then used bsdlabel > > to make make the partitions a, b, e and f. Then to put the boot > > block on 'disklabel -B /dev/da0s1' - if I 'disklabel -B /dev/da0' > > it trashes the label. Then I copy all my filesystems off the IDE > > drive I'm trying to rid myself of onto the SCSI disk. When I tell > > the BIOS to boot off SCSI, it complains 'Missing Operating System'. > > Then, when you fdisk, make damn sure that the probed geometry is used. > After that, you shouldn't have probelms. If that fixes your problem, > please report it in detail to [EMAIL PROTECTED] so we can get a more > permanent fix. I've just tried this dd'ing /dev/zero over the front of the disk first to no avail (the probed geometry is the geometry that fdisk used anyway). I also tried your much loved ficticious geometry of 255H 64S and that didn't work. It's a RPITA. In the end I dangerously dedicated the disk and that works. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overdone rescue cleaning as part of buildworld?
On Mon, Jul 14, 2003 at 09:09:52AM -0700, Gordon Tetlow wrote: > On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote: > > On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote: > > > It appears /rescue is cleaning for way too much as part of buildworld. > > > For instance, groff is NOT part of /rescue (or we have other things to > > > discuss. :) This adds a bit of time to buildworld, can it be removed? > > > > Gordon, 'make world' times have climbed up to over 1 hour on a machine > > that used to do it in 25 minutes. Can you please commit to understanding > > how /resuce is build and optimizing it before 5.2-RELEASE. > > I've already started this process and I have some work in a local tree > to depessimize the build dramatically. Thanks! :-) > Would you be interested in taking a look at the patches? If it would be a help to you, I am willing. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overdone rescue cleaning as part of buildworld?
On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote: > On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote: > > It appears /rescue is cleaning for way too much as part of buildworld. > > For instance, groff is NOT part of /rescue (or we have other things to > > discuss. :) This adds a bit of time to buildworld, can it be removed? > > Gordon, 'make world' times have climbed up to over 1 hour on a machine > that used to do it in 25 minutes. Can you please commit to understanding > how /resuce is build and optimizing it before 5.2-RELEASE. I've already started this process and I have some work in a local tree to depessimize the build dramatically. Thank you for the reminder. Would you be interested in taking a look at the patches? -gordon pgp0.pgp Description: PGP signature
Re: HEADSUP: acpica 0619 in the tree
On Mon, 14 Jul 2003, Mark Santcroos wrote: > On Sun, Jul 13, 2003 at 04:18:52PM -0700, Nate Lawson wrote: > > I have imported acpica 0619. I will be gone for a few hours but will be > > checking again tonight in case there are any problems. > > I wasn't able to test the update before it was committed, but it doesn't > have any runtime regressions for me so far, so that's good! > > However, something I haven't seen reported before, is that it breaks for > the ACPI_DEBUG case. (Which I have in /etc/make.conf) > > The first thing to do is to add the new file dmobject.c to the debugging > section in the modules/acpi/Makefile. > However, there are some more hairy things that prevent it from simply just > working that I am looking into now. Yes, thanks for pointing that out. The whole debug level/layer thing changed and I need to update the code for that. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Making a disk bootable...
Hi Ian! Ian Freislich writes: > I've used fdisk to create one slice (da0s1). I then used bsdlabel > to make make the partitions a, b, e and f. Then to put the boot > block on 'disklabel -B /dev/da0s1' - if I 'disklabel -B /dev/da0' > it trashes the label. Then I copy all my filesystems off the IDE > drive I'm trying to rid myself of onto the SCSI disk. When I tell > the BIOS to boot off SCSI, it complains 'Missing Operating System'. I've seen this before, and I think it is a geometry problem. Boot the system in verbose mode (off the floppy), and go back and see what the boot probe thinks the geomtery is. (blat the boot partitions first, if you can). Then, when you fdisk, make damn sure that the probed geometry is used. After that, you shouldn't have probelms. If that fixes your problem, please report it in detail to [EMAIL PROTECTED] so we can get a more permanent fix. 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]"
ata raid crash
It seems that the ata driver still has some issues with configuring the RAID devices. Sources cvsupped today. Pete Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Copyright (c) 1992-2003 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.1-CURRENT #11: Mon Jul 14 12:22:00 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/EMTEST Preloaded elf kernel "/boot/kernel/kernel" at 0xc04d7000. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 598009854 Hz CPU: Intel Celeron (598.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383fbff real memory = 267386880 (255 MB) avail memory = 254500864 (242 MB) Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00e8790 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci_cfgintr: 0:2 INTA BIOS irq 5 pci_cfgintr: 0:31 INTD BIOS irq 11 pci_cfgintr: 0:31 INTB BIOS irq 9 agp0: mem 0x4070-0x4077,0x4400-0x47ff irq 5 at device 2.0 on pci0 pcib1: at device 30.0 on pci0 pci2: on pcib1 pci_cfgintr: 2:8 INTA BIOS irq 5 pci_cfgintr: 2:8 INTB BIOS irq 9 pci_cfgintr: 2:9 INTA BIOS irq 9 pci_cfgintr: 2:10 INTA BIOS irq 10 pci2: at device 8.0 (no driver attached) pci2: at device 8.1 (no driver attached) atapci0: port 0x1080-0x10ff,0x1480-0x148f,0x1000-0x107f mem 0x4020-0x4021,0x4040-0x40400fff irq 9 at device 9.0 on pci2 ata2: at 0x4040 on atapci0 ata3: at 0x4040 on atapci0 ata4: at 0x4040 on atapci0 ata5: at 0x4040 on atapci0 atapci1: port 0x1490-0x149f,0x14b4-0x14b7,0x14a8-0x14af,0x14b0-0x14b3,0x14a0-0x14a7 mem 0x4030-0x40303fff irq 10 at device 10.0 on pci2 ata6: at 0x14a0 on atapci1 ata7: at 0x14a8 on atapci1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci2: port 0x2460-0x246f at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci2 ata1: at 0x170 irq 15 on atapci2 uhci0: port 0x2440-0x245f irq 11 at device 31.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 31.5 (no driver attached) orm0: at iomem 0xe-0xe,0xd1800-0xd3fff,0xca000-0xd17ff,0xc-0xc9fff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ppc1: parallel port not found. unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounters tick every 10.000 msec ad4: 76319MB [155061/16/63] at ata2-master UDMA100 ad6: 76319MB [155061/16/63] at ata3-master UDMA100 ad8: 76319MB [155061/16/63] at ata4-master UDMA100 ad12: 76319MB [155061/16/63] at ata6-master UDMA100 ar0: 76319MB [9729/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad8 at ata4-master ar1: WARNING - mirror lost ar1: 76319MB [9729/255/63] status: DEGRADED subdisks: disk0 READY on ad6 at ata3-master disk1 DOWN no device found for this disk ar2: WARNING - mirror lost ar2: 76319MB [9729/255/63] status: DEGRADED subdisks: disk0 DOWN no device found for this disk disk1 READY on ad12 at ata6-master Opened disk ad4 -> 1 Opened disk ad4 -> 1 Opened disk ad4 -> 1 Opened disk ad4 -> 1 Opened disk ad6 -> 1 Opened disk ad6 -> 1 Opened disk ad8 -> 1 Opened disk ad8 -> 1 Opened disk ad12 -> 1 Opened disk ad12 -> 1 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0161106 stack pointer = 0x10:0xcd22ebd4 frame pointer = 0x10:0xcd22ec54 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 = 4 (g_down) kernel: type 12 trap, code=0 Stopped at arstrategy+0x906: movl0x10(%eax),%eax db> trace arstrategy(c26a42d0,0,c0393b57,5c,0) at arstrategy+0x906 g_disk_start(c26a4360,0,c03940be,159,a) at g_disk_start+0x19e g_io_schedule_down(c0ead000,2,c039428f,6e,c01d9390) at g_io_schedule_down+0x19c g_down_procbody(0,cd22ed48,c0395fd6,312,14ec8353) at g_down_procbody+0x48 fork_exit(c01d9390,0,cd22ed48) at fork_exit+0xc0 fork_trampoline() at f
Re: HEADSUP: acpica 0619 in the tree
On Sun, Jul 13, 2003 at 04:18:52PM -0700, Nate Lawson wrote: > I have imported acpica 0619. I will be gone for a few hours but will be > checking again tonight in case there are any problems. I wasn't able to test the update before it was committed, but it doesn't have any runtime regressions for me so far, so that's good! However, something I haven't seen reported before, is that it breaks for the ACPI_DEBUG case. (Which I have in /etc/make.conf) The first thing to do is to add the new file dmobject.c to the debugging section in the modules/acpi/Makefile. However, there are some more hairy things that prevent it from simply just working that I am looking into now. Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Belkin USB2serial F5U103
On Mon, 14 Jul 2003 15:57:54 +0200 Guenter Doerrhoefer <[EMAIL PROTECTED]> wrote: > According to the release note the Belkin F5U103 should be supported. I > > could not get it to operate, the device is recognized but cannot be > configured. Anyone got the Belkin to cooperate with 5.2-current? Hardly a bug report. Care to shed more details? -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Belkin USB2serial F5U103
According to the release note the Belkin F5U103 should be supported. I could not get it to operate, the device is recognized but cannot be configured. Anyone got the Belkin to cooperate with 5.2-current? We tried several other adapters (not mentioned in the release note) and found that they work without problems: M-CAB USB-serial adapter cable and M-CAB USB2.0-serial adapter cable Hint for programming: The port UCOMn mounted by the USBA-driver must remain open after settings are made, otherwise the settings are lost when port is closed. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Making a disk bootable...
Peter McGarvey wrote: > * Ian Freislich <[EMAIL PROTECTED]> [2003-07-14 13:58:39 BST]: > > Hi > > > > This might sound like a really simple question, but what used to > > work no longer does. How do you partition, label and make a disk > > bootable? > > And this may sound like a really stupid answer, but have you considered > using /stand/sysinstall? Yes. See paragraph 4. Aside, I'd like to be able to do this from the command line anyway. > > > I've used fdisk to create one slice (da0s1). I then used bsdlabel > > to make make the partitions a, b, e and f. Then to put the boot > > block on 'disklabel -B /dev/da0s1' - if I 'disklabel -B /dev/da0' > > it trashes the label. Then I copy all my filesystems off the IDE > > drive I'm trying to rid myself of onto the SCSI disk. When I tell > > the BIOS to boot off SCSI, it complains 'Missing Operating System'. > > > > So I try to dd the first 512 bytes of ad0 onto da0. The BIOS now > > doesn't complain about a missing operating system, it just hangs > > and the label on da0 is trashed. > > > > So, after about 7 cycles of fdisk, label, newfs, dump, restore, > # boot SCSI die 'Missing Operating System', boot IDE I give up and > # try to use sysinstall compiled on July 9 from sources of the same > # thinking 'surely the installer must be able to make a disk bootable'. > # It can't either. BTW, it doesn't even make the filesystems when > # you 'w'rite the changes in the label editor, even though it say's > > it's makeing the filesystems. So for the moment, I have to keep > > the IDE disk just for the MBR and type '1:da(0,a)/boot/loader' which > > is a bit inconvenient. > > > > Does anyone have any suggestions short of putting the disks I want > > labeled in a -STABLE box (which will be a major PITA since my -STABLE > > box doesn't have SCSI and the controler is on-board on my -CURRENT > > box)? > > > > Ian > > ___ > > [EMAIL PROTECTED] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > -- > TTFN, FNORD > > Peter McGarvey > Freelance FreeBSD Hacker > (will work for bandwidth) > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Making a disk bootable...
* Ian Freislich <[EMAIL PROTECTED]> [2003-07-14 13:58:39 BST]: > Hi > > This might sound like a really simple question, but what used to > work no longer does. How do you partition, label and make a disk > bootable? And this may sound like a really stupid answer, but have you considered using /stand/sysinstall? > I've used fdisk to create one slice (da0s1). I then used bsdlabel > to make make the partitions a, b, e and f. Then to put the boot > block on 'disklabel -B /dev/da0s1' - if I 'disklabel -B /dev/da0' > it trashes the label. Then I copy all my filesystems off the IDE > drive I'm trying to rid myself of onto the SCSI disk. When I tell > the BIOS to boot off SCSI, it complains 'Missing Operating System'. > > So I try to dd the first 512 bytes of ad0 onto da0. The BIOS now > doesn't complain about a missing operating system, it just hangs > and the label on da0 is trashed. > > So, after about 7 cycles of fdisk, label, newfs, dump, restore, > boot SCSI die 'Missing Operating System', boot IDE I give up and > try to use sysinstall compiled on July 9 from sources of the same > thinking 'surely the installer must be able to make a disk bootable'. > It can't either. BTW, it doesn't even make the filesystems when > you 'w'rite the changes in the label editor, even though it say's > it's makeing the filesystems. So for the moment, I have to keep > the IDE disk just for the MBR and type '1:da(0,a)/boot/loader' which > is a bit inconvenient. > > Does anyone have any suggestions short of putting the disks I want > labeled in a -STABLE box (which will be a major PITA since my -STABLE > box doesn't have SCSI and the controler is on-board on my -CURRENT > box)? > > Ian > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- TTFN, FNORD Peter McGarvey Freelance FreeBSD Hacker (will work for bandwidth) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Help diagnosing NIS breakage ?
On Mon, 14 Jul 2003, Robin P. Blanchard wrote: > Ok...Been systematically stepping through the sources to locate the point at > which NIS became broken. Here are the results: > > -CURRENT src date report > --- --- > 2003.06.18.00.00.00 success > 2003.06.25.00.00.00 success > 2003.06.26.00.00.00 success > 2003.06.27.00.00.00 sucesss > 2003.06.28.00.00.00 failure > 2003.07.01.00.00.00 failure > 2003.07.09.00.00.00 failure > latest (last night) failure > > So, something between 27 and 28 June resulted in this NIS breakage. Hopefully > this will jog someone's memory and give ideas as to my/our next step as to > diagnosing/repairing what's wrong here. I have a test box with src's and obj > 's from both 27 and 28 june availabe for testing, should someone like to ssh > in and poke around. Try backing out rev 1.82 of src/lib/libc/gen/getpwent.c. If that works, then perhaps there is something wrong with FreeBSD's yp_master (on server end). -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Making a disk bootable...
Hi This might sound like a really simple question, but what used to work no longer does. How do you partition, label and make a disk bootable? I've used fdisk to create one slice (da0s1). I then used bsdlabel to make make the partitions a, b, e and f. Then to put the boot block on 'disklabel -B /dev/da0s1' - if I 'disklabel -B /dev/da0' it trashes the label. Then I copy all my filesystems off the IDE drive I'm trying to rid myself of onto the SCSI disk. When I tell the BIOS to boot off SCSI, it complains 'Missing Operating System'. So I try to dd the first 512 bytes of ad0 onto da0. The BIOS now doesn't complain about a missing operating system, it just hangs and the label on da0 is trashed. So, after about 7 cycles of fdisk, label, newfs, dump, restore, boot SCSI die 'Missing Operating System', boot IDE I give up and try to use sysinstall compiled on July 9 from sources of the same thinking 'surely the installer must be able to make a disk bootable'. It can't either. BTW, it doesn't even make the filesystems when you 'w'rite the changes in the label editor, even though it say's it's makeing the filesystems. So for the moment, I have to keep the IDE disk just for the MBR and type '1:da(0,a)/boot/loader' which is a bit inconvenient. Does anyone have any suggestions short of putting the disks I want labeled in a -STABLE box (which will be a major PITA since my -STABLE box doesn't have SCSI and the controler is on-board on my -CURRENT box)? Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Help diagnosing NIS breakage ?
Ok...Been systematically stepping through the sources to locate the point at which NIS became broken. Here are the results: -CURRENT src date report --- --- 2003.06.18.00.00.00 success 2003.06.25.00.00.00 success 2003.06.26.00.00.00 success 2003.06.27.00.00.00 sucesss 2003.06.28.00.00.00 failure 2003.07.01.00.00.00 failure 2003.07.09.00.00.00 failure latest (last night) failure So, something between 27 and 28 June resulted in this NIS breakage. Hopefully this will jog someone's memory and give ideas as to my/our next step as to diagnosing/repairing what's wrong here. I have a test box with src's and obj 's from both 27 and 28 june availabe for testing, should someone like to ssh in and poke around. Thanks in advance. Robin. > Can you build with a testbox new sources (binary search) > until you can locate the cutover point between where it works > and where it doesn't? > > > OK... Nsswitch.conf exists on neither machine here. I setup a > > > test nsswitch.conf on the broken NIS box to use NIS but it > > > didn't help at all. > > > > > > 1) > > > On FreeBSD 5.1-CURRENT #0: Tue Jun 17 10:28:52 EDT 2003: > > > # ypcat passwd |fgrep robin > > > robin:OeIS3xdIRAiQs:20292:30028::/home/robin:/bin/bash > > > # finger robin > > > Login: robinName: > > > Directory: /home/robin Shell: /bin/bash > > > Never logged in. > > > No Mail. > > > No Plan. > > > # id robin > > > uid=20292(robin) gid=30028(NSS) groups=30028(NSS), > > > 3(gactr), 30026(ITS) # tail -2 /etc/passwd > > > nobody:*:65534:65534:Unprivileged user:/nonexistent:/sbin/nologin > > > +:*: > > > # tail -2 /etc/passwd > > > nobody:*:65534:65534:Unprivileged user:/nonexistent:/sbin/nologin > > > +:*: > > > # tail -2 /etc/group > > > nobody:*:65534: > > > +:*:0: > > > > > > > > > 2) > > > On FreeBSD 5.1-CURRENT #0: Mon Jul 7 11:33:56 EDT 2003 > > > # ypcat passwd |fgrep robin > > > robin:OeIS3xdIRAiQs:20292:30028::/home/robin:/bin/bash > > > # finger robin > > > Login: robinName: > > > Directory: /home/robin Shell: /bin/bash > > > Last login Mon Jul 7 07:47 (EDT) on ttyp0 from 10.2.2.10 > > > No Mail. > > > No Plan. > > > # id robin > > > id: robin: no such user > > > # tail -2 /etc/passwd > > > nobody:*:65534:65534:Unprivileged user:/nonexistent:/sbin/nologin > > > +:*: > > > # > > > # tail -2 /etc/group > > > nobody:*:65534: > > > +:*:0: > > > > > > And here's something else interesting on this 'broken' NIS box: > > > > > > # ls -ald . > > > drwx--x--x 4 20292 NSS 4.0K Jun 13 13:34 ./ > > > > > > So (via NIS) GID translation is working but not UID > translation > > > > > > Look forward to getting this solved... > > > > > > > > > > > > > > -john > > > > > > > > > Demonstration: > > > > > > > > > > # ypcat passwd |fgrep robin > > > > > robin:OeIS3xdIRAiQs:20292:30028::/home/robin:/bin/bash > > > > > # ypcat group |fgrep robin > > > > > > > > > > > > > gactr::3:holmesr,wrighta,prestonh,reagind,gankol,cafieroj,cahoon > > > b, > > > > > pettigr > > > > > m,brantlek,thumat,dosterc,nate,robin,charles > > > > > ITS::30026:dosterc,nate,robin,charles > > > > > NSS::30028:dosterc,nate,robin,charles,test > > > > > # ps ax |fgrep ypbind > > > > > 79910 ?? Ss 0:00.03 ypbind > > > > > # ypwhich > > > > > GCDC2.gc.nat > > > > > # finger robin > > > > > Login: robinName: > > > > > Directory: /home/robin Shell: /bin/bash > > > > > Last login Mon Jul 7 07:47 (EDT) on ttyp0 from 10.2.2.10 No > > > > > Mail. No Plan. > > > > > > > > > > So NIS is 'working'...But: > > > > > # id robin > > > > > id: robin: no such user > > > > > > > > > > And as a result, he (I) cannot login. > > > > > > > > > > # su - robin ; tail -1 /var/log/auth.log > > > > > > > > > > su: Sorry > > > > > Jul 7 13:59:29 ftp su: pam_acct_mgmt: error in service module > > > > > > > > > > There's a truss and a ktrace (of the id command) > available at: > > > > > ftp://ftp.gactr.uga.edu/incoming/id.tar.gz > > > > > > > > > > Thanks in advance. > > > > > > > > > -- > -- > As said by Napolean Bonaparte: > "Never ascribe to malice, that which is adequately explained > by incompetence" > > After being embraced by MS: > > "When accused of malice, always hide behind incompetence". > ___ [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-07-14 11:12:19 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-07-14 11:12:19 - 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-07-14 11:14:29 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> 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.. [...] gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/getnetent.3 > getnetent.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/getprotoent.3 > getprotoent.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/getservent.3 > getservent.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/hesiod.3 > hesiod.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/if_indextoname.3 > if_indextoname.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/inet.3 > inet.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/inet_net.3 > inet_net.3.gz Bus error (core dumped) *** Error code 138 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib. *** 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. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-07-14 11:53:19 - /usr/bin/make returned exit code 1 TB --- 2003-07-14 11:53:19 - ERROR: failed to build world TB --- 2003-07-14 11:53:19 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FFS_ROOT is gone?
On Sat, Jul 12, 2003 at 02:22:41AM +0200, Harald Schmalzbauer wrote: > Hello, > > my kernel (5.1-REL) can't mount root (mountroot>) on my CF-card although > it's booting fine and I can mount the card on my USB card reader. > I had a look at GENERIC and saw that I didn't miss the option FFS_ROOT but > it doesn't exist any longer. > Any ideas why I can't mount root? Any messages? -can't mount- ist sparse input. Does it mount the volume without being rootfs? -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW and/or rc rule parsing not working since today's cvsup
just committed a fix cheers luigi On Sun, Jul 13, 2003 at 01:31:07PM +0100, Matt wrote: > > Matt said: > > I normally sync to current once a week and have just done it today: > > > > FreeBSD tao.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Jul 13 > > 12:24:40 BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TAO > > i386 > > > > The problem is though that it looks like IPFW or RC has changed how it > > works. I'm not sure if this is intentional or not though. If it is > > intentional then I think it is a violation of POLA. ___ [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-07-14 06:40:25 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-07-14 06:40:25 - 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-07-14 06:42:29 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> 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 >>> stage 4: building everything.. TB --- 2003-07-14 07:47:01 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Building an up-to-date make(1) >>> Kernel build for GENERIC started on Mon Jul 14 07:47:02 GMT 2003 >>> Kernel build for GENERIC completed on Mon Jul 14 08:01:22 GMT 2003 TB --- 2003-07-14 08:01:22 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-14 08:01:22 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Building an up-to-date make(1) >>> Kernel build for LINT started on Mon Jul 14 08:01:23 GMT 2003 [...] dbdisply.o: In function `AcpiDbDisplayArguments': dbdisply.o(.text+0x69c): undefined reference to `AcpiDmDisplayArguments' dbdisply.o: In function `AcpiDbDisplayResults': dbdisply.o(.text+0x772): undefined reference to `AcpiDmDisplayInternalObject' dbdisply.o: In function `AcpiDbDisplayResultObject': dbdisply.o(.text+0x99c): undefined reference to `AcpiDmDisplayInternalObject' dbdisply.o: In function `AcpiDbDisplayArgumentObject': dbdisply.o(.text+0xa0c): undefined reference to `AcpiDmDisplayInternalObject' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** 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-07-14 08:13:53 - /usr/bin/make returned exit code 1 TB --- 2003-07-14 08:13:53 - ERROR: failed to build lint kernel TB --- 2003-07-14 08:13:53 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overdone rescue cleaning as part of buildworld?
On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote: > It appears /rescue is cleaning for way too much as part of buildworld. > For instance, groff is NOT part of /rescue (or we have other things to > discuss. :) This adds a bit of time to buildworld, can it be removed? Gordon, 'make world' times have climbed up to over 1 hour on a machine that used to do it in 25 minutes. Can you please commit to understanding how /resuce is build and optimizing it before 5.2-RELEASE. thanks, -- -- David([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fla.ko
David Yeske wrote this message on Sun, Jul 13, 2003 at 19:21 -0700: > I'm wondering what needs to be done to make the "fla" device into a kernel module. > I made modules/fla/Makefile, but I am not sure what else needs to be done. > It looks like you can't kldunload it after you kldload it... You need to add a method to detach the device: /* Device interface */ DEVMETHOD(device_probe, flaprobe), DEVMETHOD(device_attach,flaattach), there needs to be a device_detach line here. Look at other drivers on how to add this. One the detach can be successfully called, kldunload should then start working. -- 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]"
