Re: panic: page fault on FreeBSD 5.1 -RELEASE
On Wed, 11 Jun 2003, Nick Twaddell wrote: I downloaded the 5.1 -RELEASE isos yesterday and tried to install them on my server. My server is an IBM Xseries 330 server with an IBM ServeRAID 4LX Raid card. I tried it with and without ACPI kernels and both resulted in a panic. Here is the error.. Fatal trap 12: page fault while in kernel mode Fault code= supervisor read, page not present Instruction pointer = 0x8:0xc29ee760 Stack pointer = 0x10:0xcd33fce4 Frame pointer = 0x10:0xcd33fd0c Code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 Processor eflags = interupt enabled, resume, IOPL = 0 Current process = 29 (irq9: ahc0 ips0) Trap number = 12 Panic = page fault Did I do something wrong or is there a problem with the driver? :( I can't see an invalid eip, ebp, or esp in the above page fault. It would really help if you could get a backtrace (tr when you have DDB enabled). BTW, re@ people: could we add an option (under a sysctl but on by default in the release) that does a backtrace on page fault? We already have the backtrace code accessible w/o DDB I believe. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
On Thu, Jun 12, 2003 at 07:18:12AM +0200, Wiktor Niesiobedzki wrote: On Wed, Jun 11, 2003 at 09:50:22PM -0700, Kris Kennaway wrote: On Wed, Jun 11, 2003 at 10:48:32PM -0600, Andrew Lankford wrote: Can you try backing out bsd.sys.mk to r1.26 and rebuild your world and kernel? Later versions of this file are causing strange problems with package builds. I was a little lazy and just backed out bsd.sys.mk to 1.26 as you suggested, rebuilt /usr/lib/ , /usr/include/, and ppp. My kernel is the same as last time. As a result, ppp's now up and running again. Thanks, that's actually more useful because it isolates the problem. It's probably something in ppp that is misbehaving with CSTD=c99. alloca(3) function is misbehaving in ppp (namely ether.c). Is this a compiler bug? It looks like gcc's inline alloca implementation allocates chunks in larger chunks than the alloca.S implementation does. This (untested) patch should make the alloca.S behaviour match that of gcc. Kris Index: i386/gen/alloca.S === RCS file: /usr/home/ncvs/src/lib/libc/i386/gen/alloca.S,v retrieving revision 1.10 diff -u -r1.10 alloca.S --- i386/gen/alloca.S 23 Mar 2002 02:44:18 - 1.10 +++ i386/gen/alloca.S 12 Jun 2003 06:00:52 - @@ -47,8 +47,8 @@ popl%edx/* pop return addr */ popl%eax/* pop amount to allocate */ movl%esp,%ecx - addl$3,%eax /* round up to next word */ - andl$0xfffc,%eax + addl$15,%eax/* round up to next word */ + andl$0xfff0,%eax subl%eax,%esp movl%esp,%eax /* base of newly allocated space */ pushl 8(%ecx) /* copy possible saved registers */ pgp0.pgp Description: PGP signature
Re: adsl/pppoe no longer connecting on 5.1
On Wed, Jun 11, 2003 at 11:05:57PM -0700, Kris Kennaway wrote: It looks like gcc's inline alloca implementation allocates chunks in larger chunks than the alloca.S implementation does. This (untested) patch should make the alloca.S behaviour match that of gcc. I suspect that there's a buffer overrun in one of the alloca() buffers in ppp, that is harmless with gcc's inline version because of the extra padding. I haven't spotted it yet though. Kris pgp0.pgp Description: PGP signature
Re: adsl/pppoe no longer connecting on 5.1
On Thu, Jun 12, 2003 at 07:18:12AM +0200, Wiktor Niesiobedzki wrote: On Wed, Jun 11, 2003 at 09:50:22PM -0700, Kris Kennaway wrote: On Wed, Jun 11, 2003 at 10:48:32PM -0600, Andrew Lankford wrote: Can you try backing out bsd.sys.mk to r1.26 and rebuild your world and kernel? Later versions of this file are causing strange problems with package builds. I was a little lazy and just backed out bsd.sys.mk to 1.26 as you suggested, rebuilt /usr/lib/ , /usr/include/, and ppp. My kernel is the same as last time. As a result, ppp's now up and running again. Thanks, that's actually more useful because it isolates the problem. It's probably something in ppp that is misbehaving with CSTD=c99. alloca(3) function is misbehaving in ppp (namely ether.c). Is this a compiler bug? Okay, it looks like alloca.S was broken. My previous patch that increased the size of allocations was just a gratuitous difference with the inline version, and is not necessary. Here's a fix that seems to get ppp to stop complaining. Kris Index: alloca.S === RCS file: /usr/home/ncvs/src/lib/libc/i386/gen/alloca.S,v retrieving revision 1.10 diff -u -r1.10 alloca.S --- alloca.S23 Mar 2002 02:44:18 - 1.10 +++ alloca.S12 Jun 2003 07:35:03 - @@ -51,6 +51,7 @@ andl$0xfffc,%eax subl%eax,%esp movl%esp,%eax /* base of newly allocated space */ + leal24(%esp), %eax pushl 8(%ecx) /* copy possible saved registers */ pushl 4(%ecx) pushl 0(%ecx) pgp0.pgp Description: PGP signature
[-CURRENT tinderbox] failure on i386/pc98
TB --- 2003-06-12 06:49:32 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-06-12 06:49:32 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-12 06:52:11 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. [...] cc -O -pipe -mcpu=pentiumpro -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/vinum/../../sys -std=iso9899:1999 -c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/vinum/vinumutil.c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/vinum/vinumutil.c: In function `DriveState': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/vinum/vinumutil.c:137: warning: implicit declaration of function `strcmp' cc -O -pipe -mcpu=pentiumpro -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/vinum/../../sys -std=iso9899:1999 -c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/vinum/commands.c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/vinum/commands.c: In function `vinum_label': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/vinum/commands.c:700: `VINUM_LABEL' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/vinum/commands.c:700: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/vinum/commands.c:700: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin/vinum. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sbin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-06-12 07:40:57 - /usr/bin/make returned exit code 1 TB --- 2003-06-12 07:40:57 - ERROR: failed to build world TB --- 2003-06-12 07:40:57 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
On Thu, Jun 12, 2003 at 12:38:36AM -0700, Kris Kennaway wrote: Okay, it looks like alloca.S was broken. My previous patch that increased the size of allocations was just a gratuitous difference with the inline version, and is not necessary. Here's a fix that seems to get ppp to stop complaining. Oops, forgot to remove the movl. Index: alloca.S === RCS file: /usr/home/ncvs/src/lib/libc/i386/gen/alloca.S,v retrieving revision 1.10 diff -u -r1.10 alloca.S --- alloca.S23 Mar 2002 02:44:18 - 1.10 +++ alloca.S12 Jun 2003 07:41:45 - @@ -50,7 +50,7 @@ addl$3,%eax /* round up to next word */ andl$0xfffc,%eax subl%eax,%esp - movl%esp,%eax /* base of newly allocated space */ + leal24(%esp), %eax /* base of newly allocated space */ pushl 8(%ecx) /* copy possible saved registers */ pushl 4(%ecx) pushl 0(%ecx) Kris pgp0.pgp Description: PGP signature
Re: adsl/pppoe no longer connecting on 5.1
On Thu, Jun 12, 2003 at 12:44:51AM -0700, Kris Kennaway wrote: + leal24(%esp), %eax /* base of newly allocated space */ After I figured out what the 24(...) meant (add 24 to ...) it's clear that this isn't a fix (except in the special case of PPPoE support ;-). gcc's builtin inline alloca() is tuning that offset value at compile-time, so alloca.S is just broken (and has been since 386BSD, looks like), but it's beyond my pattern-monkey asm skills to fix. Kris pgp0.pgp Description: PGP signature
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
Craig Boston wrote this message on Wed, Jun 11, 2003 at 22:44 -0500: Believe it or not, after futzing with the debugger for hours, reading the OHCI spec, and trying to figure out why writing to the control registers works exactly as it should but the card seems to ignore the ED list, I decided to try something completely crazy and put the line pci_enable_busmaster(self); near the top of ohci_attach() in ohci_pci.c ...and it worked! I believe my first words upon seeing ums0: blah blah were You have GOT to be kidding me. Hey, thanks for the great work. This got me past the same problem on the sparc box I have, but now I'm getting tons of: usb0: 198 scheduling overruns I fiddled with the PCI Latency, but it doesn't seem to do much good. (Though the latency was set wrong.) -- 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: CSTD=c99 breaks package creation
deleting the define __attribute stuff in system.h of /usr/src/contrib/tar/src/system.h and rebuilding+installing tar repaired package creation here. -- Mit freundlichen Grüßen Fritz Heinrichmeyer FernUniversitaet, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://www-es.fernuni-hagen.de/~jfh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Duplicate keys in CVSROOT/modules
Hello, since 1.557 in cvs:main/CVSROOT/modules, there are three duplicate keys: # egrep -w (fib|libpanel|rain) modules.1.557 | sort fib ports/devel/fib fib src/usr.bin/fib libpanelports/x11/libpanel libpanelsrc/lib/libpanel rainports/security/rain rainsrc/games/rain Is it possible to fix them? -- Rudolf Cejka cejkar at fit.vutbr.cz http://www.fit.vutbr.cz/~cejkar Brno University of Technology, Faculty of Information Technology Bozetechova 2, 612 66 Brno, Czech Republic ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Apparent i386 alloca.S bug (was: adsl/pppoe no longer connecting on5.1)
Here's a test program for the i386 alloca() bug. Compile with -std=gnu89 (or
no -std option) and it works fine. Compile with -std=c99 or -std=c89 and it
breaks like this:
corruption: 05 should be 0xcc at offset 0
corruption: 00 should be 0xcc at offset 1
corruption: 00 should be 0xcc at offset 2
corruption: 00 should be 0xcc at offset 3
Interestingly, gcc -std=c89 on FreeBSD 4.8 doesn't trigger the bug.
#include assert.h
#include stdio.h
#include stdlib.h
#include string.h
#define NUMBYTES511
static void
somefunc(int a, int b, int c, int d, int e)
{
}
int
main(int argc, char *argv[])
{
char *s;
int i;
int failed;
s = alloca(NUMBYTES);
memset(s, 0xcc, NUMBYTES);
somefunc(1, 2, 3, 4, 5);
failed = 0;
for (i = 0; i NUMBYTES; i++) {
if ((unsigned char)s[i] != 0xcc) {
printf(corruption: %02x should be 0xcc at offset %d\n,
(unsigned char)s[i], i);
failed = 1;
}
}
exit(failed);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Duplicate keys in CVSROOT/modules
Cejka Rudolf (cejkar) writes: Is it possible to fix them? I sent a mail to the CVS repository Meisters yesterday, so it's just a matter of time before it will be fixed. /mich -- Best Regards, Michael L. Hostbaek FreeBSD Committer - FreeBSD: The power to serve [EMAIL PROTECTED] - http://www.FreeBSD.org */ PGP-key available upon request /* ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on ia64/ia64
TB --- 2003-06-12 07:40:58 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-06-12 07:40:58 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-12 07:44:51 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. [...] /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/vinum/list.c:879: warning: cast from pointer to integer of different size cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/vinum/../../sys-c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/vinum/vinumparser.c cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/vinum/../../sys-c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/vinum/vinumutil.c cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/vinum/../../sys-c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/vinum/commands.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/vinum/commands.c: In function `vinum_label': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/vinum/commands.c:700: `VINUM_LABEL' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/vinum/commands.c:700: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/vinum/commands.c:700: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/vinum. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-06-12 08:38:33 - /usr/bin/make returned exit code 1 TB --- 2003-06-12 08:38:33 - ERROR: failed to build world TB --- 2003-06-12 08:38:33 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-06-12 08:39:03 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-12 08:39:03 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-12 08:41:27 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. [...] cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum/../../sys -std=gnu99 -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumutil.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumutil.c: In function `DriveState': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumutil.c:137: warning: implicit declaration of function `strcmp' cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum/../../sys -std=gnu99 -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum/commands.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum/commands.c: In function `vinum_label': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum/commands.c:700: `VINUM_LABEL' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum/commands.c:700: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum/commands.c:700: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin. *** 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-06-12 09:25:50 - /usr/bin/make returned exit code 1 TB --- 2003-06-12 09:25:50 - ERROR: failed to build world TB --- 2003-06-12 09:25:50 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.0/5.1: Installer does not find CD-ROM drive - even thoughit's booted off it
onsdagen den 11 juni 2003 kl 08.04 skrev Vitaly Markitantov: On Tue, Jun 10, 2003 at 09:19:08PM -0500, [EMAIL PROTECTED] wrote: FWIW - I have a Samsung SM-348 48x CD/DVD combo unit that works just fine under 5.1 (and 4.8): acd0: CD-RW SAMSUNG CDRW/DVD SM-348B at ata0-master PIO4 Yes, i have 48X SAMSUNG CD-ROM SC-148T, and it works fine under 5.1 and 4.8 Maybe only 52X Samsung SC-152 is broken for FreeBSD. Which is the precise drive I have. Just for information, what IDE chipset do you have? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Is IBM xSeries 225 supported by 5.1R ?
Hi!
I've got the problem. In one place, there is an IBM xSeries 225 machine,
which has an integrated ServeRAID controller (but _not_ the Adaptec verion,
instead, the motherboard-integrated, LSI 53c1030-based one), and a Broadcom
Gigabit Ethernet controller. I cannot go and try it, so are there anybody
who can give me some information about it. Is it supported in 5.1R, or in some
older version?
Thanx,
Zahy Gabor at Zahemszky dot HU
--
#!/bin/ksh
Z='21N16I25C25E30, 40M30E33E25T15U!' ;IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ ';set $Z ;for i
{ [[ $i = ? ]]print $ibreak;[[ $i = ??? ]]j=$ii=${i%?};typeset -i40
i=8#$i;print -n ${i#???};[[ $j = ??? ]]print -n ${j#??} j=;typeset +i
i;};IFS=' 0123456789 ';set $Z;for i { [[ $i = , ]]i=2;[[ $i = ?? ]]||typeset -l
i;j=$j $i;typeset +l i;};print $j
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
error building world
Hey there, I recently ran into a problem when building updated (via cvsup) world from -CURRENT. Some background information: FreeBSD caboose.shortcircut.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Jun 4 19:39:23 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CABOOSE i386 This is the error that stops the build: # cc -O -pipe -march=athlon-tbird -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/libbfd -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/include -DDEFAULT_VECTOR=bfd_elf32_i386_freebsd_vec -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd -DBFD_VERSION=\20021127\ -DBFD_VERSION_DATE=20021127 -DBFD_VERSION_STRING=\2.13.2 [FreeBSD] 2002-11-27\ -DSELECT_ARCHITECTURES= bfd_i386_arch -DHAVE_bfd_elf32_i386_freebsd_vec -DHAVE_bfd_elf32_i386_vec -DSELECT_VECS= bfd_elf32_i386_freebsd_vec ,bfd_elf32_i386_vec -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -c /usr/src/contrib/binutils/bfd/targets.c -o targets.o In file included from /usr/src/contrib/binutils/bfd/targets.c:1092: targmatch.h:7:1: null character(s) ignored targmatch.h:12:1: null character(s) ignored targmatch.h:16:1: null character(s) ignored targmatch.h:20:1: null character(s) ignored targmatch.h:24:1: null character(s) ignored ... ... ... targmatch.h:2037:1: null character(s) ignored *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils/libbfd. *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. ## Although this is where it stoppped, I recall seeing those null char ignored warnings scroll by earlier in the build as well. I tried removing/reinstalling /usr/include and /usr/share/mk, which unfortunately did not resolve the problem. After the original error, I also tried building from the 5.1-RELEASE tree, which produced the same error. Also, note that I had the error before I added the athlon-tbird cpu flags, so that is not a factor. I'm wondering if anyone has any suggestions. Thank you in advance! -- Mike Bohan [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: CardBus USB 2.0 Controller (NEC uPD)
On Wed, Jun 11, 2003 at 10:47:01PM -0500, Craig Boston wrote: On Wednesday 11 June 2003 07:21 pm, Bernd Walter wrote: On Wed, Jun 11, 2003 at 11:45:38PM +0100, Josef Karthauser wrote: The detach code could be made to work fairly easily. It's mostly there I believe, but disabled. Nick couldn't convince himself that all the used memory was being returned if the device is suddently unloaded. You could suck it and see. I'm not shure if the code would work, but it was also ported into ehci and therefor ehci should be in a similar state. Well loosing memory is better than panic. I have no cardbus - can this be tested with a module? I'd be more than happy to give it a shot on my now-working cardbus card and see what happens. It is as simple as adding DEVMETHOD(device_detach, ohci_pci_detach) to the device_method_t ? Yes + the same for ehci. -- 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: error building world
* Mike Bohan [EMAIL PROTECTED] [ Date: 2003-06-12 ] [ w.r.t. error building world ] Hey there, I recently ran into a problem when building updated (via cvsup) world from -CURRENT. This smells like a sed bug. Rebuild and install sed, and try again. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Apparent i386 alloca.S bug (was: adsl/pppoe no longerconnecting on 5.1)
On Thu, Jun 12, 2003 at 06:29:44PM +1000, Tim Robbins wrote: Here's a test program for the i386 alloca() bug. Compile with -std=gnu89 (or no -std option) and it works fine. Compile with -std=c99 or -std=c89 and it breaks like this: corruption: 05 should be 0xcc at offset 0 corruption: 00 should be 0xcc at offset 1 corruption: 00 should be 0xcc at offset 2 corruption: 00 should be 0xcc at offset 3 Interestingly, gcc -std=c89 on FreeBSD 4.8 doesn't trigger the bug. I should mention that you need to compile with -march=pentiumpro to trigger the bug. It's related to the way gcc 3 uses movl x,y(%esp) instead of pushl x when passing arguments to a function. I suggest backing out the commit that made CSTD=c99 the default, so that we go back to using gcc's builtin alloca() until we figure out how to fix the one in libc. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
On Thu, Jun 12, 2003 at 01:10:24AM -0700, John-Mark Gurney wrote: Craig Boston wrote this message on Wed, Jun 11, 2003 at 22:44 -0500: Believe it or not, after futzing with the debugger for hours, reading the OHCI spec, and trying to figure out why writing to the control registers works exactly as it should but the card seems to ignore the ED list, I decided to try something completely crazy and put the line pci_enable_busmaster(self); near the top of ohci_attach() in ohci_pci.c ...and it worked! I believe my first words upon seeing ums0: blah blah were You have GOT to be kidding me. Hey, thanks for the great work. This got me past the same problem on the sparc box I have, but now I'm getting tons of: usb0: 198 scheduling overruns usb is not available on other 64 bit platforms than alpha. We need busdma support in the controller drivers first. -- 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]
Centrino laptop (glidepoint | sd card | wireless)
I'm playing around with 5.1-RELEASE, kernel upgraded to -CURRENT, on a centrino-based laptop (from micropoint.nl, but that site's in dutch and short on technical details). The laptop boots winXP, linux, and 5.1-RELEASE just fine, but there are some devices missing when I boot into FreeBSD. The real irritating one is the lack of the glidepoint device, so I don't have an integrated mouse then. *** Glidepoint Mouse Has anybody else seen glidepoint devices disappearing on this kind of setup? Linux finds the mouse and gives me /dev/psaux to play with, but for the life of me I can't find out where it thinks the device lives - damn their dmesg output. Windows tells me that I have an 82801DBM LPC Interface controller, id 24CC, (which I presume is an ISA bus bridge) and hanging off of there there are typical ISA devices like the keyboard, printer port, and an Alps Pointing Device, which must be the touchy-feely pad thing. It's attached to the PS/2 mouse port, or so it claims, and IRQ 12. How can I best go about convincing the 5.1 kernel that there is a device there? Can I force a scan of the ISA bus, looking for this device (well, reading the ISA PnP configuration entries would be swell, too)? [Remainder of message is about other devices found not supported, speedstep, and other little things.] *** SD Card Reader This lappy, as well as my Toshiba Satellite 6100, come with an SD card reader. I don't suppose that's supported or will be supported in the near future. It's on IRQ 5, I/O 0x248-0x24f, FWIW. *** Wireless LAN The Intel PRO/Wireless LAN 2100 3B Mini PCI adaptor isn't recognized either - and earlier messages don't seem to be conclusive about whether it's supported or not. For example, http://lists.freebsd.org/mailman/htdig/freebsd-mobile/2003-March/07.html quotes an earlier message saying It's a Prism 2.5, which leaves me wondering whether it's supported or not. *** Speedstep The speedstep support - in particular sysctl ..current_speed and economy_speed - seems to work. At least, pulling the plug letting it go to battery, reducing the CPU speed, has a significant effect on things like md5 /usr/lib/* (not that that's a scientific test, mind you). -- Adriaan de Groot[EMAIL PROTECTED] Kamer A6020 024-3652272 GPG Key Fingerprint 934E 31AA 80A7 723F 54F9 50ED 76AC EE01 FEA2 A3FE http://www.cs.kun.nl/~adridg/research/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
On Thu, 2003-06-12 at 03:10, John-Mark Gurney wrote: Craig Boston wrote this message on Wed, Jun 11, 2003 at 22:44 -0500: Hey, thanks for the great work. This got me past the same problem on the sparc box I have... Don't look at me -- thank Warner for all his hard work on Cardbus and the many people in both the NetBSD and FreeBSD groups who have contributed to the OHCI/EHCI drivers. My little two-line patch wouldn't do squat without that huge support base :) Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
In article [EMAIL PROTECTED], Craig Boston [EMAIL PROTECTED] writes Believe it or not, after futzing with the debugger for hours, reading the OHCI spec, and trying to figure out why writing to the control registers works exactly as it should but the card seems to ignore the ED list, I decided to try something completely crazy and put the line pci_enable_busmaster(self); near the top of ohci_attach() in ohci_pci.c ...and it worked! I believe my first words upon seeing ums0: blah blah were You have GOT to be kidding me. Great news. I'm attaching a (trivial) patch for the lazy :) Be advised, this is far from a general solution as it probably breaks some (many?) PCI-based controllers that don't support bus mastering. Sorry, I don't understand this comment. All OHCI, UHCI EHCI USB controllers need PCI bus mastering in order to read update their various lists of pending completed transfers. Without bus mastering the system CPU has to do all this stuff in an interrupt handler. This can be quite a heavy cpu load, and is not attractive on a PC. (I've outlined this before, on [EMAIL PROTECTED] E.g. the ScanLogic SL811 needs an interrupt for every packet transfer, and Philips PHCI devices [e.g. ISP1160] needs a whole frame's worth of data to read written every ms.) Cheers, Tony ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Twin CPU machine running with only one cpu?
On Tue, 10 Jun 2003, Brendon and Wendy wrote: Conclusion in my case setting sysctl machdep.halt_logical_cpus=1 effectively halts my second CPU. Maybe it thought it was a second core in the first CPU? Mayhaps :) For Doug, thanks for the suggestions. Flashed the BIOS with no effect. Mptable attached. Well it sees both CPUs, so we have one of two possibilities: 1) Theres a bug in halt_logical_cpus that acts wierd if you don't have an HTT CPU in the system. 2) Theres a bug or other oddment that causes the AP not to be activated. I'm happy to test any patches arising from this... Have you looked at boot -v output? -- 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: SMP in 5.1 cant deactivate hyperthreading
On Wed, 11 Jun 2003, Steven Hartland wrote: sysctl machdep.hlt_logical_cpus: machdep.hlt_logical_cpus: 1 Halting them will still cause the CPUs to be detected. They just won't do any useful work. Relevant sections from dmesg: Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 24 pins in IOAPIC #1 Programming 24 pins in IOAPIC #2 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 6, version: 0x00050014, at 0xfee0 cpu2 (AP): apic id: 1, version: 0x00050014, at 0xfee0 cpu3 (AP): apic id: 7, version: 0x00050014, at 0xfee0 -- 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: ThinkPad T20 with 5.0R wakes up from halt -p
Hello Kevin, sorry for the question, but what is IYET60WW? Bye Oliver Kevin Oberman wrote: This is a bit odd, but version IYET60WW shows a BIOS date in 12/99, but a release date of 30-Apr-2003. I have been told by others that is really is a new release. You probably should check your BIOS version against IYET60WW. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP in 5.1 cant deactivate hyperthreading
- Original Message - From: Doug White [EMAIL PROTECTED] sysctl machdep.hlt_logical_cpus: machdep.hlt_logical_cpus: 1 Halting them will still cause the CPUs to be detected. They just won't do any useful work. Yep but the issue is that all the core admin tools are unaware of this and hence include the virtual cores in idle calcs etc making load monitoring impossible without nasty cludges :( So what's the way forward? 1. Dont just use halt have a compile or other directive to disable them? 2. Update all tools to be halt aware? Personally I'd go with 2 all be it more work / ramifications on other 3rd party tools as it gives the benefit of also working when physical CPU's are halted. Which ever it needs someone to pick it up ASAP dont you think? Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sh job control
Paul Richards [EMAIL PROTECTED] writes: I've installed a current built last night and job control no longer works in /bin/sh or /usr/local/bin/zsh, but it does with csh. ctr-c and ctrl-z are just ignored with both the sh style shells. [Same experience here, with a guess at what is causing this. My system is an IBM ThinkPad X20. Note I am not really a kernel hacker, and the move in CURRENT to threads has really dated my knowledge.] -- Moving from FreeBSD 5.1beta2 to a slightly post-release CURRENT signals have stopped working under bash and sh for ordinary users (but not for root). Creating a user from scratch verified that the problem did not stem from initialization process problems. The following patch to trap.c might have a failure in the logic by replacing the call via PCPU_GET(spinlocks) by the direct reference to the thread-critnest, but this is just a guess. *** /usr/src-5.1-BETA2/sys/i386/i386/trap.c Wed Apr 30 19:59:27 2003 --- /usr/src-QUIP/sys/i386/i386/trap.c Sat Jun 7 09:34:34 2003 *** *** 222,231 type); /* * Page faults need interrupts diasabled until later, !* and we shouldn't enable interrupts while holding a !* spin lock. */ ! if (type != T_PAGEFLT PCPU_GET(spinlocks) == NULL) enable_intr(); } } --- 224,233 type); /* * Page faults need interrupts diasabled until later, !* and we shouldn't enable interrupts while in a !* critical section. */ ! if (type != T_PAGEFLT td-td_critnest == 0) enable_intr(); } } -- Mark Evenson [EMAIL PROTECTED] A screaming comes across the sky. It has happened before, but there is nothing to compare to it now. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
On Thu, 2003-06-12 at 08:14, Anthony Naggs wrote: Sorry, I don't understand this comment. All OHCI, UHCI EHCI USB controllers need PCI bus mastering in order to read update their various lists of pending completed transfers. That was speculation on my part as to why bus mastering was not being explicitly activated (i.e. maybe somebody had problems with it). It may just be that the BIOS always turns it on for the PCI version so there was never a need to. Should we do this on uhci as well? Does anyone know if a such as thing as a cardbus uhci controller even exists? -Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Apparent i386 alloca.S bug (was: adsl/pppoe no longerconnecting on 5.1)
On Thu, 12 Jun 2003 22:22:07 +1000, Tim Robbins [EMAIL PROTECTED] said: builtin alloca() until we figure out how to fix the one in libc. It is fundamentally impossible to ``fix'' the alloca() implementation in libc. alloca() CANNOT be implemented that way. If GCC's builtin alloca() is disabled by requesting a strict Standard C environment (which is not appropriate for FreeBSD anyway), then alloca() is just an ordinary user symbol and programs expecting the implementation to supply it should simply fail. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
On Thu, 12 Jun 2003 15:38:49 +1000, Tim Robbins [EMAIL PROTECTED] said: Misbehaving in what way? CSTD=c99 causes gcc to use alloca() from libc instead of its builtin version. Perhaps alloca() in libc is broken -- any bugs in it would have been covered up by gcc until now. alloca() in libc is *fundamentally* broken. Only the compiler can know the current state of the stack frame, and that information is not necessarily available to library functions. On some architectures it is not even possible for a library function to adjust its caller's stack frame, which is why alpha, ia64, and sparc64 don't have an alloca.S (nor an alloca.c for that matter). -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP in 5.1 cant deactivate hyperthreading
On Thu, 12 Jun 2003, Killing wrote: - Original Message - From: Doug White [EMAIL PROTECTED] sysctl machdep.hlt_logical_cpus: machdep.hlt_logical_cpus: 1 Halting them will still cause the CPUs to be detected. They just won't do any useful work. Yep but the issue is that all the core admin tools are unaware of this and hence include the virtual cores in idle calcs etc making load monitoring impossible without nasty cludges :( So what's the way forward? 1. Dont just use halt have a compile or other directive to disable them? 2. Update all tools to be halt aware? Personally I'd go with 2 all be it more work / ramifications on other 3rd party tools as it gives the benefit of also working when physical CPU's are halted. Well, hyperthreading can be disabled via a kernel directive, right? Which ever it needs someone to pick it up ASAP dont you think? Really? What's the hurry? FreeBSD 5.x isn't even bootable/installable on a number of SMP machines yet (ex. Dell Poweredge 6350). Steve Tom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP in 5.1 cant deactivate hyperthreading
Well, hyperthreading can be disabled via a kernel directive, right? From what I've seen that was removed between 5.0 and 5.1 correct me if Im wrong. Which ever it needs someone to pick it up ASAP dont you think? Really? What's the hurry? FreeBSD 5.x isn't even bootable/installable on a number of SMP machines yet (ex. Dell Poweredge 6350). I suppose the hurry is that basic utils that we use day to day like top and vmstat to monitor machine load cannot be trusted to give accurate info. Yes 5.X is still new tech and may not run on all machines but on the ones which it does ( and it runs very well here ) basic tools are required. If it doesn't run on a machine your under know false impressions, if however you users complain of performance issues and you look @ top and it says 50% idle and its really 0% idle its a different matter. Steve / K ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
Garrett Wollman wrote: alloca() in libc is *fundamentally* broken. Only the compiler can know the current state of the stack frame... Sounds like alloca() should simply be stricken from libc on all architectures. Might also be a good idea to begin removing uses of it. Searching through the source tree, I note that there's only a handful of uses of alloca outside of contrib and gnu. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Interest in nvidia-driver debugging on 5-*
I am highly interested in getting nvidia-driver to work well for FBSD, and in particular my own computer. I do not have the expertise to hack on either it or the kernel (yet), but I am eager to provide debugging information. nvidia-driver frequently crashes my machine, so I expect that my input could be valuable. Is anybody interested in my assistance? Is anybody actively working on/with/around the nvidia-driver, or does the license make that infeasible? Thanks a bundle, Evan Dower Undergraduate, Computer Science University of Washington _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
On Thu, 12 Jun 2003 11:37:03 -0700, Tim Kientzle [EMAIL PROTECTED] said: Sounds like alloca() should simply be stricken from libc on all architectures. Yes. (For values of `all' being `i386'.) Might also be a good idea to begin removing uses of it. Not necessarily. There's nothing wrong, intrinsically, with using alloca(), although much but not all of the purpose has been subsumed by variable-length arrays which I think are in C99. One merely has to be aware that it is not part of Standard C (any more than a thousand other interfaces in FreeBSD) which must be implemented in the compiler; therefore, one cannot expect programs which expect alloca(3) to be available and have the standard semantics to work when compiled with a strictly conforming compiler. Most compilers do implement alloca(). -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interest in nvidia-driver debugging on 5-*
On 2003-06-12 11:51 +, Evan Dower wrote: I am highly interested in getting nvidia-driver to work well for FBSD, and in particular my own computer. I do not have the expertise to hack on either it or the kernel (yet), but I am eager to provide debugging information. nvidia-driver frequently crashes my machine, so I expect that my input could be valuable. Is anybody interested in my assistance? Is anybody actively working on/with/around the nvidia-driver, or does the license make that infeasible? Thanks a bundle, Evan Dower Undergraduate, Computer Science University of Washington NVIDIA is handling everything to do with the driver. Expect a new release shortly *cough*. Until then, perhaps some of the information in the FAQ will help you: http://www.soulwax.net/nvidia/faq.shtml Good luck. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interest in nvidia-driver debugging on 5-*
I was afraid that might be the case :-( From: Munish Chopra [EMAIL PROTECTED] On 2003-06-12 11:51 +, Evan Dower wrote: I am highly interested in getting nvidia-driver to work well for FBSD, and in particular my own computer. I do not have the expertise to hack on either it or the kernel (yet), but I am eager to provide debugging information. nvidia-driver frequently crashes my machine, so I expect that my input could be valuable. Is anybody interested in my assistance? Is anybody actively working on/with/around the nvidia-driver, or does the license make that infeasible? Thanks a bundle, Evan Dower Undergraduate, Computer Science University of Washington NVIDIA is handling everything to do with the driver. Expect a new release shortly *cough*. Until then, perhaps some of the information in the FAQ will help you: http://www.soulwax.net/nvidia/faq.shtml Good luck. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
build flags for a 386DX (5.1)
[escalated from -questions] Hi folks- I am setting up FreeBSD 5.1-RELEASE on a 386DX. I'm mostly doing it as a learning exercise (or perhaps because I'm a masochist), but the machine may be used as a firewall at some point. I have the OS installed with a custom kernel, and things are actually going quite well. There are (of course) some problems though. Most of the userland utilities work great, but some just dump core. The one I miss in particular is groff (for manpages, etc). I suspect that the problems are a result of CPU instructions that the poor 386 doesn't understand. I do have a separate build machine (soon to be running 5.1 as well), so I'd like to recompile everything (kernel, world, and ports-to-be-made-into-packages) for the 386 with the appropriate flags to gcc and friends. Hopefully that will take care of the issues I'm seeing. So my question is, what flags should I use and where should I put them? I'd like to be able to switch easily between builds for the 386 and normal builds (for everything else). Can I just put an override in /etc/make.conf or do I have to futz with /usr/share/mk/bsd.cpu.mk? (In the case of the latter, detailed hints would be appreciated.. I don't grok Make all that well yet.) Thanks, JN ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
user confusion
Hi This might be a common error/misconfiguration, but i've been unable to locate it in the archives.. Using 5.1-RELEASE (upgraded from 5.0 through buildkernel/buildworld). I'm seeing the following strangeness I login as a normal user, run who .. shows my own username as logged in. su to another user, logout (back to my own uid), run who, and su'ed user is still listed for my session. Here's a little screenshot (names have been changed to protect the innocent :* ) -bash-2.05b$ w 11:09PM up 2 days, 11:27, 2 users, load averages: 1.19, 1.17, 1.16 USER TTY FROM LOGIN@ IDLE WHAT test1p0 xxx.xx.x.xxx 11:09PM - w -bash-2.05b$ su - test2 Password: Last login: Thu Mar 6 18:39:11 from something.somewhere. -su-2.05b$ w 11:09PM up 2 days, 11:27, 2 users, load averages: 1.24, 1.18, 1.17 USER TTY FROM LOGIN@ IDLE WHAT test2p0 -11:09PM - w -su-2.05b$ logout -bash-2.05b$ w 11:09PM up 2 days, 11:27, 2 users, load averages: 1.22, 1.18, 1.17 USER TTY FROM LOGIN@ IDLE WHAT test2p0 -11:09PM - w -bash-2.05b$ who am i test2ttyp0Jun 12 23:09 uname -a gives the following : FreeBSD some.where.com 5.1-RELEASE FreeBSD 5.1-RELEASE #16: Tue Jun 10 11:24:37 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KCONF i386 Any ideas ??. thought i'd run it though -current before submitting to bugs. Jimmy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
Bernd Walter wrote this message on Thu, Jun 12, 2003 at 14:30 +0200: On Thu, Jun 12, 2003 at 01:10:24AM -0700, John-Mark Gurney wrote: Craig Boston wrote this message on Wed, Jun 11, 2003 at 22:44 -0500: pci_enable_busmaster(self); near the top of ohci_attach() in ohci_pci.c ...and it worked! I believe my first words upon seeing ums0: blah blah were You have GOT to be kidding me. Hey, thanks for the great work. This got me past the same problem on the sparc box I have, but now I'm getting tons of: usb0: 198 scheduling overruns usb is not available on other 64 bit platforms than alpha. We need busdma support in the controller drivers first. Is someone working on this? -- 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: CSTD=c99 breaks package creation
On Wed, Jun 11, 2003 at 07:37:01PM -0700, Kris Kennaway wrote: On Tue, Jun 10, 2003 at 04:38:58AM -0700, Kris Kennaway wrote: A couple of ports are creating broken bzip2 archives since I updated the build environments to 5.1-CURRENT: ... Backing out the recent changes to bsd.sys.mk fixed these problems. I don't know why, but pkg_create was creating packages that were truncated - perhaps tar was closing the pipe early or something. It's possible that there's either a bug in gcc or there is C code in the system that has a different meaning when interpreted to C99 standards. If you can wait until after USENIX, I'll track this down. Is there any more data than this email you can send me? -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP in 5.1 cant deactivate hyperthreading
Killing wrote this message on Thu, Jun 12, 2003 at 18:47 +0100: I suppose the hurry is that basic utils that we use day to day like top and vmstat to monitor machine load cannot be trusted to give accurate info. Actually, the basic tools ARE correct, there is a cpu sitting idle that the sysadmin disabled. So, if the sysadmin would reenable the cpu, then jobs could be dispatached to it. Would you rather some junior admin go and disable the cpu, and then six months later wondering why the performance is so slow? Yes 5.X is still new tech and may not run on all machines but on the ones which it does ( and it runs very well here ) basic tools are required. If it doesn't run on a machine your under know false impressions, if however you users complain of performance issues and you look @ top and it says 50% idle and its really 0% idle its a different matter. That's a good way to remind the admin to turn the cpu back on. Now is there any good reason why you need to keep the cpu disabled? -- 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]
Understanding newPCM driver
Hi I wish to teach FreeBSD (5.0-CURRENT, somewhere in mid-may, last cvsup was week ago) make use of that fancy S/P-DIF connector on my Yamaha soundcard. OTOH, I want to implement it in a Right Way (tm), so that one can choose, whether he wish to use or not to use this feature, if it's present. Which is the Right Way(tm) to add such functionality to existing newPCM driver? PS: I'm crossposting both -hackers and -current... -- Artem 'Zazoobr' Ignatjev [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Duplicate keys in CVSROOT/modules
On Thu, Jun 12, 2003 at 10:40:51AM +0200, Michael L. Hostbaek wrote: Cejka Rudolf (cejkar) writes: Is it possible to fix them? I sent a mail to the CVS repository Meisters yesterday, so it's just a matter of time before it will be fixed. Any committer can fix this -- just check out modules and add port_ in front of the ports one. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
On Wed, Jun 11, 2003 at 10:32:30PM -0700, Kris Kennaway wrote: alloca() is not being inlined when -std is specified. It is possible there's a bug in the libc implementation. I'm also suspicious that some of the ppp data structures have changed size or alignment which could be confusing netgraph. Acutally -std=c?9, -std=gnu?9 uses GCC's alloca. I don't mind finding all the alloca uses in the tree and compiling them with -std=gnu99 instead of -std=c99. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
On Thu, 12 Jun 2003, Kris Kennaway wrote: On Thu, Jun 12, 2003 at 12:44:51AM -0700, Kris Kennaway wrote: + leal24(%esp), %eax /* base of newly allocated space */ After I figured out what the 24(...) meant (add 24 to ...) it's clear that this isn't a fix (except in the special case of PPPoE support ;-). gcc's builtin inline alloca() is tuning that offset value at compile-time, so alloca.S is just broken (and has been since 386BSD, looks like), but it's beyond my pattern-monkey asm skills to fix. Something like that is needed just to realign the stack frame. Alignment of the (eventual) stack to at least a 16-byte boundary is now required. Since the required alignment depends on the compiler vendor version and flags, and possibly on the calling function's environment, this is impossible to do in all cases. It may be possible to keep current gcc cases working by not disturbing the the stack's alignment mod 16 relative to what it was when the function was called. I don't think misalignment of the stack could cause the current problems. Those are more likely to be caused by copy possible [sic] saved registers (see tjr's mail about pushl vs movl to the stack). Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CSTD=c99 breaks package creation
On Thu, Jun 12, 2003 at 02:43:42PM -0700, David O'Brien wrote: On Wed, Jun 11, 2003 at 07:37:01PM -0700, Kris Kennaway wrote: On Tue, Jun 10, 2003 at 04:38:58AM -0700, Kris Kennaway wrote: A couple of ports are creating broken bzip2 archives since I updated the build environments to 5.1-CURRENT: ... Backing out the recent changes to bsd.sys.mk fixed these problems. I don't know why, but pkg_create was creating packages that were truncated - perhaps tar was closing the pipe early or something. It's possible that there's either a bug in gcc or there is C code in the system that has a different meaning when interpreted to C99 standards. If you can wait until after USENIX, I'll track this down. Is there any more data than this email you can send me? tjr has a fix. Kris pgp0.pgp Description: PGP signature
pci probing fixed (was Re: PCI bus numbering and orphaned devices)
Well, I implemented PCI probing as per the UltraSparc IIi user's manual, and now, I get quite a bit more than I bargined for: bash-2.05b$ pciconf -l | wc 38 2283106 The complete pciconf -l -v is at: http://people.freebsd.org/~jmg/pciconf-lv.sparc64 Now, I seem to be getting duplicates on some functions, and then of course, I am now seeing the firewire part of the SME2300BGA that doesn't have a phys attached to it. (The driver does attach to the firewire part, but fails trying to talk to the phys.) This also required updating the pci_read_device to ignore a all zero return value for PCIR_DEVVENDOR, and not probe higher functions in that case. If I tried to probe higher functions (such as 0.0.2), the system would hang. A dmesg output of the boot is at: http://people.freebsd.org/~jmg/dmesg.sparc64 I don't include the dmesg that shows me attaching the firewire driver. I have posted the patch to produce this at: http://people.freebsd.org/~jmg/sparc.patch Warning, this contains much debugging data, and probes for PCI devices that previously didn't get probed for. P.S. Sorry for the duplicate post to -sparc64. I forgot that some of the -current crowd is interested in this work 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]
5.1-RELEASE can't find SIL 0680 IDE controller
Hello everyone, First off, let me express my appreciation for all of the hard work that has been put into the 5.1-RELEASE of FreeBSD. I have installed it, and am extremely happy with the way that it performs on my system. Having said that, here is my dilemma: I have a Silicon Image 0680 IDE hard drive controller that (for the most part) works flawlessly in FreeBSD. The problem is that it gets detected during the boot process *ONLY IF* I first boot into another operating system (Linux, in my case), issue the 'shutdown -r now' command, and then reboot into FreeBSD. If I power up the system and immediately try booting FreeBSD, it is not found. I don't recall having this problem using 5.0-RELEASE, if that is any help. If I can provide any further information, please let me know. Thanks in advance, Mike _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pci probing fixed (was Re: PCI bus numbering and orphaneddevices)
On Thu, Jun 12, 2003 at 03:56:32PM -0700, John-Mark Gurney wrote: Well, I implemented PCI probing as per the UltraSparc IIi user's manual, and now, I get quite a bit more than I bargined for: bash-2.05b$ pciconf -l | wc 38 2283106 The complete pciconf -l -v is at: http://people.freebsd.org/~jmg/pciconf-lv.sparc64 Now, I seem to be getting duplicates on some functions, and then of course, I am now seeing the firewire part of the SME2300BGA that doesn't have a phys attached to it. (The driver does attach to the firewire part, but fails trying to talk to the phys.) Maybe they are not really disabled. This also required updating the pci_read_device to ignore a all zero return value for PCIR_DEVVENDOR, and not probe higher functions in that case. If I tried to probe higher functions (such as 0.0.2), the system would hang. The only defined invalid vendor number is 0x. The pcispace read functions should return all bits set in case a device does not exist. A dmesg output of the boot is at: http://people.freebsd.org/~jmg/dmesg.sparc64 I don't include the dmesg that shows me attaching the firewire driver. I have posted the patch to produce this at: http://people.freebsd.org/~jmg/sparc.patch If the sparc64 part is the right way to do has to be commented by the sparc64 guys. Your patch still probes for additional functions without checking if the device really is a multifunction device. There are devices out there that react on every function although they are single function. Can you check this together with Warners patch? Maybe we can also keep the original code, as the problem was not not of machine independent nature as I originaly tought. Warning, this contains much debugging data, and probes for PCI devices that previously didn't get probed for. P.S. Sorry for the duplicate post to -sparc64. I forgot that some of the -current crowd is interested in this work too. If it changes MI part - yes. -- 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: Apparent i386 alloca.S bug (was: adsl/pppoe no longerconnectingon 5.1)
On Thu, 12 Jun 2003, Tim Robbins wrote: On Thu, Jun 12, 2003 at 06:29:44PM +1000, Tim Robbins wrote: Here's a test program for the i386 alloca() bug. Compile with -std=gnu89 (or no -std option) and it works fine. Compile with -std=c99 or -std=c89 and it breaks like this: corruption: 05 should be 0xcc at offset 0 corruption: 00 should be 0xcc at offset 1 corruption: 00 should be 0xcc at offset 2 corruption: 00 should be 0xcc at offset 3 Interestingly, gcc -std=c89 on FreeBSD 4.8 doesn't trigger the bug. I should mention that you need to compile with -march=pentiumpro to trigger the bug. It's related to the way gcc 3 uses movl x,y(%esp) instead of pushl x when passing arguments to a function. I suggest backing out the commit that made CSTD=c99 the default, so that we go back to using gcc's builtin alloca() until we figure out how to fix the one in libc. I understand this now. This method of passing args is completely incompatible with any implementation of the libc alloca like the current one. gcc prepares space for storing the args by subtracting from %esp. Then the libc alloca() points %esp to the allocated space, but gcc thinks that %esp still points to the space that it has reserved for the args, so it clobbers the allocated space when it stores the args. BTW, the optimization of using movl x,y(%esp) instead of pushl x has the following benefits and costs: pentiumpro-like machine (old Celeron): +26% (4.05 seconds reduced to 2.99 seconds) pentiumpro-like machine (PIII (freefall)): +25% (1.82 seconds reduced to 1.37 seconds) AthlonXP: -45% (0.58 seconds increaded to 0.84 seconds) The times are for 10^8 calls to somefunc(1, 2, 3, 4, 5) in a loop. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pci probing fixed (was Re: PCI bus numbering and orphaneddevices)
Bernd Walter wrote this message on Fri, Jun 13, 2003 at 01:23 +0200: Your patch still probes for additional functions without checking if the device really is a multifunction device. I just now realized that the MFDEV ment Multi-Function device! Now the patch to pci.c makes perfect sense. There are devices out there that react on every function although they are single function. Can you check this together with Warners patch? Thanks, I've been having a conversation with gibbs (via proxy through dwhite) and he suggested the same thing. The good news is that this now works properly. I have posted the updated stuff at: http://people.FreeBSD.org/~jmg/dmesg.sparc64.v2 http://people.FreeBSD.org/~jmg/pciconf-lv.sparc64.v2 http://people.FreeBSD.org/~jmg/sparc.patch.v2 I will of course revert pci_read_device back to it's original state since the MFDEV patch makes it unnecessary. Maybe we can also keep the original code, as the problem was not not of machine independent nature as I originaly tought. Warning, this contains much debugging data, and probes for PCI devices that previously didn't get probed for. P.S. Sorry for the duplicate post to -sparc64. I forgot that some of the -current crowd is interested in this work too. If it changes MI part - yes. Looks like it will change it some. -- 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: SMP in 5.1 cant deactivate hyperthreading
Original Message - From: John-Mark Gurney [EMAIL PROTECTED] Yes 5.X is still new tech and may not run on all machines but on the ones which it does ( and it runs very well here ) basic tools are required. If it doesn't run on a machine your under know false impressions, if however you users complain of performance issues and you look @ top and it says 50% idle and its really 0% idle its a different matter. That's a good way to remind the admin to turn the cpu back on. Don't by it there just checking sysctl is easy enough. Now is there any good reason why you need to keep the cpu disabled? Its disabled by default due to performance reasons and we keep it that way. We are talking hyperthreading, logical CPU's, not real physical CPU's. Its quite easy to see if CPU's are disabled as mentioned above. If you check the release notes for top then you'll see a similar fix had to be made for sunos5 in beta5 iirc. Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pci probing fixed (was Re: PCI bus numbering and orphaneddevices)
John-Mark Gurney wrote this message on Thu, Jun 12, 2003 at 16:52 -0700: I will of course revert pci_read_device back to it's original state since the MFDEV patch makes it unnecessary. Ok, here is just the pci MFDEV patch. I would like to see if this works on other arch's, at a minimum, that things don't change and devices disappear. http://people.freebsd.org/~jmg/pci.mfdev.patch This patch compiles fine on Sparc, but requires the data access error trap patch to run. The patch is at: http://people.freebsd.org/~jmg/sparc.dae.patch Testing would be wecome. Thanks. -- 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]
make installworld fails on 5.1 REL
hi, im moving from beta1 to 5.1 release, I build a new kernel, booted. rm -rf /usr/obj did make buildworld, and when I do make installworld I get this: Running test variables PASS: Test variables detected no regression, output matches. Running test targets PASS: Test targets detected no regression. Running test sysvmatch PASS: Test sysvmatch detected no regression. Running test lhs_expn PASS: Test lhs_expn detected no regression. Running test notdef PASS: Test notdef detected no regression. Running test modifiers PASS: Test modifiers detected no regression. Running test funny_targets PASS: Test funny_targets detected no regression. Checking to see if your booted kernel is fresh enough.. /usr/obj/usr/src/bin/sh/sh -c 'echo Testing installed kernel for new sigaction(2) syscall' Testing installed kernel for new sigaction(2) syscall Seems ok.. mkdir -p /tmp/install.XG0p8Esu for prog in [ awk cap_mkdb cat chflags chmod chown date echo egrep find grep ln make mkdir mtree mv pwd_mkdb rm sed sh sysctl test true uname wc zic; do cp `which $prog` /tmp/install.XG0p8Esu; done cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy/usr/share/tmac PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/tmp/install.XG0p8Esu make -f Makefile.inc1 reinstall make: Permission denied *** Error code 126 Stop in /usr/src. *** Error code 1 Stop in /usr/src. whats wrong here ? thx for help! Christophe -- Christophe Zwecker mail: [EMAIL PROTECTED] Hamburg, Germanyfon: +49 179 3994867 http://www.zwecker.de Who is General Failure ? And why is he reading my disk ?? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ALTQ for FreeBSD 5.1?
Is anyone working on ALTQ intergration for FreeBSD 5.1? Looks like the FreeBSD-ALTQ went drop dead, as they havent made anything new since the release of FreeBSD 5.0.(http://www.rofug.ro/projects/freebsd-altq/) Erik. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make installworld fails on 5.1 REL
On Fri, Jun 13, 2003 at 02:56:35AM +0200, Christophe Zwecker wrote: hi, im moving from beta1 to 5.1 release, I build a new kernel, booted. rm -rf /usr/obj did make buildworld, and when I do make installworld I get AFAIK, this isn't one of the documented methods for upgrading a system. Oh well. GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy/usr/share/tmac PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/tmp/install.XG0p8Esu make -f Makefile.inc1 reinstall make: Permission denied *** Error code 126 What is the security level for the system? -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ for FreeBSD 5.1?
On Fri, Jun 13, 2003 at 03:04:52AM +0200, Erik Paulsen Skaalerud wrote: Is anyone working on ALTQ intergration for FreeBSD 5.1? Looks like the FreeBSD-ALTQ went drop dead, as they havent made anything new since the release of FreeBSD 5.0.(http://www.rofug.ro/projects/freebsd-altq/) I recently took interest in this (about a month ago) and had ALTQ port updated to work with the latest 5.0. The only issue I have had was with fxp and TBR magic; once I find an fxp(4) guru, I will get that sorted. The version that is available at the website is about a year old (august 2002 ish), and there have been substantial changes to the kernel since then. Other than that, I have got it working... Cheers. -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make installworld fails on 5.1 REL
David Wolfskill wrote: kern_securelevel_enable set (in /etc/rc.conf)? Peace, david its set to NO. should it be YES ? cu Christophe -- Christophe Zwecker mail: [EMAIL PROTECTED] Hamburg, Germanyfon: +49 179 3994867 http://www.zwecker.de Who is General Failure ? And why is he reading my disk ?? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ALTQ for FreeBSD 5.1?
Is anyone working on ALTQ intergration for FreeBSD 5.1? [...] I recently took interest in this (about a month ago) and had ALTQ port updated to work with the latest 5.0. The only issue I have had was with fxp and TBR magic; once I find an fxp(4) guru, I will get that sorted. If you're looking for a fxp hacker, mux is the one you want ([EMAIL PROTECTED]). He's also on irc.freenode.net with the same nickname. The version that is available at the website is about a year old (august 2002 ish), and there have been substantial changes to the kernel since then. Other than that, I have got it working... Good! Too bad that I only use fxp cards, so I'm pretty bummed right now. Erik. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE can't find SIL 0680 IDE controller
On Thursday, June 12, 2003, at 06:15 PM, Mike Schreckengost wrote: Hello everyone, First off, let me express my appreciation for all of the hard work that has been put into the 5.1-RELEASE of FreeBSD. I have installed it, and am extremely happy with the way that it performs on my system. Having said that, here is my dilemma: I have a Silicon Image 0680 IDE hard drive controller that (for the most part) works flawlessly in FreeBSD. The problem is that it gets detected during the boot process *ONLY IF* I first boot into another operating system (Linux, in my case), issue the 'shutdown -r now' command, and then reboot into FreeBSD. If I power up the system and immediately try booting FreeBSD, it is not found. I had a friend who had an ISA PNP sound card that did that exact thing with linux. He had to initialize it with DOS then reboot and it worked... Sounds like some PCI initialization/detection bug? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Makefile.yp aka /var/yp/Makefile.dist
In the last episode (Jun 11), Ruslan Ermilov said:
Just as a precaution, does anyone have any objections to my removing
of these funny $^ sequences from Makefile.yp? They were apparently
used to insert something into the map generation pipeline just before
the yp_mkdb(8) invokation, but recent additions to this file did not
follow this rule.
ypservers: $(YPSERVERS)
@echo Updating [EMAIL PROTECTED]
$(CAT) $(YPSERVERS) | \
- $(AWK) '{ if ($$1 != $$1 !~ ^#.*) print $$0\t$$0 }' $^ \
+ $(AWK) '{ if ($$1 != $$1 !~ ^#.*) print $$0\t$$0 }' \
| $(DBLOAD) -i $(YPSERVERS) -o $(YPMAPDIR)/$@ - $(TMP); \
$(RMV) $(TMP) $@
@$(DBLOAD) -c
$^ is gmake syntax for all prerequisites, but bsd make has never
recognized that particular variable, so afaik it has always been
ignored (rev 1.1 even has them).
There's also a useless use of cat in there. If you wanted, you could
do something like this (for all targets except netgroup, which calls
revnetgroup inbetween cat and awk):
ypservers: $(YPSERVERS)
@echo Updating [EMAIL PROTECTED]
- $(CAT) $(YPSERVERS) | \
- $(AWK) '{ if ($$1 != $$1 !~ ^#.*) print $$0\t$$0 }' $^ \
+ $(AWK) '{ if ($$1 != $$1 !~ ^#.*) print $$0\t$$0 }' $(YPSERVERS) \
| $(DBLOAD) -i $(YPSERVERS) -o $(YPMAPDIR)/$@ - $(TMP); \
$(RMV) $(TMP) $@
@$(DBLOAD) -c
--
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interest in nvidia-driver debugging on 5-*
Evan Dower wrote: I am highly interested in getting nvidia-driver to work well for FBSD, and in particular my own computer. I do not have the expertise to hack on either it or the kernel (yet), but I am eager to provide debugging information. nvidia-driver frequently crashes my machine, so I expect that my input could be valuable. Is anybody interested in my assistance? Is anybody actively working on/with/around the nvidia-driver, or does the license make that infeasible? As was pointed out the other day, nVidia use the %gs register without saving and restoring it, in order to maintain their internal thread state. Now that FreeBSD also uses this register, that causes crashes. I believe the fix is as simple as saving and restoring %gs in the nVidia driver, and/or not letting the nVidia use %gs at all (segment registers generally belong to the OS, in any case, and stealing a CPU register of any kind for exclusive use of a driver is a pig trick). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interest in nvidia-driver debugging on 5-*
Evan Dower wrote: NVIDIA is handling everything to do with the driver. Expect a new release shortly *cough*. I was afraid that might be the case :-( The only thing you care about is entry and exit through driver entry points... and maybe interrupts. It would be easy enough to wrapper all entry points to restore %gs on entry and save it on exit. For the interrupt handler, you would have to mess with the registration mechanism to wrap that. You might be able to get by with poking wrapper routines into the device declaration entry points on module registration with an if nVidia hack. This type of hack would actually be best, from the perspective of the performance of everything else, since it would be a one time setup, instead of something that has to be checked on each entry to see if it's happened yet. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bluetooth 20030604 and 5.1 release
Thanks for all the bluetooth help, I am having one more problem and I was hoping that you could help me. Following the instructions from: http://www.oook.cz/bsd/bluetooth.html I try to start bluetooth with: /etc/rc.bluetooth start ubt0 The result is: Could not execute command reset. Operation timed out My bluetooth device is from broadcom. dmesg captures it as: ubt0: Broadcom product 0x2033, rev 1.01/0.a0, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 4) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320 Also, in dmesg, after I run /etc/rc.bluetooth start ubt0, it says: ng_hci_process_command_timeout: ubt0hci - unable to complete HCI command OGF=0x3, OCF=0x3. Timeout ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15) The output from usbdevs -v -d is: addr 1: full speed, self powered, config 1, UHCI root hub(0x), VIA(0x), rev 1.00 uhub0 port 1 addr 2: full speed, power 100 mA, config 1, product 0x2033(0x2033), Broadcom(0x0a5c), rev 0.a0 ubt0 port 2 addr 3: full speed, power 100 mA, config 1, eUSB MemoryStick Reader(0x0314), SCM Microsystems Inc.(0x04e6), rev 5.07 umass0 Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x), VIA(0x), rev 1.00 uhub1 port 1 powered port 2 powered I don't really understand what the errors mean and I would appreciate it if anyone could help me. If you need more information, please ask. Thanks all for the assistance. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interest in nvidia-driver debugging on 5-*
Hey, I believe the fix is as simple as saving and restoring %gs in the nVidia driver, and/or not letting the nVidia use %gs at all (segment registers generally belong to the OS, in any case, and stealing a CPU register of any kind for exclusive use of a driver is a pig trick). Please take a look at http://www.minion.de/ Christian Zander has written a patch to deal with the gs restoration problem and other issues. It is well tested and adopted. Maxime Henrion has also written several patches which may be found in the ports system (x11/nvidia-driver). I think Terry is jumping to conclusions on what Evan's problem could be. I have this seen this cause application to crash at exit (if using OpenGL) but never a crash in kernel-space from the nVidia drivers. -- +---+ | Samy Al Bahra | [EMAIL PROTECTED] | +---+ Arabeyes.org Kerneled.com FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interest in nvidia-driver debugging on 5-*
On 13 Jun 2003 05:11:34 +, Samy Al Bahra [EMAIL PROTECTED] wrote: Hey, I believe the fix is as simple as saving and restoring %gs in the nVidia driver, and/or not letting the nVidia use %gs at all (segment registers generally belong to the OS, in any case, and stealing a CPU register of any kind for exclusive use of a driver is a pig trick). Please take a look at http://www.minion.de/ Christian Zander has written a patch to deal with the gs restoration problem and other issues. It is well tested and adopted. Maxime Henrion has also written several patches which may be found in the ports system (x11/nvidia-driver). The %gs register issue patch for linux_sysvec.c has been committed in the source tree like a month ago or so, btw. :-) Cheers, Mezz I think Terry is jumping to conclusions on what Evan's problem could be. I have this seen this cause application to crash at exit (if using OpenGL) but never a crash in kernel-space from the nVidia drivers. -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bluetooth 20030604 and 5.1 release
Hello, Did you download firmware into the device? Broadcom BCM2033 chip based device will not work without firmware. The snapshot comes with firmware download driver ubtbcmfw(4) and firmware download utility bcmfw(8). In order to make Broadcom device work you need to 1) load ubtbcmfw.ko module 2) load ng_ubt.ko module 3) use bcmfw utility to download mini driver and firmware images You should see ubtbcmfw(4) driver attach to the device first. After you download firmware the device should detach itself and ng_ubt(4) driver should attach to it. After that you can use rc.bluetooth script. Due to copyright issues I can not provide mini driver and firmware images for device. The firmware files can be fetched as part of http://bluez.sourceforge.net/download/bluez-bluefw-0.9.tar.gz thanks, max --- User Toyboy [EMAIL PROTECTED] wrote: Thanks for all the bluetooth help, I am having one more problem and I was hoping that you could help me. Following the instructions from: http://www.oook.cz/bsd/bluetooth.html I try to start bluetooth with: /etc/rc.bluetooth start ubt0 The result is: Could not execute command reset. Operation timed out My bluetooth device is from broadcom. dmesg captures it as: ubt0: Broadcom product 0x2033, rev 1.01/0.a0, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 4) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320 Also, in dmesg, after I run /etc/rc.bluetooth start ubt0, it says: ng_hci_process_command_timeout: ubt0hci - unable to complete HCI command OGF=0x3, OCF=0x3. Timeout ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15) The output from usbdevs -v -d is: addr 1: full speed, self powered, config 1, UHCI root hub(0x), VIA(0x), rev 1.00 uhub0 port 1 addr 2: full speed, power 100 mA, config 1, product 0x2033(0x2033), Broadcom(0x0a5c), rev 0.a0 ubt0 port 2 addr 3: full speed, power 100 mA, config 1, eUSB MemoryStick Reader(0x0314), SCM Microsystems Inc.(0x04e6), rev 5.07 umass0 Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x), VIA(0x), rev 1.00 uhub1 port 1 powered port 2 powered I don't really understand what the errors mean and I would appreciate it if anyone could help me. If you need more information, please ask. Thanks all for the assistance. __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
