Re: ATAng issues status report
On Fri, 10 Oct 2003, Soren Schmidt wrote: > It seems Nate Lawson wrote: > > Here is an updated status of ATAng for me. I periodically test it to see > > if any of the following problems go away. > > > > * Panic occurs after ATAFD fails to probe. Last event: 2003/10/6 > > I have no ATAFD device on my system and normally no messages are printed > > about it on boot. However, periodically ATAFD will print a bunch of > > messages on console about failing to probe. The machine works normally > > but at some point during use, it panics with a re-use of freed memory, > > last user was ATAFD. Most of the time the machine doesn't print anything > > about ATAFD and there is no panic but maybe 1/5 reboots it does. > > This should be fixed in current. Fixed for me. Sometimes acd0 takes a little longer to probe but otherwise I have not been able to recreate the panic now. > > * Resume fails, hanging with drive light on. Last event: 2003/10/2 > > Appears to be a lost interrupt during reset. > > I've just committed some changes that makes suspend/resume work just > fine on the notebooks I have access to. This works great for me! I have suspended/resumed to S3 many times now, no problems. > > * Lost interrupt for ATA-SLAVE on reboot. Last event: 2003/10/7 > > I'm unsure if this is actually a problem but occasionally it prints a > > message right before rebooting about loosing an interrupt. I'll try to > > get more info. > > No idea about that on. It's gone as well. I can't reproduce any more whereas before I could reproduce often. So now I have no problems with ATAng and I can run it on all [EMAIL PROTECTED] panic ;-) Thanks again, Nate ___ [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-10-25 04:32:16 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-25 04:32:16 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-10-25 04:32:16 - 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-10-25 04:34:07 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: populating >>> /home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include >>> stage 4.2: building libraries [...] cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/include -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/../../include -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc -DPOSIX_MISTAKE -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/rpc -DYP -DHESIOD -c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/net/ip6opt.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/net/ip6opt.c: In function `inet6_option_append': /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/net/ip6opt.c:116: warning: comparison is always false due to limited range of data type /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/net/ip6opt.c: In function `inet6_opt_append': /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/net/ip6opt.c:425: warning: comparison is always false due to limited range of data type /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/net/ip6opt.c: At top level: /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/net/ip6opt.c:516: error: conflicting types for `inet6_opt_next' /home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include/netinet6/in6.h:674: error: previous declaration of `inet6_opt_next' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib. *** 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. *** 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-10-25 05:01:13 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-10-25 05:01:13 - TB --- ERROR: failed to build world TB --- 2003-10-25 05:01:13 - 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 alpha/alpha
TB --- 2003-10-25 04:00:00 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-25 04:00:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-10-25 04:00:00 - 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-10-25 04:04:44 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: populating >>> /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include >>> stage 4.2: building libraries [...] cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/include -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/../../include -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/alpha -D__DBINTERFACE_PRIVATE -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/../../contrib/gdtoa -DINET6 -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc -DPOSIX_MISTAKE -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/rpc -DYP -DHESIOD -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/net/ip6opt.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/net/ip6opt.c: In function `inet6_option_append': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/net/ip6opt.c:116: warning: comparison is always false due to limited range of data type /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/net/ip6opt.c: In function `inet6_opt_append': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/net/ip6opt.c:425: warning: comparison is always false due to limited range of data type /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/net/ip6opt.c: At top level: /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/net/ip6opt.c:516: error: conflicting types for `inet6_opt_next' /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include/netinet6/in6.h:674: error: previous declaration of `inet6_opt_next' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib. *** 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. *** 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-10-25 04:32:15 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-10-25 04:32:15 - TB --- ERROR: failed to build world TB --- 2003-10-25 04:32:15 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sound no longer works ... ?
On Fri, 24 Oct 2003, Munish Chopra wrote: > On 2003-10-24 23:39 -0300, Marc G. Fournier wrote: > > > > Just noticed that sound isnt' working on my laptop since my last upgrade > > (Oct 16), and one of our desktop's at the office is exhibiting the same > > thing ... > > > > Just CVSup new sources, and see nothing sound related having changed since > > my last one, so is this an isolated thing that nobody else is seeing? > > Sound's been working on all my builds, the latest one being from Oct > 21. I've got a few SBxxx's, mainly Ensoniq chipsets. I'm running: pcm0: mem 0xfea0-0xfeaf,0xfe00-0xfe3f irq 9 at device 8.1 on pci0 pcm0: on a Sony VAIO ... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sound no longer works ... ?
On 2003-10-24 23:39 -0300, Marc G. Fournier wrote: > > Just noticed that sound isnt' working on my laptop since my last upgrade > (Oct 16), and one of our desktop's at the office is exhibiting the same > thing ... > > Just CVSup new sources, and see nothing sound related having changed since > my last one, so is this an isolated thing that nobody else is seeing? Sound's been working on all my builds, the latest one being from Oct 21. I've got a few SBxxx's, mainly Ensoniq chipsets. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sound no longer works ... ?
Just noticed that sound isnt' working on my laptop since my last upgrade (Oct 16), and one of our desktop's at the office is exhibiting the same thing ... Just CVSup new sources, and see nothing sound related having changed since my last one, so is this an isolated thing that nobody else is seeing? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make buildworld problems on VIA C3
On Fri, Oct 24, 2003 at 04:14:02PM -0500, Greg Hogan wrote: > I am pretty new to buildworld and I am having the following problem: > > whenever I run 'make buildworld' I get errors when it gets to libfetch. > Specifically, i get compile errors in the file > /usr/src/lib/libfetch/common.c on lines 58-63. See the following links for > relevent information: This has been discussed here in about half a dozen emails today. Are you reading the mailing list as you are expected to when tracking -current? Kris pgp0.pgp Description: PGP signature
Re: fresh -current trap
> > Fatal trap 12: page fault while in kernel mode > > I just committed a fix for this to CVS. Sorry for the trouble. > > -- > Eric Anholt[EMAIL PROTECTED] This looks like the bug that was causing me trouble. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Checking the status of ATA raids in periodic daily ?
Hi, Any objections if I commit the below diff, and add the attached file as src/etc/periodic/daily/405.status-ata_raid ? Index: defaults/periodic.conf === RCS file: /home/ncvs/src/etc/defaults/periodic.conf,v retrieving revision 1.25 diff -u -r1.25 periodic.conf --- defaults/periodic.conf 1 Apr 2003 17:45:27 - 1.25 +++ defaults/periodic.conf 25 Oct 2003 00:15:52 - @@ -85,6 +85,9 @@ daily_status_disks_enable="YES"# Check disk status daily_status_disks_df_flags="-k -t nonfs" # df(1) flags for check +# 405.status-ata_raid +status_ata_raid_enable="YES" # Check ATA raid status + # 420.status-network daily_status_network_enable="YES" # Check network status daily_status_network_usedns="YES" # DNS lookups are ok Index: periodic/daily/Makefile === RCS file: /home/ncvs/src/etc/periodic/daily/Makefile,v retrieving revision 1.11 diff -u -r1.11 Makefile --- periodic/daily/Makefile 1 Apr 2003 20:32:01 - 1.11 +++ periodic/daily/Makefile 25 Oct 2003 00:15:52 - @@ -12,6 +12,7 @@ 310.accounting \ 330.news \ 400.status-disks \ + 405.status-ata_raid \ 420.status-network \ 430.status-rwho \ 440.status-mailq \ /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. #!/bin/sh # # $FreeBSD: $ # # If there is a global system configuration file, suck it in. # if [ -r /etc/defaults/periodic.conf ] then . /etc/defaults/periodic.conf source_periodic_confs fi case "$daily_status_ata_raid_enable" in [Yy][Ee][Ss]) echo echo 'Checking status of ATA raid partitions:' rc=0 for raid in `/usr/bin/find /dev/ -name 'ar[0-9]*' -type c \ | /usr/bin/egrep '[0-9]$' | /usr/bin/egrep -v 's[0-9]' \ | cut -d / -f 3` do status=`/sbin/atacontrol status $raid` echo $status raid_rc=`echo $status | grep -v READY | wc -l` [ $rc -eq 0 ] && [ $raid_rc -gt 0 ] && rc=3 done ;; *) rc=0;; esac exit $rc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 4.9-RC4 vs 5.1-CURRENT-20031021-JPSNAP
Hardware: Soekris Net4801 (ComBIOS 1.21), SanDisk 512MB Ultra Compact Flash Software: 5.1-CURRENT Symptom:ad0: FAILURE - SET_MULTI status=51 error=4 GEOM: create disk ad0 dp=0xc47ffb70 ad0: 488MB [993/16/63] at ata0-master PIO4 Result: system boots normally and runs without problems Hardware: Soekris Net4801 (ComBIOS 1.21), SanDisk 512MB Ultra Compact Flash Software: 4.9-RC4 Symptom:Read error (BIOS? initiated) Result: hung Note: Hardware in scenario #1 and scenario #2 are the same pieces of equipment (not just similar). Analysis(feeble): This Compact Flash card does not support multi-sector transfers required to boot. 5.1-CURRENT is compensating for this effect and continues. 4.9-RC4 punts (returning an error to the BIOS?). The recent delay of 4.9-RELEASE may indicate that there is some small window in which to obtain a fix for this problem in a "STABLE" release (before 5.2). I hope. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make buildworld problems on VIA C3
On Fri, 24 Oct 2003, Greg Hogan wrote: > I am pretty new to buildworld and I am having the following problem: > > whenever I run 'make buildworld' I get errors when it gets to libfetch. > Specifically, i get compile errors in the file > /usr/src/lib/libfetch/common.c on lines 58-63. See the following links for > relevent information: Known bug. Resup. -- 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]"
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-10-24 22:04:38 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-24 22:04:38 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-10-24 22:04:38 - 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-10-24 22:07:15 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: populating >>> /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4.2: building libraries [...] cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/ip6opt.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/ip6opt.c: In function `inet6_option_append': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/ip6opt.c:116: warning: comparison is always false due to limited range of data type /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/ip6opt.c: In function `inet6_opt_append': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/ip6opt.c:425: warning: comparison is always false due to limited range of data type /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/ip6opt.c: At top level: /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/ip6opt.c:516: error: conflicting types for `inet6_opt_next' /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/netinet6/in6.h:674: error: previous declaration of `inet6_opt_next' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc. *** Error code 1 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. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-10-24 22:32:51 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-10-24 22:32:51 - TB --- ERROR: failed to build world TB --- 2003-10-24 22:32:51 - 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 ia64/ia64
TB --- 2003-10-24 21:33:34 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-24 21:33:34 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-10-24 21:33:34 - 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-10-24 21:36:12 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: populating >>> /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include >>> stage 4.2: building libraries [...] cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/include -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/../../include -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc -DPOSIX_MISTAKE -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/rpc -DYP -DHESIOD -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/net/ip6opt.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/net/ip6opt.c: In function `inet6_option_append': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/net/ip6opt.c:116: warning: comparison is always false due to limited range of data type /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/net/ip6opt.c: In function `inet6_opt_append': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/net/ip6opt.c:425: warning: comparison is always false due to limited range of data type /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/net/ip6opt.c: At top level: /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/net/ip6opt.c:516: error: conflicting types for `inet6_opt_next' /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include/netinet6/in6.h:674: error: previous declaration of `inet6_opt_next' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib. *** 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. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-10-24 22:04:37 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-10-24 22:04:37 - TB --- ERROR: failed to build world TB --- 2003-10-24 22:04:37 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fresh -current trap
On Fri, 2003-10-24 at 05:39, Sergey A. Osokin wrote: > Hello, > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x60 > fault core= supervisor read, page not present > instruction pointer = 0x8:0xc04d6d42 > stack pointer = 0x10:0xde5b7624 > frame pointer = 0x10:0xde5b764c > 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 = 87 (sysctl) > kernel: trap 12 trap, code=0 > Stopped at_mtx_lock_sleep+0x1b2: movl0x68(%ecx),%edx > db> where > _mtx_lock_sleep(c2978c18,0,c07a85f4,e5,c12bfa80) at _mtx_lock_sleep+0x1b2 > _mtx_lock_flags(c2978c18,0,c07a85f4,e5,0) at _mtx_lock_flags+0x40 > radeon_bufs_info(c2973920,c2978c00,0,de5b7bf8,de5b7bf8) at radeon_bufs_info+0x6f > sysctl_root(0,de5b7c98,4,de5b7bf8,c29b85f0) at sysctl_root+0x14b > useland_sysctl(c29b85f0,de5b7c98,4,0,bfbff40c) at useland_sysctl+0x14d > __sysctl(c29b85f0,de5b7d10,18,c0509436,6) at __sysctl+0xd4 > syscall(2f,2f,2f,0,bfbff40c) at syscall+0x310 > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x280bed2f, esp = 0xbfbff38c, ebp > = 0xbfbff3b8 --- > > Any idea? I just committed a fix for this to CVS. Sorry for the trouble. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI trouble with EPIA-M
* Nate Lawson <[EMAIL PROTECTED]> [2003-10-24 22:57]: > Type "tr" at the DDB prompt to get a trace of what is hanging. At the time of the hang a 'ps' in DDB shows two screenful's of processes. Doing a simple 'tr' just gives the backtrace of how I got into DDB which - I presume - is not relevant to this problem. I have no serial console, so I have to copy things by hand. A ps shows (only selected columns): pid ... flag stat ... 38204 new [IWAIT] irq8: rtc 37204 new [IWAIT] irq4: sio0 36204 new [IWAIT] swi0: tty:sio 35204 [IWAIT] irq0: ppc0 34204 new [IWAIT] irq12: psm0 33204 [CPU0] irq1: atkbd0 32204 [IWAIT] irq15: ata1 31204 [IWAIT] irq14: ata0 30204 [SLP]usbdly 0x... usb2 29204 new [IWAIT] irq10: uhci2 pcm0 28204 [SLP] usbdly 0x... usb1 27204 [SLP] usbtsk 0x... usbtask 26204 [SLP] usbdly 0q... usb0 25204 new [IWAIT] irq11: vr0 uhci0 24204 [IWAIT] irq7: fwohci0 uhci1 8204 [SLP]actask 0x... acpi_task2 7204 [SLP]actask 0x... acpi_task1 6204 [SLP]actask 0x... acpi_task0 23204 new [IWAIT] irq9: acpi0 22204 new [IWAIT] irq13: 21204 new [IWAIT] swi3: cambio 20204 new [IWAIT] swi2: camnet 19204 new [IWAIT] swi5:+ 5204 [SLP]tqthr 0x... taskqueue 18204 [IWAIT] swi7: acpitaskq 17204 [IWAIT] swi6:+ 16204 [IWAIT] swi6: task queue 15204 [SLP]- 0x... random 4204 [SLP]- 0x... g_down 3204 [SLP]- 0x... g_up 2204 [SLP]- 0x... g_event 14204 new [IWAIT] swi5: vm 1320c new [IWAIT] swi8: tty:sio clock 12204 new [IWAIT] swi1: net 1120c [Can run] idle 1200 new [INACTIVE] swapper 10204 [CV]ktrace 0x... ktrace 0200 [SLP]conifhk 0x... swapper This state seems to be pretty reproducible. Any idea what is wrong? Regards -Thorsten -- People who claim they don't let little things bother them have never slept in a room with a single mosquito. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
make buildworld problems on VIA C3
I am pretty new to buildworld and I am having the following problem: whenever I run 'make buildworld' I get errors when it gets to libfetch. Specifically, i get compile errors in the file /usr/src/lib/libfetch/common.c on lines 58-63. See the following links for relevent information: http://xyst.dhs.org/logs/dmesg.boot http://xyst.dhs.org/logs/make.conf http://xyst.dhs.org/logs/buildworld.3.log http://xyst.dhs.org/logs/buildworld.2.log http://xyst.dhs.org/logs/buildworld.1.log I have tried changing options in my make.conf file but I still have no success, I keep getting the same error. The make.conf file is the one used for the log file buildworld.3.log and any other log files are for previous runs with slightly different options in the file make.conf I also used cvsup yesterday to update my source tree. I should also mention that I went into this directory and typed 'make' and everything ran without a hitch! I just downloaded, burned, and installed FreeBSD 5.1 CURRENT yesterday. Any help is appreciated! Thanks, Greg _ Concerned that messages may bounce because your Hotmail account has exceeded its 2MB storage limit? Get Hotmail Extra Storage! http://join.msn.com/?PAGE=features/es ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: buildworld fails on Alpha?
On Sat, Oct 25, 2003 at 06:06:24AM +0900, Hajimu UMEMOTO wrote: > Hi, > > > On Fri, 24 Oct 2003 23:03:31 +0200 > > Wilko Bulte <[EMAIL PROTECTED]> said: > > wkb> ll -Wno-format-y2k -Wno-uninitialized -c /usr/src/lib/libfetch/common.c > wkb> /usr/src/lib/libfetch/common.c:58: error: `EAINONAME' undeclared here (not > > It was fixed already. Please re-cvsup. > Sorry for the mess. No problem, I'll re-cvsup -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: buildworld fails on Alpha?
Hi, > On Fri, 24 Oct 2003 23:03:31 +0200 > Wilko Bulte <[EMAIL PROTECTED]> said: wkb> ll -Wno-format-y2k -Wno-uninitialized -c /usr/src/lib/libfetch/common.c wkb> /usr/src/lib/libfetch/common.c:58: error: `EAINONAME' undeclared here (not It was fixed already. Please re-cvsup. Sorry for the mess. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: buildworld fails on Alpha?
On Fri, Oct 24, 2003 at 11:03:31PM +0200, Wilko Bulte wrote: > ll -Wno-format-y2k -Wno-uninitialized -c /usr/src/lib/libfetch/fetch.c > cc -O -pipe -mcpu=ev6 -mieee -I. -DINET6 -DWITH_SSL -Wsystem-headers -Werror > -Wa > ll -Wno-format-y2k -Wno-uninitialized -c /usr/src/lib/libfetch/common.c > /usr/src/lib/libfetch/common.c:58: error: `EAINONAME' undeclared here (not > in a > function) This was fixed yesterday. Kris pgp0.pgp Description: PGP signature
buildworld fails on Alpha?
ll -Wno-format-y2k -Wno-uninitialized -c /usr/src/lib/libfetch/fetch.c cc -O -pipe -mcpu=ev6 -mieee -I. -DINET6 -DWITH_SSL -Wsystem-headers -Werror -Wa ll -Wno-format-y2k -Wno-uninitialized -c /usr/src/lib/libfetch/common.c /usr/src/lib/libfetch/common.c:58: error: `EAINONAME' undeclared here (not in a function) /usr/src/lib/libfetch/common.c:58: error: initializer element is not constant /usr/src/lib/libfetch/common.c:58: error: (near initialization for `_netdb_errli st[0].num') /usr/src/lib/libfetch/common.c:58: error: initializer element is not constant /usr/src/lib/libfetch/common.c:58: error: (near initialization for `_netdb_errli st[0]') /usr/src/lib/libfetch/common.c:60: error: initializer element is not constant /usr/src/lib/libfetch/common.c:60: error: (near initialization for `_netdb_errli st[1]') /usr/src/lib/libfetch/common.c:61: error: initializer element is not constant /usr/src/lib/libfetch/common.c:61: error: (near initialization for `_netdb_errli st[2]') /usr/src/lib/libfetch/common.c:62: error: initializer element is not constant /usr/src/lib/libfetch/common.c:62: error: (near initialization for `_netdb_errli st[3]') /usr/src/lib/libfetch/common.c:63: error: initializer element is not constant /usr/src/lib/libfetch/common.c:63: error: (near initialization for `_netdb_errli st[4]') *** Error code 1 Stop in /usr/src/lib/libfetch. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Seen before? Or just me? -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
P6DGH and CURRENT as of 2 PM EST 10/24 panics
-CURRENT as of 10/17 is not a problem, kernel just compiled with SMP support today after cvsup at about 2 PM EST (10/24) panics. Nothing shows up in the logs (of course?). I'm recompiling with no SMP support and will report if that dies also. Hardware is the oddball SM P6DGH dual PIII/850 with bridged PCI busses and onboard Adaptec SCSI support, plus i2o support that is not used. The 10/18 kernel boots with a lot of ACPI errors, but so far they have had no effect. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fresh -current trap
On Fri, 2003-10-24 at 13:40, Arjan van Leeuwen wrote: > On Friday 24 October 2003 19:30, Kris Kennaway wrote: > > On Fri, Oct 24, 2003 at 10:13:34AM -0700, Janet Sullivan wrote: > > > Kris Kennaway wrote: > > > >On Fri, Oct 24, 2003 at 04:39:14PM +0400, Sergey A. Osokin wrote: > > > >>Fatal trap 12: page fault while in kernel mode > > > > > > > >Looks like it might be related to the DRM import from yesterday. > > > >You're not using any modules, are you? > > > > > > Since the DRM commit I received similar traps. I had to rebuild a > > > kernel without "options radeondrm" just to be able to boot. I'm not > > > using any modules. > > > > Don't drop the mailing list from the CC list when reporting bugs ;-) > > > > Kris > > Same here, using an Ati Radeon R100. I see functions that have 'radeon' in the > name in the trace. Is there any more information I can provide? Not sure what went wrong here. I'm cvsupping to do a fresh build (going really slow, our internet connection is terrible). Sorry for the trouble everyone. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fresh -current trap
On Friday 24 October 2003 19:30, Kris Kennaway wrote: > On Fri, Oct 24, 2003 at 10:13:34AM -0700, Janet Sullivan wrote: > > Kris Kennaway wrote: > > >On Fri, Oct 24, 2003 at 04:39:14PM +0400, Sergey A. Osokin wrote: > > >>Fatal trap 12: page fault while in kernel mode > > > > > >Looks like it might be related to the DRM import from yesterday. > > >You're not using any modules, are you? > > > > Since the DRM commit I received similar traps. I had to rebuild a > > kernel without "options radeondrm" just to be able to boot. I'm not > > using any modules. > > Don't drop the mailing list from the CC list when reporting bugs ;-) > > Kris Same here, using an Ati Radeon R100. I see functions that have 'radeon' in the name in the trace. Is there any more information I can provide? Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ata problem with latest current
Hi, Once again we cvsupped latest ATA code changes and nothing much changed. Only after couple minutes of stress testing system will freeze. Though error message is little different than before. Tomppa ad5: TIMEOUT - READ_DMA retrying (2 retries left) ata2: resetting devices .. ata2: reset tp1 mask=03 ostat0=80 ostat1=80 ad4: stat=0x90 err=0x90 lsb=0x90 msb=0x90 ad5: stat=0x90 err=0x90 lsb=0x90 msb=0x90 ad4: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ad5: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 mask=03 stat0=50 stat1=50 devices=0x3 ad4: FAILURE - already active DMA on this device ad4: setting up DMA failed ad5: pio=0x0c wdma=0x22 udma=0x45 cable=80pin smbfs_getpages: error 4 vm_fault: pager read error, pid 621 (cp) smb_iod_recvall: drop resp with mid 31170 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: Memory modified after free
Thanks again for looking at this problem Doug White wrote: > On Thu, 23 Oct 2003, othermark wrote: > Onboard fiber? What kind of system is this? They're wired to the board. I'd probably break the connector if I remove it. This box has custom hardware attached, I don't expect any of the drivers to attach (with exception of the std onboard ethernet) because of this. I do want -current to come up so I can begin driver twiddling. >> > That or perhaps you have bad memory. Do you have ECC RAM in the >> > system? I found some and turned on bios ecc logging. Same panic, no ECC errors corrections. > I suspect the actual last user is irrelevant; its a leaking pointer > reference somewhere and the memory allocator is handing the memory block > it points to back out to some innocent bystander who triggers the panic. > > Have you emailed the em driver maintainer yet? Based on my later replies - October 16th boots fine, and October 17th snapshot b0rks on this panic, I'm not convinced the em driver is at fault. I will recompile w/o em in the kernel to test this theory. -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fresh -current trap
I also trapped same problem. Subject: Re: fresh -current trap, On Fri, 24 Oct 2003 10:00:57 -0700, Kris Kennaway wrote: > Looks like it might be related to the DRM import from yesterday. > You're not using any modules, are you? I'm using a radeon DRM module. -- Shin-ichi YOSHIMOTO <[EMAIL PROTECTED]> http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: trap: fast data access mmu miss
On Fri, 2003/10/24 at 09:09:25 +0400, Alex Deiter wrote:
> panic: trap: fast data access mmu miss
> cpuid = 0;
> Debugger("panic")
> Stopped at Debugger+0x1c: ta %xcc, 1
> db> tr
> panic() at panic+0x174
> trap() at trap+0x394
> -- fast data access mmu miss tar=0 %o7=0xc018b820 --
> quotactl() at quotactl+0x98
> syscall() at syscall+0x308
> -- syscall (148, FreeBSD ELF64, quotactl) %o7=0x1e3044 --
> userland() at 0x41187e88
> user trace: trap %o7=0x1e3044
> pc 0x41187e88, sp 0x7fde221
> pc 0x15149c, sp 0x7fde321
> pc 0x151818, sp 0x7fde871
> pc 0x1c771c, sp 0x7fde931
> pc 0x1a6938, sp 0x7fdea01
> pc 0x1b3904, sp 0x7fdec81
> pc 0x1d987c, sp 0x7fdedc1
> pc 0x1d99c0, sp 0x7fdeec1
> pc 0x1da06c, sp 0x7fdefa1
> pc 0x1db99c, sp 0x7fdf071
> pc 0x451ea8, sp 0x7fdf161
> pc 0x133560, sp 0x7fdf3f1
> pc 0x405d3f94, sp 0x7fdf4b1
> done
I believe that the attached patch should fix that; the panic is not
sparc64-specific, and should occur on all file systems that do not
define a vop_getwritemount method.
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
<[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Index: vfs_syscalls.c
===
RCS file: /vol/ncvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.331
diff -u -r1.331 vfs_syscalls.c
--- vfs_syscalls.c 21 Aug 2003 13:53:01 - 1.331
+++ vfs_syscalls.c 24 Oct 2003 19:08:29 -
@@ -189,7 +189,7 @@
caddr_t arg;
} */ *uap;
{
- struct mount *mp;
+ struct mount *mp, *wmp;
int error;
struct nameidata nd;
@@ -199,12 +199,13 @@
if ((error = namei(&nd)) != 0)
return (error);
NDFREE(&nd, NDF_ONLY_PNBUF);
- error = vn_start_write(nd.ni_vp, &mp, V_WAIT | PCATCH);
+ error = vn_start_write(nd.ni_vp, &wmp, V_WAIT | PCATCH);
+ mp = nd.ni_vp->v_mount;
vrele(nd.ni_vp);
if (error)
return (error);
error = VFS_QUOTACTL(mp, uap->cmd, uap->uid, uap->arg, td);
- vn_finished_write(mp);
+ vn_finished_write(wmp);
return (error);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD-Current and XFree86
On Fri, 2003-10-24 at 00:13, Thomas Schwarzkopf wrote: > On Friday 24 October 2003 02:00, James Tanis wrote: > > > From the log file: > > (II) Primary Device is: > > (--) Assigning device section with no busID to primary device > > (WW) RADEON: No matching Device section for instance (BusID > > PCI:1:0:1) found (EE) No devices detected. > > > > I did not attempt any different settings from the norm at > > this time since, if my memory serves me right this is the same exact > > error I was getting before and nothing I tried seemed to fix it. Here > > is the device section as it is now for my radeon 9800, these are the > > same settings that I used to use and worked perfectly fine with my > > radeon 7000, although I have tried a config without the extra options > > it did not seems to help nor is their any reason that I can think of > > that these options would not work with the 9800. > > > > Section "Device" > > Identifier "Radeon 9800" > > Driver "radeon" > > #VideoRam131072 > > # Insert Clocks lines here if appropriate > > Option "AGPMode" "4" > > Option "AGPFastWrite" "1" > > Option "EnablePageFlip""1" > > EndSection > > Have you tried adding a line like this > > BusID"PCI 01:00:0" > > to Section "Device"? Maybe also try "PCI 1:0:1" > I had the same error with a different card and this helped. Actually, the problem here (as I just replied in a private email) was that that card is newer than 4.2.99.12's radeon support, so it didn't probe the radeon. Solution I suggested was to try chipid 0x4e48 because his is 0x4e49, which is the same generation of chip. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADS-UP: switch Advanced Sockets API for IPv6 from RFC2292 to RFC3542
Hi, I've just committed to switch Advanced Sockets API for IPv6 from RFC2292 to RFC3542 (aka RFC2292bis). Though I believe this commit doesn't break backward compatibility againt existing binaries, it breaks backward compatibility of API. Now, the applications which use Advanced Sockets API such as telnet, ping6, mld6query and traceroute6 use RFC3542 API. Sincerely, --- Begin Message --- ume 2003/10/24 11:26:30 PDT FreeBSD src repository Modified files: contrib/telnet/telnet commands.c lib/libc/net Makefile.inc getaddrinfo.c ip6opt.c rthdr.c lib/libsdp search.c sbin/ping6 Makefile ping6.8 ping6.c sys/netinet icmp6.h in.h in_pcb.h ip6.h sys/netinet6 icmp6.c in6.h in6_pcb.c in6_var.h ip6_input.c ip6_output.c ip6_var.h mld6.c nd6.c nd6.h nd6_rtr.c raw_ip6.c route6.c udp6_output.c usr.sbin/mld6query Makefile mld6.c usr.sbin/traceroute6 Makefile Added files: lib/libc/net inet6_opt_init.3 inet6_rth_space.3 Log: Switch Advanced Sockets API for IPv6 from RFC2292 to RFC3542 (aka RFC2292bis). Though I believe this commit doesn't break backward compatibility againt existing binaries, it breaks backward compatibility of API. Now, the applications which use Advanced Sockets API such as telnet, ping6, mld6query and traceroute6 use RFC3542 API. Obtained from: KAME Revision ChangesPath 1.33 +9 -16 src/contrib/telnet/telnet/commands.c 1.49 +14 -2 src/lib/libc/net/Makefile.inc 1.46 +276 -156 src/lib/libc/net/getaddrinfo.c 1.1 +291 -0src/lib/libc/net/inet6_opt_init.3 (new) 1.1 +254 -0src/lib/libc/net/inet6_rth_space.3 (new) 1.5 +227 -0src/lib/libc/net/ip6opt.c 1.6 +340 -210 src/lib/libc/net/rthdr.c 1.2 +1 -0 src/lib/libsdp/search.c 1.10 +2 -4 src/sbin/ping6/Makefile 1.19 +61 -71src/sbin/ping6/ping6.8 1.25 +200 -181 src/sbin/ping6/ping6.c 1.13 +25 -26src/sys/netinet/icmp6.h 1.81 +1 -0 src/sys/netinet/in.h 1.63 +6 -4 src/sys/netinet/in_pcb.h 1.8 +10 -11src/sys/netinet/ip6.h 1.43 +36 -5 src/sys/netinet6/icmp6.c 1.28 +90 -33src/sys/netinet6/in6.h 1.43 +1 -2 src/sys/netinet6/in6_pcb.c 1.17 +4 -1 src/sys/netinet6/in6_var.h 1.59 +33 -56src/sys/netinet6/ip6_input.c 1.62 +985 -246 src/sys/netinet6/ip6_output.c 1.20 +37 -4 src/sys/netinet6/ip6_var.h 1.14 +1 -1 src/sys/netinet6/mld6.c 1.35 +27 -38src/sys/netinet6/nd6.c 1.15 +28 -9 src/sys/netinet6/nd6.h 1.23 +0 -3 src/sys/netinet6/nd6_rtr.c 1.29 +25 -23src/sys/netinet6/raw_ip6.c 1.8 +1 -2 src/sys/netinet6/route6.c 1.13 +3 -2 src/sys/netinet6/udp6_output.c 1.5 +2 -2 src/usr.sbin/mld6query/Makefile 1.3 +97 -16src/usr.sbin/mld6query/mld6.c 1.8 +2 -2 src/usr.sbin/traceroute6/Makefile --- End Message --- -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon 7500 w/ DRI locking on restart of X
Eric, I updated my 5.1-RELEASE system to CURRENT dated today at approx. 9:10 CDT to give your changes a try. I had a bit of a fright at first with kernel panics right at the end of the boot sequence but it turned out I had forgotten to disable the ltmdm code -- the kernel module compiled under -RELEASE wasn't friendly to -CURRENT. I've got just a basic install with my custom kernel. I'm using the packages for X from the 5.1-RELEASE cd running twm. Hangs on restart are gone! I restarted about 10 times in a row and ran glxinfo and glxgears each time to verify DRI was still activated and working -- no issues. VT switches are fine (even while running glxgears). The one thing that does not work is resume from acpiconf -s 4 (disk) -- there is a failure to refresh in X and no ability *apparently* to switch to a VT; the keystrokes just generate beeps. Interestingly, the cursor still changed between the different modes when mousing over the xterm and onto the background. Also, Alt-Cntl-Del did work just fine. The only other thing I noticed is that there seems to be a syslog entry for every instance of running glxgears that reads: [MP SAFE] drm0 Is this expected behavior? I noticed that same message (in brackets) in front of each of my disks as they were probed during boot. Any further info you'd like or more testing I could do to help? Sean -Original Message- From: Eric Anholt <[EMAIL PROTECTED]> Sent: Oct 23, 2003 9:09 PM To: Glenn Johnson <[EMAIL PROTECTED]> Cc: Vulpes Velox <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Radeon 7500 w/ DRI locking on restart of X On Tue, 2003-08-26 at 20:37, Glenn Johnson wrote: > On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote: > > > On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote: > > > > > I had similar problem with a 7200 and OGL. I solved the problem by > > > turning off some of the options in the X config. > > > > > > On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) Sean Welch > > > <[EMAIL PROTECTED]> wrote: > > > > > > > Is anyone else seeing this issue? I'm running into it on desktop > > > > boxes and a laptop running 4.8-RELEASE with up to date ports > > > > collections and various versions of DRI installed over a ports > > > > version of X. I'm also seeing this under 5.1-RELEASE on the > > > > laptop. > > > > > > > > Everything works perfectly unless/until I restart the X server. > > > > This appears to be initiated automatically when running GDM -- ie, > > > > GDM starts, you log in using that X session, you log out and the > > > > session stops, GDM starts X again and displays the login screen. > > > > Everyone that's experiencing this and is using the DRI, what version > > of the radeon DRM is loaded? (dmesg | grep drm) Is anyone experiencing > > this without the DRI loaded? The ForcePCIMode workaround is > > interesting, I'll take a look at what could be going on there. > > I did some googling tonight and found out this problem is supposedly > fixed in XFree86-4.3.99 although I do not see any specific mention of > this problem in the Changelog. See: > > http://www.knoppix.net/forum/viewtopic.php?t=2504&highlight= That patch has been in our XFree86 for quite a while. For those of you using -current, could you try with the latest DRM which I committed to FreeBSD CVS a few minutes ago? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 10/23 cvsup buildworld failure
Il Ven, 2003-10-24 alle 17:47, Michael L. Squires ha scritto: > Tinderbox > > /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libfetch/common.c:60: > error: initializer element is not constant > > Under 5.1-CURRENT or i386 cvsuped on 10/23 I get the same failure, with > the additional error message > > /usr/src/lib/libfetch/common.c:58: error: 'EAINONAME' undeclared here (not in a > function) > > Other error messages are similar or the same. > > I have re-cvsup'd and am trying again. You cvsup'd on at a bad moment, because ume@ correct this error at 2003/10/23 20:49:38 PDT with revision 1.29 of netdb.h Regards -- Rionda aka Matteo Riondato G.U.F.I Staff Member (http://www.gufi.org) BSD-FAQ-it Main Developer (http://www.gufi.org/~rionda) GPG key at: http://www.riondabsd.net/riondagpg.asc Sent from: kaiser.sig11.org running FreeBSD-5.1-CURRENT signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Re: fresh -current trap
On Fri, Oct 24, 2003 at 10:13:34AM -0700, Janet Sullivan wrote: > > Kris Kennaway wrote: > >On Fri, Oct 24, 2003 at 04:39:14PM +0400, Sergey A. Osokin wrote: > >> > >>Fatal trap 12: page fault while in kernel mode > > >Looks like it might be related to the DRM import from yesterday. > >You're not using any modules, are you? > > Since the DRM commit I received similar traps. I had to rebuild a > kernel without "options radeondrm" just to be able to boot. I'm not > using any modules. Don't drop the mailing list from the CC list when reporting bugs ;-) Kris pgp0.pgp Description: PGP signature
Re: fresh -current trap
On Fri, Oct 24, 2003 at 04:39:14PM +0400, Sergey A. Osokin wrote: > Hello, > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x60 > fault core= supervisor read, page not present > instruction pointer = 0x8:0xc04d6d42 > stack pointer = 0x10:0xde5b7624 > frame pointer = 0x10:0xde5b764c > 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 = 87 (sysctl) > kernel: trap 12 trap, code=0 > Stopped at_mtx_lock_sleep+0x1b2: movl0x68(%ecx),%edx > db> where > _mtx_lock_sleep(c2978c18,0,c07a85f4,e5,c12bfa80) at _mtx_lock_sleep+0x1b2 > _mtx_lock_flags(c2978c18,0,c07a85f4,e5,0) at _mtx_lock_flags+0x40 > radeon_bufs_info(c2973920,c2978c00,0,de5b7bf8,de5b7bf8) at radeon_bufs_info+0x6f > sysctl_root(0,de5b7c98,4,de5b7bf8,c29b85f0) at sysctl_root+0x14b > useland_sysctl(c29b85f0,de5b7c98,4,0,bfbff40c) at useland_sysctl+0x14d > __sysctl(c29b85f0,de5b7d10,18,c0509436,6) at __sysctl+0xd4 > syscall(2f,2f,2f,0,bfbff40c) at syscall+0x310 > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x280bed2f, esp = 0xbfbff38c, ebp > = 0xbfbff3b8 --- > > Any idea? Looks like it might be related to the DRM import from yesterday. You're not using any modules, are you? Kris pgp0.pgp Description: PGP signature
Re: 10/23 cvsup buildworld failure
On Fri, Oct 24, 2003 at 10:47:22AM -0500, Michael L. Squires wrote: > Tinderbox > > /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libfetch/common.c:60: > error: initializer element is not constant > > Under 5.1-CURRENT or i386 cvsuped on 10/23 I get the same failure, with > the additional error message > > /usr/src/lib/libfetch/common.c:58: error: 'EAINONAME' undeclared here (not in a > function) > > Other error messages are similar or the same. > > I have re-cvsup'd and am trying again. This was fixed yesterday, hours before your message was sent :-) Kris pgp0.pgp Description: PGP signature
Re: LOR (swap_pager.c:1134 <> vm_kern.c:328).
On Fri, Oct 24, 2003 at 09:44:45AM +0200, Pawel Jakub Dawidek wrote: > Hello. > > It was reported already? Yes, n times. Kris pgp0.pgp Description: PGP signature
Re: __fpclassifyd problem
[ add compatability hacks to libm ] > > We tried this at usenix, but it still didn't work. Obviously there is more > > going on. > > > > Before anybody goes and bumps libraries etc, it would be useful to know if > > running a statically linked jvm will work on -current. > > This sounds like a good plan, though it should be noted that statically > linking the jvm executable will reder it useless since it won't be able > to dl_open any of the essential JNI modules. Not just the JNI modules, but basically *all* the modules are dl_opened, so a staticially linked modern JVM can't realistically be created. The last time we were able to create a static JVM was JDK1.1. I spent many weeks attempting to create one for 1.2, and finally gave up. Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: Memory modified after free
On Thu, 23 Oct 2003, othermark wrote: > these are fibre 1000 base sx connections. They don't attach correctly in > the 5.0-release kernel as well (with the exact same error), but it does > continue to boot correctly. These are hardwired into the bus, and I'm > unable to disable them. :( Onboard fiber? What kind of system is this? > > That or perhaps you have bad memory. Do you have ECC RAM in the system? > > I'm not positive, so I'm going to say no, but I'm also fairly sure that > the memory is good. I ran make buildworld on 5.0 successfully w/o any > problems. Slow bios memcheck at startup is good. That memcheck is useless, sadly. You might track down a copy of memtest86 and run it on your system just to be sure. Its a much more intensive diagnostic. > this seems similar to: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/53566 > > except the last user is of memory is different. I suspect the actual last user is irrelevant; its a leaking pointer reference somewhere and the memory allocator is handing the memory block it points to back out to some innocent bystander who triggers the panic. > I think the next step is to move up to a 5.1-release kernel and see if > it boots as well as the 5.0-release does, or provides a more interesting > panic. Have you emailed the em driver maintainer yet? -- 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]"
10/23 cvsup buildworld failure
Tinderbox > /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libfetch/common.c:60: > error: initializer element is not constant Under 5.1-CURRENT or i386 cvsuped on 10/23 I get the same failure, with the additional error message /usr/src/lib/libfetch/common.c:58: error: 'EAINONAME' undeclared here (not in a function) Other error messages are similar or the same. I have re-cvsup'd and am trying again. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: Memory modified after free
Hi, thanks for taking a gander at my problem. The original panic can be reviewed here: http://article.gmane.org/gmane.os.freebsd.current/31913 now to answer your query... Doug Rabson wrote: > On Thu, 2003-10-23 at 22:45, othermark wrote: >> I wrote: >> > I will try seeing how far I can go up the list of snapshots until I >> > encounter the first boot -s panic. >> >> Well I walked up the available snapshots and the first panic occurs with >> the snapshot from the 17th of October. Reviewing the commit logs between >> the 16th and the 17th I note the following commits are the most >> 'interesting.' as related to this panic.. This is just a cursory look >> at the logs, I haven't gotten into compiling and fingering an exact >> commit yet (which takes loads of time). >> >> dfr 2003/10/16 02:16:28 PDT >> >> FreeBSD src repository >> >> Modified files: >> sys/sys bus.h kobj.h param.h >> sys/kern subr_bus.c subr_kobj.c >> Log: >> * Add multiple inheritance to kobj. > > I haven't had any other reports of breakage related to this. Is it > possible that you are using a kernel module which you have not re-built > after this date (e.g. nvidia.ko)? I'm not loading any modules with the single user boot 'boot -s'. (kldstat shows no modules, just 'kernel'). In fact I only downloaded the 'kernel' file for each snapshot off current.freebsd.org, placed it in it's own directory under /boot and referenced it explicitly at the boot prompt. Beginning at the oct 17th snapshot, I got the same panic as referenced in my original post to the list. Does anyone else have a box with several legacy isa pnp cards or embedded devices that can try to boot up -current from after the 17th? -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fresh -current trap
Hello, Fatal trap 12: page fault while in kernel mode fault virtual address = 0x60 fault core = supervisor read, page not present instruction pointer = 0x8:0xc04d6d42 stack pointer = 0x10:0xde5b7624 frame pointer = 0x10:0xde5b764c 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 = 87 (sysctl) kernel: trap 12 trap, code=0 Stopped at _mtx_lock_sleep+0x1b2: movl0x68(%ecx),%edx db> where _mtx_lock_sleep(c2978c18,0,c07a85f4,e5,c12bfa80) at _mtx_lock_sleep+0x1b2 _mtx_lock_flags(c2978c18,0,c07a85f4,e5,0) at _mtx_lock_flags+0x40 radeon_bufs_info(c2973920,c2978c00,0,de5b7bf8,de5b7bf8) at radeon_bufs_info+0x6f sysctl_root(0,de5b7c98,4,de5b7bf8,c29b85f0) at sysctl_root+0x14b useland_sysctl(c29b85f0,de5b7c98,4,0,bfbff40c) at useland_sysctl+0x14d __sysctl(c29b85f0,de5b7d10,18,c0509436,6) at __sysctl+0xd4 syscall(2f,2f,2f,0,bfbff40c) at syscall+0x310 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x280bed2f, esp = 0xbfbff38c, ebp = 0xbfbff3b8 --- Any idea? -- Rgdz,/"\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone seeing any NFS lockups/weirdness with latest (ish) current??
On Fri, Oct 24, 2003 at 01:30:18PM +0200, Poul-Henning Kamp wrote: > You may want to try this patch, Kirk sent it to me in response to a > case where my NFS-server hung during snapshot processing. > > I have only just managed to put it on my server so I don't know if > it solves the problem or not. Hmm, my NFS server stays ok; it's the client that has problems. Until somewhere this week, the following occurred: prompt> portupgrade -rR wv-0.7.5 ---> Upgrading 'imake-4.3.0' to 'imake-4.3.0_1' (devel/imake-4) ---> Building '/usr/ports/devel/imake-4' ===> Cleaning for perl-5.6.1_14 ===> Cleaning for imake-4.3.0_1 ===> Extracting for imake-4.3.0_1 >> Checksum OK for xc/X430src-1.tgz. >> Checksum OK for xc/X430src-3.tgz. [... ctrl-t (stty status) (15 seconds interval):] load: 2.43 cmd: tar 12295 [nfsfsync] 0.09u 4.16s 2% 544k load: 2.40 cmd: tar 12295 [nfsfsync] 0.09u 4.16s 2% 544k load: 2.34 cmd: tar 12295 [nfsfsync] 0.09u 4.16s 2% 544k load: 2.17 cmd: tar 12295 [nfsfsync] 0.09u 4.16s 2% 544k load: 2.05 cmd: tar 12295 [nfsfsync] 0.09u 4.16s 2% 544k load: 2.00 cmd: tar 12295 [nfsfsync] 0.09u 4.16s 2% 544k In other words, the 'tar' is dead in the water. Since somewhere this week, it not only hangs up that specific process, but all processes that try using NFS hang themselves up and eventually the machine reboots... I haven't produced a crash dump yet. The NFS server I use runs FreeBSD 4 and is mounted by a lot of FreeBSD 4 machines that do not have this problem. Zlo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone seeing any NFS lockups/weirdness with latest (ish) current??
In message <[EMAIL PROTECTED]>, Marc Olzheim writes:
>On Thu, Oct 23, 2003 at 10:53:29PM +0200, Soren Schmidt wrote:
>> Yes, NFS is locking up here as well between current machines thats been
>> updated in the last 24 hours...
>
>In kernels since about october 17th, until upto an hour ago, it's still
>reproducable here as well..
You may want to try this patch, Kirk sent it to me in response to a
case where my NFS-server hung during snapshot processing.
I have only just managed to put it on my server so I don't know if
it solves the problem or not.
Poul-Henning
Index: nfs_serv.c
===
RCS file: /home/ncvs/src/sys/nfsserver/nfs_serv.c,v
retrieving revision 1.136
diff -u -r1.136 nfs_serv.c
--- nfs_serv.c 24 Jun 2003 19:04:26 - 1.136
+++ nfs_serv.c 24 Oct 2003 11:14:56 -
@@ -310,13 +310,7 @@
error = ESTALE;
goto out;
}
- if ((error = VFS_FHTOVP(mp, &fhp->fh_fid, &vp)) != 0) {
- mp = NULL;
- goto out;
- }
- (void) vn_start_write(vp, &mp, V_WAIT);
- vput(vp);
- vp = NULL;
+ (void) vn_start_write(NULL, &mp, V_WAIT);
VATTR_NULL(vap);
if (v3) {
nfsm_srvsattr(vap);
@@ -1010,13 +1004,7 @@
error = ESTALE;
goto ereply;
}
- if ((error = VFS_FHTOVP(mntp, &fhp->fh_fid, &vp)) != 0) {
- mntp = NULL;
- goto ereply;
- }
- (void) vn_start_write(vp, &mntp, V_WAIT);
- vput(vp);
- vp = NULL;
+ (void) vn_start_write(NULL, &mntp, V_WAIT);
if (v3) {
tl = nfsm_dissect(u_int32_t *, 5 * NFSX_UNSIGNED);
off = fxdr_hyper(tl);
@@ -1588,7 +1576,6 @@
u_quad_t tempsize;
u_char cverf[NFSX_V3CREATEVERF];
struct mount *mp = NULL;
- struct vnode *vp;
nfsdbprintf(("%s %d\n", __FILE__, __LINE__));
#ifndef nolint
@@ -1602,12 +1589,7 @@
error = ESTALE;
goto ereply;
}
- if ((error = VFS_FHTOVP(mp, &fhp->fh_fid, &vp)) != 0) {
- mp = NULL;
- goto ereply;
- }
- (void) vn_start_write(vp, &mp, V_WAIT);
- vput(vp);
+ (void) vn_start_write(NULL, &mp, V_WAIT);
nfsm_srvnamesiz(len);
nd.ni_cnd.cn_cred = cred;
@@ -1891,13 +1873,7 @@
error = ESTALE;
goto ereply;
}
- if ((error = VFS_FHTOVP(mp, &fhp->fh_fid, &vp)) != 0) {
- mp = NULL;
- goto ereply;
- }
- (void) vn_start_write(vp, &mp, V_WAIT);
- vput(vp);
- vp = NULL;
+ (void) vn_start_write(NULL, &mp, V_WAIT);
nfsm_srvnamesiz(len);
nd.ni_cnd.cn_cred = cred;
@@ -2064,7 +2040,6 @@
nfsfh_t nfh;
fhandle_t *fhp;
struct mount *mp = NULL;
- struct vnode *vp;
nfsdbprintf(("%s %d\n", __FILE__, __LINE__));
ndclear(&nd);
@@ -2075,13 +2050,7 @@
error = ESTALE;
goto ereply;
}
- if ((error = VFS_FHTOVP(mp, &fhp->fh_fid, &vp)) != 0) {
- mp = NULL;
- goto ereply;
- }
- (void) vn_start_write(vp, &mp, V_WAIT);
- vput(vp);
- vp = NULL;
+ (void) vn_start_write(NULL, &mp, V_WAIT);
nfsm_srvnamesiz(len);
nd.ni_cnd.cn_cred = cred;
@@ -2178,7 +2147,6 @@
fhandle_t *ffhp, *tfhp;
uid_t saved_uid;
struct mount *mp = NULL;
- struct vnode *vp;
nfsdbprintf(("%s %d\n", __FILE__, __LINE__));
#ifndef nolint
@@ -2199,13 +2167,7 @@
error = ESTALE;
goto out1;
}
- if ((error = VFS_FHTOVP(mp, &ffhp->fh_fid, &vp)) != 0) {
- mp = NULL;
- goto out1;
- }
- (void) vn_start_write(vp, &mp, V_WAIT);
- vput(vp);
- vp = NULL;
+ (void) vn_start_write(NULL, &mp, V_WAIT);
nfsm_srvnamesiz(len);
/*
* Remember our original uid so that we can reset cr_uid before
@@ -2421,13 +2383,7 @@
error = ESTALE;
goto ereply;
}
- if ((error = VFS_FHTOVP(mp, &fhp->fh_fid, &vp)) != 0) {
- mp = NULL;
- goto ereply;
- }
- (void) vn_start_write(vp, &mp, V_WAIT);
- vput(vp);
- vp = NULL;
+ (void) vn_start_write(NULL, &mp, V_WAIT);
nfsm_srvmtofh(dfhp);
nfsm_srvnamesiz(len);
@@ -2559,7 +2515,6 @@
nfsfh_t nfh;
fhandle_t *fhp;
struct mount *mp = NULL;
- struct vnode *vp;
nfsdbprintf(("%s %d\n", __FILE__, __LINE__));
ndclear(&nd);
@@ -2570,13 +2525,7 @@
error = ESTALE;
goto out;
}
- if ((error = VFS_FHTOVP(mp, &fhp->fh_fid, &vp)) != 0) {
- mp = NULL;
- goto out;
- }
- (void) v
Re: Anyone seeing any NFS lockups/weirdness with latest (ish) current??
On Thu, Oct 23, 2003 at 10:53:29PM +0200, Soren Schmidt wrote: > Yes, NFS is locking up here as well between current machines thats been > updated in the last 24 hours... In kernels since about october 17th, until upto an hour ago, it's still reproducable here as well.. Zlo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD-Current and XFree86
At Thu, 23 Oct 2003 20:00:38 -0400, James Tanis wrote: > > Attempted this, first did a deinstall of XFree86-Server and then > built/installed XFree86-Server-snap. It built and installed perfectly fine, > from what I can see it runs fine too.. but I get the same error. You > weren't wrong, in the log once of the supported cards listed is the ATI > Radeon 9800 NH (AGP), although I have no idea what the NH stands for. The > only problem is I'm getting the same exact error I was previously.. > You could try running "XFree86 -configure" as root and see if there are any differences to you conf. -Richard ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
camcontrol rescan all panics kernel
I was playing a bit with USB (had a umass device attached) and while still being unsure whether I had device umass in kernel I typed the line camcontrol rescan all and that gave: panic:vmapbuf db> -- Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp0 device timeouts blues on T30
On Fri, Oct 24, 2003 at 09:31:52AM +0200, Hans Lambermont wrote: > I also added to /boot/device.hints : > hint.fxp.0.prefer_iomap="1" this never helped for me to fix the fxp timeout problem. it is necessary for me to the get the pccard buses to work though. > Tobias Roth wrote on 18 Jul 2003 about this irq order: > 5,9,10,11,11,9,10,11 and this did the trick for me. others reported that this particular order didn't work for them, but that trying different numbers and orders finally yielded in a working set. > This still needs to be sorted out for 5.2 definitely. but i do not have the knowledge to even start with it. cheers, t. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: Memory modified after free
On Thu, 2003-10-23 at 22:45, othermark wrote: > I wrote: > > I will try seeing how far I can go up the list of snapshots until I > > encounter the first boot -s panic. > > Well I walked up the available snapshots and the first panic occurs with > the snapshot from the 17th of October. Reviewing the commit logs between > the 16th and the 17th I note the following commits are the most > 'interesting.' as related to this panic.. This is just a cursory look > at the logs, I haven't gotten into compiling and fingering an exact commit > yet (which takes loads of time). > > dfr 2003/10/16 02:16:28 PDT > > FreeBSD src repository > > Modified files: > sys/sys bus.h kobj.h param.h > sys/kern subr_bus.c subr_kobj.c > Log: > * Add multiple inheritance to kobj. I haven't had any other reports of breakage related to this. Is it possible that you are using a kernel module which you have not re-built after this date (e.g. nvidia.ko)? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Flash Plugin report
On Fri, 24 Oct 2003 00:40:24 -0300 Roberto de Iriarte <[EMAIL PROTECTED]> wrote: > a) Problem > Right upon installing mozilla 1.5 from ports, i installed > flashpluginwrapper-20031006, and found out that mozilla would fail to > exit eating up CPU as if stuck in an infinite loop (Usage per top went > up into high 90%'s) if the plugin was triggered (by viewing a flash movie) > The same result was observed using the native java plugin (J2SE 1.4.1 > patchlevel 4 from ports) I heard this behavior like yours. But I don't have any idea to fix this behavior. > I decided to give libkse a try so i modified libmap.conf, and rebooted > the system for good measure and mozilla works perfectly. (And > responsivenes is excellent, and cpu usage much reduced, btw) Humm.. I use libkse, too. I wonder if we had better use libkse. > c) Ignorance from my part > Is linux.ko necessary to run flashpluginwrapper ? I forgot to enable it > in rc.conf and it seems to run equally well !? Theoretically, flashpluginwrapper uses userland COMPAT_LINUX technology:-), and is A killer application of libmap.conf feature:-)). So we don't need linux.ko (COMPAT_LINUX). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
LOR (swap_pager.c:1134 <> vm_kern.c:328).
Hello. It was reported already? 1st 0xc0c1ede0 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1134 2nd 0xc0c2f110 system map (system map) @ /usr/src/sys/vm/vm_kern.c:328 Stack backtrace: backtrace(c05cce28,c0c2f110,c05d72b0,c05d72b0,c05d7147) at backtrace+0x17 witness_lock(c0c2f110,8,c05d7147,148,c0c2f0b0) at witness_lock+0x686 _mtx_lock_flags(c0c2f110,0,c05d7147,148,101) at _mtx_lock_flags+0xbb _vm_map_lock(c0c2f0b0,c05d7147,148,c061a748,c061a770) at _vm_map_lock+0x36 kmem_malloc(c0c2f0b0,1000,101,c46b78bc,c056aead) at kmem_malloc+0x3a page_alloc(c0c3a3c0,1000,c46b78af,101,0) at page_alloc+0x27 slab_zalloc(c0c3a3c0,1,c0c3a3d4,8,c05d8ac1) at slab_zalloc+0xb3 uma_zone_slab(c0c3a3c0,1,c05d8ac1,68c,0) at uma_zone_slab+0xda uma_zalloc_internal(c0c3a3c0,0,1,0,c0c206b0) at uma_zalloc_internal+0x3e bucket_alloc(80,1,c05d8ac1,70b,0) at bucket_alloc+0x5e uma_zfree_arg(c0c20600,c472ebdc,0,7b6,8000) at uma_zfree_arg+0x299 swp_pager_meta_ctl(c0c1ede0,1f,0,2,c46b7a9c) at swp_pager_meta_ctl+0x10d swap_pager_unswapped(c0cbfb28,1,c05c7357,bd,c46b7a14) at swap_pager_unswapped+0x 2a vm_fault(c0d415e8,bfbff000,2,8,c154d390) at vm_fault+0x1186 trap_pfault(c46b7b0c,0,bfbffcc8,c063cee0,bfbffcc8) at trap_pfault+0x119 trap(18,10,10,bfbffcc8,c46b7bac) at trap+0x2f7 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc059d82c, esp = 0xc46b7b4c, ebp = 0xc46b7cb8 --- slow_copyout(c154d390,5,bfbffcc8,bfbffc48,0) at slow_copyout+0x4 select(c154d390,c46b7d14,c05dd181,3ed,5) at select+0x67 syscall(2f,2f,2f,bfbffcc8,1) at syscall+0x28f Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (93), eip = 0x280bbad3, esp = 0xbfbffbfc, ebp = 0xbfbffda0 --- -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
fxp0 device timeouts blues on T30
Hi list, My fxp0: device timeout problems are back (and I found a workaround, but the matter still deserves attention for 5.2, hence this email) Some info. This is an IBM T30 with : fxp0: port 0x8000-0x803f mem 0xd020-0xd0200fff irq 11 at device 8.0 on pci2 I also added to /boot/device.hints : hint.fxp.0.prefer_iomap="1" I upgraded from -current of last july, with all interrupts set to 11 in the bios, fxp0 worked fine for the last 3 months, it seemed the hint.fxp.0.prefer_iomap fixed it for me then. Upgrading to -current of October 23 gave the 'fxp0: device timeouts' back. I tried al pci interrupts set to auto in the bios, this works for a colleague of me with the same laptop on 5.1-R , but not for me on todays -current. Tobias Roth wrote on 18 Jul 2003 about this irq order: 5,9,10,11,11,9,10,11 and this did the trick for me. This still needs to be sorted out for 5.2 Any things I should try ? Hans Lambermont -- http://lambermont.webhop.org/ () ASCII-ribbon campaign against vCards, /\ HTML-mail and proprietary formats. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD-Current and XFree86
On Friday 24 October 2003 02:00, James Tanis wrote: > From the log file: > (II) Primary Device is: > (--) Assigning device section with no busID to primary device > (WW) RADEON: No matching Device section for instance (BusID > PCI:1:0:1) found (EE) No devices detected. > > I did not attempt any different settings from the norm at > this time since, if my memory serves me right this is the same exact > error I was getting before and nothing I tried seemed to fix it. Here > is the device section as it is now for my radeon 9800, these are the > same settings that I used to use and worked perfectly fine with my > radeon 7000, although I have tried a config without the extra options > it did not seems to help nor is their any reason that I can think of > that these options would not work with the 9800. > > Section "Device" > Identifier "Radeon 9800" > Driver "radeon" > #VideoRam131072 > # Insert Clocks lines here if appropriate > Option "AGPMode" "4" > Option "AGPFastWrite" "1" > Option "EnablePageFlip""1" > EndSection Have you tried adding a line like this BusID"PCI 01:00:0" to Section "Device"? Maybe also try "PCI 1:0:1" I had the same error with a different card and this helped. Thomas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
