From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 29 04:30:09 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C8D716A422 for ; Sun, 29 Jan 2006 04:30:09 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E200143D46 for ; Sun, 29 Jan 2006 04:30:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0T4U8nu070880 for ; Sun, 29 Jan 2006 04:30:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0T4U8ws070876; Sun, 29 Jan 2006 04:30:08 GMT (envelope-from gnats) Date: Sun, 29 Jan 2006 04:30:08 GMT Message-Id: <200601290430.k0T4U8ws070876@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: hotlips Internet admin Cc: Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hotlips Internet admin List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 04:30:09 -0000 The following reply was made to PR amd64/92412; it has been noted by GNATS. From: hotlips Internet admin To: kris@obsecurity.org (Kris Kennaway) Cc: bug-followup@FreeBSD.org Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info Date: Sat, 28 Jan 2006 23:28:25 -0500 (EST) Thus saith Kris Kennaway: | On Fri, Jan 27, 2006 at 11:59:15AM -0500, hotlips Internet admin wrote: | | > | > >Description: | > | > packets/second value reported by rpc.rstatd to remote monitor hovers around | > | > 8000 or so with odd downward spikes approx every 90 seconds (it's not at | > | all related to actual interface traffic) | > | > | > | > >How-To-Repeat: | > | > keep displaying rpc.rstatd data from 6.0 system | > | | > | How are you using rpc.rstatd and rup? I don't see a way to make rup | > | display "packets/second", it only gives uptime and load average: | > | | > | # rup | > | fbsd-amd64.isc. 10:02am up 4 days, 14:00, load average: 2.00 2.00 2.00 | > | > Solaris perfmeter, actually. | | Do you know how I can query this on FreeBSD? here's a tester kluge: in /usr/src/usr.bin/rup, make a copy rupx.c with this diff: 147a148 > printf("ipackets: %d opackets %d\n", host_stat->if_ipackets, host_stat->if_opackets); ... but I'll do better - it's fixed. Below are diffs for FreeBSD 6.x to fix 2 basic issues: 1. the code was filling in values to the most restrictive members of the union rather than the least, so values got overlaid; 2. the last gettimeofday call was clobbering the structure because it has 64-bit values in amd64. So how does this get tested & into the distro? (I also backported these & other fixes to 4.x) Cheers, Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@gts.net --------- 8< --------- 8< --------- 8< --------- 8< --------- 8< --------- *** rstat_proc.c.orig Sun Jun 1 22:34:36 2003 --- rstat_proc.c Sat Jan 28 16:41:10 2006 *************** *** 136,143 **** rstatproc_stats_2_svc(void *argp, struct svc_req *rqstp) { if (! stat_is_init) ! stat_init(); sincelastreq = 0; return(&stats_all.s2); } --- 136,144 ---- rstatproc_stats_2_svc(void *argp, struct svc_req *rqstp) { if (! stat_is_init) ! stat_init(); sincelastreq = 0; + stats_all.s2.if_opackets = stats_all.s3.if_opackets; return(&stats_all.s2); } *************** *** 145,152 **** rstatproc_stats_1_svc(void *argp, struct svc_req *rqstp) { if (! stat_is_init) ! stat_init(); sincelastreq = 0; return(&stats_all.s1); } --- 146,154 ---- rstatproc_stats_1_svc(void *argp, struct svc_req *rqstp) { if (! stat_is_init) ! stat_init(); sincelastreq = 0; + stats_all.s1.if_opackets = stats_all.s3.if_opackets; return(&stats_all.s1); } *************** *** 234,247 **** syslog(LOG_ERR, "sysctl(kern.boottime): %m"); exit(1); } ! ! stats_all.s2.boottime.tv_sec = btm.tv_sec; ! stats_all.s2.boottime.tv_usec = btm.tv_usec; #ifdef DEBUG ! fprintf(stderr, "%d %d %d %d\n", stats_all.s1.cp_time[0], ! stats_all.s1.cp_time[1], stats_all.s1.cp_time[2], stats_all.s1.cp_time[3]); #endif /* XXX - should use sysctl */ --- 236,248 ---- syslog(LOG_ERR, "sysctl(kern.boottime): %m"); exit(1); } ! stats_all.s3.boottime.tv_sec = btm.tv_sec; ! stats_all.s3.boottime.tv_usec = btm.tv_usec; #ifdef DEBUG ! fprintf(stderr, "%d %d %d %d\n", stats_all.s3.cp_time[0], ! stats_all.s3.cp_time[1], stats_all.s3.cp_time[2], stats_all.s3.cp_time[3]); #endif /* XXX - should use sysctl */ *************** *** 249,266 **** syslog(LOG_ERR, "rstat: can't read cnt from kmem"); exit(1); } ! stats_all.s1.v_pgpgin = cnt.v_vnodepgsin; ! stats_all.s1.v_pgpgout = cnt.v_vnodepgsout; ! stats_all.s1.v_pswpin = cnt.v_swappgsin; ! stats_all.s1.v_pswpout = cnt.v_swappgsout; ! stats_all.s1.v_intr = cnt.v_intr; gettimeofday(&tm, (struct timezone *) 0); ! stats_all.s1.v_intr -= hz*(tm.tv_sec - btm.tv_sec) + hz*(tm.tv_usec - btm.tv_usec)/1000000; ! stats_all.s2.v_swtch = cnt.v_swtch; /* update disk transfers */ ! updatexfers(RSTAT_DK_NDRIVE, stats_all.s1.dk_xfer); mib[0] = CTL_NET; mib[1] = PF_LINK; --- 250,267 ---- syslog(LOG_ERR, "rstat: can't read cnt from kmem"); exit(1); } ! stats_all.s3.v_pgpgin = cnt.v_vnodepgsin; ! stats_all.s3.v_pgpgout = cnt.v_vnodepgsout; ! stats_all.s3.v_pswpin = cnt.v_swappgsin; ! stats_all.s3.v_pswpout = cnt.v_swappgsout; ! stats_all.s3.v_intr = cnt.v_intr; gettimeofday(&tm, (struct timezone *) 0); ! stats_all.s3.v_intr -= hz*(tm.tv_sec - btm.tv_sec) + hz*(tm.tv_usec - btm.tv_usec)/1000000; ! stats_all.s3.v_swtch = cnt.v_swtch; /* update disk transfers */ ! updatexfers(RSTAT_DK_NDRIVE, stats_all.s3.dk_xfer); mib[0] = CTL_NET; mib[1] = PF_LINK; --- 273,278 ---- *************** *** 287,305 **** if (errno == ENOENT) continue; ! syslog(LOG_ERR, "sysctl(net.link.ifdata.%d.general)" ! ": %m", i); exit(1); } - stats_all.s1.if_ipackets += ifmd.ifmd_data.ifi_ipackets; stats_all.s1.if_opackets += ifmd.ifmd_data.ifi_opackets; stats_all.s1.if_ierrors += ifmd.ifmd_data.ifi_ierrors; stats_all.s1.if_oerrors += ifmd.ifmd_data.ifi_oerrors; stats_all.s1.if_collisions += ifmd.ifmd_data.ifi_collisions; } ! gettimeofday((struct timeval *)&stats_all.s3.curtime, ! (struct timezone *) 0); alarm(1); } --- 287,305 ---- if (errno == ENOENT) continue; ! syslog(LOG_ERR, "sysctl(net.link.ifdata.%d.general): %m", i); exit(1); } stats_all.s1.if_ipackets += ifmd.ifmd_data.ifi_ipackets; stats_all.s1.if_opackets += ifmd.ifmd_data.ifi_opackets; stats_all.s1.if_ierrors += ifmd.ifmd_data.ifi_ierrors; stats_all.s1.if_oerrors += ifmd.ifmd_data.ifi_oerrors; stats_all.s1.if_collisions += ifmd.ifmd_data.ifi_collisions; } ! ! gettimeofday(&tm, (struct timezone *) 0); ! stats_all.s3.curtime.tv_sec = tm.tv_sec; ! stats_all.s3.curtime.tv_usec = tm.tv_usec; alarm(1); } *************** *** 307,324 **** setup() { char errbuf[_POSIX2_LINE_MAX]; - int en; ! if ((kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf)) == NULL) { ! syslog(LOG_ERR, "rpc.rstatd, %s", errbuf); ! exit(1); } if ((en = kvm_nlist(kd, nl)) != 0) { syslog(LOG_ERR, "rstatd: Can't get namelist. %d", en); exit (1); ! } } /* --- 307,333 ---- setup() { char errbuf[_POSIX2_LINE_MAX]; int en; + static int is_kd_setup = 0; ! /* setup() is called after each dormant->active ! * transition. Since we never close the kvm files ! * (there's no reason), make sure we don't open them ! * each time, as that can lead to exhaustion of all open ! * files! */ ! if (!is_kd_setup) { ! kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf); ! if (kd == NULL) { ! syslog(LOG_ERR, "%s", errbuf); ! exit (1); ! } ! is_kd_setup = 1; } if ((en = kvm_nlist(kd, nl)) != 0) { syslog(LOG_ERR, "rstatd: Can't get namelist. %d", en); exit (1); ! } } /* From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 29 07:30:07 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3FB516A420 for ; Sun, 29 Jan 2006 07:30:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CA0643D45 for ; Sun, 29 Jan 2006 07:30:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0T7U78G084291 for ; Sun, 29 Jan 2006 07:30:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0T7U7kp084290; Sun, 29 Jan 2006 07:30:07 GMT (envelope-from gnats) Date: Sun, 29 Jan 2006 07:30:07 GMT Message-Id: <200601290730.k0T7U7kp084290@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: hotlips Internet admin Cc: Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hotlips Internet admin List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 07:30:07 -0000 The following reply was made to PR amd64/92412; it has been noted by GNATS. From: hotlips Internet admin To: kris@obsecurity.org (Kris Kennaway) Cc: bug-followup@FreeBSD.org Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info Date: Sun, 29 Jan 2006 02:25:33 -0500 (EST) Thus saith Kris Kennaway: | On Fri, Jan 27, 2006 at 11:59:15AM -0500, hotlips Internet admin wrote: | | > | > >Description: | > | > packets/second value reported by rpc.rstatd to remote monitor hovers around | > | > 8000 or so with odd downward spikes approx every 90 seconds (it's not at | > | all related to actual interface traffic) | > | > | > | > >How-To-Repeat: | > | > keep displaying rpc.rstatd data from 6.0 system | > | | > | How are you using rpc.rstatd and rup? I don't see a way to make rup | > | display "packets/second", it only gives uptime and load average: | > | | > | # rup | > | fbsd-amd64.isc. 10:02am up 4 days, 14:00, load average: 2.00 2.00 2.00 | > | > Solaris perfmeter, actually. | | Do you know how I can query this on FreeBSD? oop, wrong (older) diff - use this one below... -- Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@gts.net --------- 8< --------- 8< --------- 8< --------- 8< --------- 8< --------- *** rstat_proc.c.orig Sun Jun 1 22:34:36 2003 --- rstat_proc.c Sun Jan 29 02:17:10 2006 *************** *** 136,143 **** rstatproc_stats_2_svc(void *argp, struct svc_req *rqstp) { if (! stat_is_init) ! stat_init(); sincelastreq = 0; return(&stats_all.s2); } --- 136,144 ---- rstatproc_stats_2_svc(void *argp, struct svc_req *rqstp) { if (! stat_is_init) ! stat_init(); sincelastreq = 0; + stats_all.s2.if_opackets = stats_all.s3.if_opackets; return(&stats_all.s2); } *************** *** 145,152 **** rstatproc_stats_1_svc(void *argp, struct svc_req *rqstp) { if (! stat_is_init) ! stat_init(); sincelastreq = 0; return(&stats_all.s1); } --- 146,154 ---- rstatproc_stats_1_svc(void *argp, struct svc_req *rqstp) { if (! stat_is_init) ! stat_init(); sincelastreq = 0; + stats_all.s1.if_opackets = stats_all.s3.if_opackets; return(&stats_all.s1); } *************** *** 219,231 **** exit(1); } for(i = 0; i < RSTAT_CPUSTATES ; i++) ! stats_all.s1.cp_time[i] = bsd_cp_time[cp_time_xlat[i]]; ! (void)getloadavg(avrun, sizeof(avrun) / sizeof(avrun[0])); ! stats_all.s2.avenrun[0] = avrun[0] * FSCALE; ! stats_all.s2.avenrun[1] = avrun[1] * FSCALE; ! stats_all.s2.avenrun[2] = avrun[2] * FSCALE; mib[0] = CTL_KERN; mib[1] = KERN_BOOTTIME; --- 221,233 ---- exit(1); } for(i = 0; i < RSTAT_CPUSTATES ; i++) ! stats_all.s3.cp_time[i] = bsd_cp_time[cp_time_xlat[i]]; ! (void)getloadavg(avrun, sizeof(avrun) / sizeof(avrun[0])); ! stats_all.s3.avenrun[0] = avrun[0] * FSCALE; ! stats_all.s3.avenrun[1] = avrun[1] * FSCALE; ! stats_all.s3.avenrun[2] = avrun[2] * FSCALE; mib[0] = CTL_KERN; mib[1] = KERN_BOOTTIME; *************** *** 234,247 **** syslog(LOG_ERR, "sysctl(kern.boottime): %m"); exit(1); } ! ! stats_all.s2.boottime.tv_sec = btm.tv_sec; ! stats_all.s2.boottime.tv_usec = btm.tv_usec; #ifdef DEBUG ! fprintf(stderr, "%d %d %d %d\n", stats_all.s1.cp_time[0], ! stats_all.s1.cp_time[1], stats_all.s1.cp_time[2], stats_all.s1.cp_time[3]); #endif /* XXX - should use sysctl */ --- 236,248 ---- syslog(LOG_ERR, "sysctl(kern.boottime): %m"); exit(1); } ! stats_all.s3.boottime.tv_sec = btm.tv_sec; ! stats_all.s3.boottime.tv_usec = btm.tv_usec; #ifdef DEBUG ! fprintf(stderr, "%d %d %d %d\n", stats_all.s3.cp_time[0], ! stats_all.s3.cp_time[1], stats_all.s3.cp_time[2], stats_all.s3.cp_time[3]); #endif /* XXX - should use sysctl */ *************** *** 249,266 **** syslog(LOG_ERR, "rstat: can't read cnt from kmem"); exit(1); } ! stats_all.s1.v_pgpgin = cnt.v_vnodepgsin; ! stats_all.s1.v_pgpgout = cnt.v_vnodepgsout; ! stats_all.s1.v_pswpin = cnt.v_swappgsin; ! stats_all.s1.v_pswpout = cnt.v_swappgsout; ! stats_all.s1.v_intr = cnt.v_intr; gettimeofday(&tm, (struct timezone *) 0); ! stats_all.s1.v_intr -= hz*(tm.tv_sec - btm.tv_sec) + hz*(tm.tv_usec - btm.tv_usec)/1000000; ! stats_all.s2.v_swtch = cnt.v_swtch; /* update disk transfers */ ! updatexfers(RSTAT_DK_NDRIVE, stats_all.s1.dk_xfer); mib[0] = CTL_NET; mib[1] = PF_LINK; --- 250,267 ---- syslog(LOG_ERR, "rstat: can't read cnt from kmem"); exit(1); } ! stats_all.s3.v_pgpgin = cnt.v_vnodepgsin; ! stats_all.s3.v_pgpgout = cnt.v_vnodepgsout; ! stats_all.s3.v_pswpin = cnt.v_swappgsin; ! stats_all.s3.v_pswpout = cnt.v_swappgsout; ! stats_all.s3.v_intr = cnt.v_intr; gettimeofday(&tm, (struct timezone *) 0); ! stats_all.s3.v_intr -= hz*(tm.tv_sec - btm.tv_sec) + hz*(tm.tv_usec - btm.tv_usec)/1000000; ! stats_all.s3.v_swtch = cnt.v_swtch; /* update disk transfers */ ! updatexfers(RSTAT_DK_NDRIVE, stats_all.s3.dk_xfer); mib[0] = CTL_NET; mib[1] = PF_LINK; *************** *** 272,283 **** syslog(LOG_ERR, "sysctl(net.link.generic.system.ifcount): %m"); exit(1); } ! ! stats_all.s1.if_ipackets = 0; ! stats_all.s1.if_opackets = 0; ! stats_all.s1.if_ierrors = 0; ! stats_all.s1.if_oerrors = 0; ! stats_all.s1.if_collisions = 0; for (i = 1; i <= ifcount; i++) { len = sizeof ifmd; mib[3] = IFMIB_IFDATA; --- 273,283 ---- syslog(LOG_ERR, "sysctl(net.link.generic.system.ifcount): %m"); exit(1); } ! stats_all.s3.if_ipackets = 0; ! stats_all.s3.if_opackets = 0; ! stats_all.s3.if_ierrors = 0; ! stats_all.s3.if_oerrors = 0; ! stats_all.s3.if_collisions = 0; for (i = 1; i <= ifcount; i++) { len = sizeof ifmd; mib[3] = IFMIB_IFDATA; *************** *** 287,305 **** if (errno == ENOENT) continue; ! syslog(LOG_ERR, "sysctl(net.link.ifdata.%d.general)" ! ": %m", i); exit(1); } ! ! stats_all.s1.if_ipackets += ifmd.ifmd_data.ifi_ipackets; ! stats_all.s1.if_opackets += ifmd.ifmd_data.ifi_opackets; ! stats_all.s1.if_ierrors += ifmd.ifmd_data.ifi_ierrors; ! stats_all.s1.if_oerrors += ifmd.ifmd_data.ifi_oerrors; ! stats_all.s1.if_collisions += ifmd.ifmd_data.ifi_collisions; } ! gettimeofday((struct timeval *)&stats_all.s3.curtime, ! (struct timezone *) 0); alarm(1); } --- 287,305 ---- if (errno == ENOENT) continue; ! syslog(LOG_ERR, "sysctl(net.link.ifdata.%d.general): %m", i); exit(1); } ! stats_all.s3.if_ipackets += ifmd.ifmd_data.ifi_ipackets; ! stats_all.s3.if_opackets += ifmd.ifmd_data.ifi_opackets; ! stats_all.s3.if_ierrors += ifmd.ifmd_data.ifi_ierrors; ! stats_all.s3.if_oerrors += ifmd.ifmd_data.ifi_oerrors; ! stats_all.s3.if_collisions += ifmd.ifmd_data.ifi_collisions; } ! ! gettimeofday(&tm, (struct timezone *) 0); ! stats_all.s3.curtime.tv_sec = tm.tv_sec; ! stats_all.s3.curtime.tv_usec = tm.tv_usec; alarm(1); } *************** *** 307,324 **** setup() { char errbuf[_POSIX2_LINE_MAX]; - int en; ! if ((kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf)) == NULL) { ! syslog(LOG_ERR, "rpc.rstatd, %s", errbuf); ! exit(1); } if ((en = kvm_nlist(kd, nl)) != 0) { syslog(LOG_ERR, "rstatd: Can't get namelist. %d", en); exit (1); ! } } /* --- 307,333 ---- setup() { char errbuf[_POSIX2_LINE_MAX]; int en; + static int is_kd_setup = 0; ! /* setup() is called after each dormant->active ! * transition. Since we never close the kvm files ! * (there's no reason), make sure we don't open them ! * each time, as that can lead to exhaustion of all open ! * files! */ ! if (!is_kd_setup) { ! kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf); ! if (kd == NULL) { ! syslog(LOG_ERR, "%s", errbuf); ! exit (1); ! } ! is_kd_setup = 1; } if ((en = kvm_nlist(kd, nl)) != 0) { syslog(LOG_ERR, "rstatd: Can't get namelist. %d", en); exit (1); ! } } /* From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 29 12:50:06 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B59F516A420 for ; Sun, 29 Jan 2006 12:50:06 +0000 (GMT) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40E2E43D45 for ; Sun, 29 Jan 2006 12:50:06 +0000 (GMT) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0ITU002ZNUKJSY90@osl1smout1.broadpark.no> for freebsd-amd64@freebsd.org; Sun, 29 Jan 2006 13:55:31 +0100 (CET) Received: from kg-work.kg4.no ([80.202.172.166]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0ITU001G6UFME740@osl1sminn1.broadpark.no> for freebsd-amd64@freebsd.org; Sun, 29 Jan 2006 13:52:35 +0100 (CET) Date: Sun, 29 Jan 2006 13:50:07 +0100 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH In-reply-to: <200601281850.07422.joao@matik.com.br> To: freebsd-amd64@freebsd.org Message-id: <20060129135007.11ee605e.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200601270957.44032.kono@kth.se> <200601280912.52907.joao@matik.com.br> <43DB7457.6050605@mail.uni-mainz.de> <200601281850.07422.joao@matik.com.br> Subject: Re: dual vs single core opteron 100's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 12:50:06 -0000 On Sat, 28 Jan 2006 18:50:05 -0200 JoaoBR wrote: > but money is a strong point when you get the same quantity of > "cherries" at the end, so the comparism is it worth to talk about and > find out the limits Can we pleas have more FreeBSD-related discussions on this mailinglist now? Please take this thread which is not specifically about FreeBSD eleswhere. Thank you. -- Regards, Torfinn Ingolfsen, Norway From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 29 17:28:05 2006 Return-Path: X-Original-To: Freebsd-amd64@freebsd.org Delivered-To: Freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7577416A420 for ; Sun, 29 Jan 2006 17:28:05 +0000 (GMT) (envelope-from ralf.folkerts@gmx.de) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id AC8DC43D55 for ; Sun, 29 Jan 2006 17:28:02 +0000 (GMT) (envelope-from ralf.folkerts@gmx.de) Received: (qmail invoked by alias); 29 Jan 2006 17:27:59 -0000 Received: from dslb-084-057-129-179.pools.arcor-ip.net (EHLO beaster) [84.57.129.179] by mail.gmx.net (mp019) with SMTP; 29 Jan 2006 18:27:59 +0100 X-Authenticated: #18511927 From: Ralf Folkerts To: Freebsd-amd64@freebsd.org Content-Type: text/plain Organization: Wohnzimmerrechenzentrum Date: Sun, 29 Jan 2006 18:27:58 +0100 Message-Id: <1138555678.915.20.camel@beaster> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Subject: Installation of print/acroread7 fails on my amd64-System X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 17:28:05 -0000 Hi, I've been trying to install print/acroread7 for a while on my amd64-System, but always ran into a Problem :-( It seems, the Port tries to fetch amd64-Version of Linux-Base-Ports, which it doesn't find :-( I already to to de- and reinstall liunx-base and also tried several different Linux-Bases, but neither helped. I also tried both to install acroread "manually" and via portupgrade, as there (were/are) issues with the Install of Linux-Base via Portupgrade on amd64... I enclosed the Versions of the installed Linux-Base (well, all "linux"-Ports indeed) and the full List of errors that show up after "make install"... Is there something wrong with my Ports-Tree? Or is something else broken on my System? Does anyone have a hint? MTIA, cheers, _ralf_ [-su]beaster:acroread7$portversion -v \*linux\* linux-expat-1.95.7 = up-to-date with port linux-fontconfig-2.2.3_2 = up-to-date with port linux-sun-jdk-1.4.2.10 = up-to-date with port linux_base-8-8.0_12 = up-to-date with port linuxpluginwrapper-20051113 = up-to-date with port [-su]beaster:acroread7$make install ===> Installing for acroread7-7.0.1 ===> acroread7-7.0.1 depends on file: /compat/linux/usr/lib/libgtk-x11-2.0.so.0 - not found ===> Verifying install for /compat/linux/usr/lib/libgtk-x11-2.0.so.0 in /usr/ports/x11-toolkits/linux-gtk2 => gtk2-2.4.14-4.fc3.3.amd64.rpm doesn't seem to exist in /usr/ports/distfiles/rpm. => Attempting to fetch from ftp://limestone.uoregon.edu/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://limestone.uoregon.edu/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://mirrors.kernel.org/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://mirrors.kernel.org/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://mirrors.kernel.org/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://mirrors.kernel.org/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://mirror.web-ster.com/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://mirror.web-ster.com/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://mirror.web-ster.com/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://mirror.web-ster.com/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://fedora.cs.utah.edu/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://fedora.cs.utah.edu/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://fedora.cat.pdx.edu/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://fedora.cat.pdx.edu/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://fedora.cat.pdx.edu/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://fedora.cat.pdx.edu/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://mirror.linux.duke.edu/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://mirror.linux.duke.edu/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://mirror.linux.duke.edu/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://mirror.linux.duke.edu/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://rpmfind.net/linux/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://rpmfind.net/linux/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://rpmfind.net/linux/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://rpmfind.net/linux/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://ftp.gtlib.cc.gatech.edu/pub/fedora.redhat/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.gtlib.cc.gatech.edu/pub/fedora.redhat/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://fedora.mirrors.tds.net/pub/fedora-core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://fedora.mirrors.tds.net/pub/fedora-core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://ftp.ale.org/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://ftp.ale.org/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.ale.org/mirrors/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.ale.org/mirrors/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Service not available, closing control connection => Attempting to fetch from http://ftp.ndlug.nd.edu/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://ftp.ndlug.nd.edu/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.ndlug.nd.edu/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.ndlug.nd.edu/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://fedora.server4you.net/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://fedora.server4you.net/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://fedora.server4you.net/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://fedora.server4you.net/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://fedora.mirrored.ca/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://fedora.mirrored.ca/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://fedora.mirrored.ca/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://fedora.mirrored.ca/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://ftp.scarlet.be/pub/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.scarlet.be/pub/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://ftp.belnet.be/linux/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://ftp.belnet.be/linux/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.belnet.be/linux/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.belnet.be/linux/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://sunsite.mff.cuni.cz/pub/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://sunsite.mff.cuni.cz/pub/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://sunsite.mff.cuni.cz/pub/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://sunsite.mff.cuni.cz/pub/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://ultra.linux.cz/pub/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ultra.linux.cz/pub/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://ftp.fi.muni.cz/pub/linux/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.fi.muni.cz/pub/linux/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: No route to host => Attempting to fetch from http://fr2.rpmfind.net/linux/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://fr2.rpmfind.net/linux/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://fr2.rpmfind.net/linux/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://fr2.rpmfind.net/linux/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://wftp.tu-chemnitz.de/pub/linux/fedora-core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://wftp.tu-chemnitz.de/pub/linux/fedora-core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.tu-chemnitz.de/pub/linux/fedora-core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.tu-chemnitz.de/pub/linux/fedora-core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://ftp.heanet.ie/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://ftp.heanet.ie/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.heanet.ie/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.heanet.ie/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://ftp.esat.net/pub/linux/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://ftp.esat.net/pub/linux/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.esat.net/pub/linux/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.esat.net/pub/linux/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://alviss.et.tudelft.nl/pub/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://alviss.et.tudelft.nl/pub/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://ftp.surfnet.nl/ftp/pub/os/Linux/distr/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://ftp.surfnet.nl/ftp/pub/os/Linux/distr/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.surfnet.nl/pub/os/Linux/distr/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.surfnet.nl/pub/os/Linux/distr/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://ftp.nluug.nl/ftp/pub/os/Linux/distr/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://ftp.nluug.nl/ftp/pub/os/Linux/distr/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.nluug.nl/pub/os/Linux/distr/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.nluug.nl/pub/os/Linux/distr/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://ftp.uninett.no/pub/linux/Fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.uninett.no/pub/linux/Fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://ftp.man.poznan.pl/pub/linux/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://ftp.man.poznan.pl/pub/linux/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Moved Temporarily => Attempting to fetch from ftp://ftp.man.poznan.pl/pub/linux/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.man.poznan.pl/pub/linux/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://ftp.ps.pl/pub/linux/fedora-core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://ftp.ps.pl/pub/linux/fedora-core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.ps.pl/pub/linux/fedora-core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.ps.pl/pub/linux/fedora-core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://ftp.idilis.ro/mirrors/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://ftp.idilis.ro/mirrors/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.idilis.ro/mirrors/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.idilis.ro/mirrors/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://ftp.kappa.ro/pub/Linux/Distributions/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.kappa.ro/pub/Linux/Distributions/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://mirror.etf.bg.ac.yu/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://mirror.etf.bg.ac.yu/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://mirror.etf.bg.ac.yu/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://mirror.etf.bg.ac.yu/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://ftp.chl.chalmers.se/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.chl.chalmers.se/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://ftp.hostrino.com/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.hostrino.com/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://ftp.sfc.wide.ad.jp/pub/Linux/Fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.sfc.wide.ad.jp/pub/Linux/Fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://ftp.kddilabs.jp/Linux/packages/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://ftp.kddilabs.jp/Linux/packages/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.kddilabs.jp/Linux/packages/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.kddilabs.jp/Linux/packages/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://ftp.riken.go.jp/pub/Linux/fedora/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.riken.go.jp/pub/Linux/fedora/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://ftp.isu.edu.tw/pub/Linux/Fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://ftp.isu.edu.tw/pub/Linux/Fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.isu.edu.tw/pub/Linux/Fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.isu.edu.tw/pub/Linux/Fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://public.planetmirror.com/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://public.planetmirror.com/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.planetmirror.com/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.planetmirror.com/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://www.las.ic.unicamp.br/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://www.las.ic.unicamp.br/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Operation timed out => Attempting to fetch from ftp://www.las.ic.unicamp.br/pub/fedora/linux/core/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://www.las.ic.unicamp.br/pub/fedora/linux/core/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Operation timed out => Attempting to fetch from ftp://mirror.netglobalis.net/pub/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://mirror.netglobalis.net/pub/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://mirror.pacific.net.au/linux/redhat/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://mirror.pacific.net.au/linux/redhat/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://mirror.pacific.net.au/linux/redhat/fedora/updates/3/i386/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://mirror.pacific.net.au/linux/redhat/fedora/updates/3/i386/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core//. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core//gtk2-2.4.14-4.fc3.3.amd64.rpm: Not Found => Attempting to fetch from ftp://ftp.uni-koeln.de/mirrors/fedora/linux/core//. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.uni-koeln.de/mirrors/fedora/linux/core//gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/rpm/. grep: /usr/ports/x11-toolkits/linux-gtk2/distinfo.amd64: No such file or directory fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/rpm/gtk2-2.4.14-4.fc3.3.amd64.rpm: File unavailable (e.g., file not found, no access) => Couldn't fetch it - please try to retrieve this => port manually into /usr/ports/distfiles/rpm and try again. *** Error code 1 Stop in /usr/ports/x11-toolkits/linux-gtk2. *** Error code 1 Stop in /usr/ports/print/acroread7. [-su]beaster:acroread7$ From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 29 18:19:37 2006 Return-Path: X-Original-To: Freebsd-amd64@freebsd.org Delivered-To: Freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5641516A420 for ; Sun, 29 Jan 2006 18:19:37 +0000 (GMT) (envelope-from sangwoos@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id B158A43D49 for ; Sun, 29 Jan 2006 18:19:36 +0000 (GMT) (envelope-from sangwoos@gmail.com) Received: by uproxy.gmail.com with SMTP id u2so553650uge for ; Sun, 29 Jan 2006 10:19:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z2HkV7q6fIoNVXSRLlNxCA2zRgS/tzQC1gFUCuUvgJP0FwpGeyqGkqEuQ1ceni9vGRNmxHH6jgHL7qH0ft4xajAf5R9P7Q/OZ0DQCc5VHie1qWQaGtm9B7YVkVAOQM1TflB3jfOI/Bng30ISPi1QcvSDLD20v/of+b/zz90Ehhs= Received: by 10.48.250.5 with SMTP id x5mr776380nfh; Sun, 29 Jan 2006 10:19:35 -0800 (PST) Received: by 10.48.214.8 with HTTP; Sun, 29 Jan 2006 10:19:34 -0800 (PST) Message-ID: <4cbd01f40601291019s3c0558cav@mail.gmail.com> Date: Mon, 30 Jan 2006 03:19:34 +0900 From: Sangwoo Shim To: Ralf Folkerts In-Reply-To: <1138555678.915.20.camel@beaster> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1138555678.915.20.camel@beaster> Cc: Freebsd-amd64@freebsd.org Subject: Re: Installation of print/acroread7 fails on my amd64-System X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 18:19:37 -0000 2006/1/30, Ralf Folkerts : > Hi, > > I've been trying to install print/acroread7 for a while on my > amd64-System, but always ran into a Problem :-( > > It seems, the Port tries to fetch amd64-Version of Linux-Base-Ports, > which it doesn't find :-( > > I already to to de- and reinstall liunx-base and also tried several > different Linux-Bases, but neither helped. I also tried both to install > acroread "manually" and via portupgrade, as there (were/are) issues with > the Install of Linux-Base via Portupgrade on amd64... > > I enclosed the Versions of the installed Linux-Base (well, all > "linux"-Ports indeed) and the full List of errors that show up after > "make install"... > > Is there something wrong with my Ports-Tree? Or is something else broken > on my System? Does anyone have a hint? > > > MTIA, > cheers, > _ralf_ > [snip] I've also experienced this problem several months ago, and submitted PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/87985 ...Althogh it didn't get much attention from the maintainer. -- Regards, Sangwoo Shim From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 29 18:43:57 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5E2516A420 for ; Sun, 29 Jan 2006 18:43:57 +0000 (GMT) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 533E443D46 for ; Sun, 29 Jan 2006 18:43:57 +0000 (GMT) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0ITV004AVAYABLB0@osl1smout1.broadpark.no> for freebsd-amd64@freebsd.org; Sun, 29 Jan 2006 19:49:22 +0100 (CET) Received: from kg-work.kg4.no ([80.202.172.166]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0ITV0043OATD6RA0@osl1sminn1.broadpark.no> for freebsd-amd64@freebsd.org; Sun, 29 Jan 2006 19:46:26 +0100 (CET) Date: Sun, 29 Jan 2006 19:43:58 +0100 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH In-reply-to: <4cbd01f40601291019s3c0558cav@mail.gmail.com> To: freebsd-amd64@freebsd.org Message-id: <20060129194358.34422cc5.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <1138555678.915.20.camel@beaster> <4cbd01f40601291019s3c0558cav@mail.gmail.com> Subject: Re: Installation of print/acroread7 fails on my amd64-System X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 18:43:57 -0000 On Mon, 30 Jan 2006 03:19:34 +0900 Sangwoo Shim wrote: > I've also experienced this problem several months ago, and submitted > PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/87985 > ...Althogh it didn't get much attention from the maintainer. I can confirm that I also see this problem, and that manually installing the linux-gtk2 port before installing acroread7 is a possible workaround. HTH -- Regards Torfinn Ingolfsen, Norway From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 29 19:42:43 2006 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DCEE16A420 for ; Sun, 29 Jan 2006 19:42:43 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 544F643D45 for ; Sun, 29 Jan 2006 19:42:43 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 82196F253F; Sun, 29 Jan 2006 11:42:42 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (triton.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30494-06; Sun, 29 Jan 2006 11:42:42 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 02AFFF24BD; Sun, 29 Jan 2006 11:42:41 -0800 (PST) From: Sean McNeil To: hotlips Internet admin In-Reply-To: <200601290730.k0T7U7kp084290@freefall.freebsd.org> References: <200601290730.k0T7U7kp084290@freefall.freebsd.org> Content-Type: text/plain Date: Sun, 29 Jan 2006 11:42:41 -0800 Message-Id: <1138563761.33172.1.camel@triton.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Cc: freebsd-amd64@FreeBSD.org Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 19:42:43 -0000 On Sun, 2006-01-29 at 07:30 +0000, hotlips Internet admin wrote: > The following reply was made to PR amd64/92412; it has been noted by GNATS. > > From: hotlips Internet admin > To: kris@obsecurity.org (Kris Kennaway) > Cc: bug-followup@FreeBSD.org > Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info > Date: Sun, 29 Jan 2006 02:25:33 -0500 (EST) > > Thus saith Kris Kennaway: > | On Fri, Jan 27, 2006 at 11:59:15AM -0500, hotlips Internet admin wrote: > | > | > | > >Description: > | > | > packets/second value reported by rpc.rstatd to remote monitor hovers around > | > | > 8000 or so with odd downward spikes approx every 90 seconds (it's not at > | > | all related to actual interface traffic) > | > | > > | > | > >How-To-Repeat: > | > | > keep displaying rpc.rstatd data from 6.0 system > | > | > | > | How are you using rpc.rstatd and rup? I don't see a way to make rup > | > | display "packets/second", it only gives uptime and load average: > | > | > | > | # rup > | > | fbsd-amd64.isc. 10:02am up 4 days, 14:00, load average: 2.00 2.00 2.00 > | > > | > Solaris perfmeter, actually. > | > | Do you know how I can query this on FreeBSD? > > > oop, wrong (older) diff - use this one below... The diff would be more readable if you only include useful changes and eliminate difference caused solely from white space. For instance, with diff -ub. Cheers, Sean From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 29 20:19:08 2006 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 487B116A420; Sun, 29 Jan 2006 20:19:08 +0000 (GMT) (envelope-from hostmaster@GTS.NET) Received: from fukspam.GTS.NET (hotlips.gts.net [204.138.66.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 800BE43D4C; Sun, 29 Jan 2006 20:19:07 +0000 (GMT) (envelope-from hostmaster@GTS.NET) Received: from localhost by fukspam.GTS.NET via sendmail with STDIO (/R:inet_hosts/T:inet_zone_smtp/dest:remote) id (7367 bytes from ident using UNIX) for ; Sun, 29 Jan 2006 15:19:05 -0500 (EST) (Smail-3.2.0.122-Pre 2005-Nov-17 #1; built 2006-Jan-22) Message-Id: From: hotlips Internet admin To: sean@mcneil.com (Sean McNeil) Date: Sun, 29 Jan 2006 15:19:04 -0500 (EST) In-Reply-To: <1138563761.33172.1.camel@triton.mcneil.com> from "Sean McNeil" at Jan 29, 2006 11:42:41 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 20:19:08 -0000 Thus saith Sean McNeil: | On Sun, 2006-01-29 at 07:30 +0000, hotlips Internet admin wrote: | > The following reply was made to PR amd64/92412; it has been noted by GNATS. | > From: hotlips Internet admin | > Thus saith Kris Kennaway: | > | On Fri, Jan 27, 2006 at 11:59:15AM -0500, hotlips Internet admin wrote: | > | | > | > | > >Description: | > | > | > packets/second value reported by rpc.rstatd to remote monitor hovers around | > | > | > 8000 or so with odd downward spikes approx every 90 seconds (it's not at | > | > | all related to actual interface traffic) | > | > | > | > | > | > >How-To-Repeat: | > | > | > keep displaying rpc.rstatd data from 6.0 system | > | > | | > | > | How are you using rpc.rstatd and rup? I don't see a way to make rup | > | > | display "packets/second", it only gives uptime and load average: | > | > | | > | > | # rup | > | > | fbsd-amd64.isc. 10:02am up 4 days, 14:00, load average: 2.00 2.00 2.00 | > | > | > | > Solaris perfmeter, actually. | > | | > | Do you know how I can query this on FreeBSD? | > | > oop, wrong (older) diff - use this one below... | | The diff would be more readable if you only include useful changes and | eliminate difference caused solely from white space. For instance, with | diff -ub. sorry, I've been trained to use diff -c; "-ub" version included velow. This fix should work for all 6.x FreeBSD (and probably 5.x too) - 4.x & 3.x seem to have issues with opackets systcl mib (always returns 0), so I made a version for them which uses the kmem interface as well as the other fixes shown below.... BTW, the sysutils/xsysstats package works fine for X users... -- Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@gts.net --------- 8< --------- 8< --------- 8< --------- 8< --------- 8< --------- --- rstat_proc.c.orig Sun Jun 1 22:34:36 2003 +++ rstat_proc.c Sun Jan 29 02:17:10 2006 @@ -138,6 +138,7 @@ if (! stat_is_init) stat_init(); sincelastreq = 0; + stats_all.s2.if_opackets = stats_all.s3.if_opackets; return(&stats_all.s2); } @@ -147,6 +148,7 @@ if (! stat_is_init) stat_init(); sincelastreq = 0; + stats_all.s1.if_opackets = stats_all.s3.if_opackets; return(&stats_all.s1); } @@ -219,13 +221,13 @@ exit(1); } for(i = 0; i < RSTAT_CPUSTATES ; i++) - stats_all.s1.cp_time[i] = bsd_cp_time[cp_time_xlat[i]]; + stats_all.s3.cp_time[i] = bsd_cp_time[cp_time_xlat[i]]; (void)getloadavg(avrun, sizeof(avrun) / sizeof(avrun[0])); - stats_all.s2.avenrun[0] = avrun[0] * FSCALE; - stats_all.s2.avenrun[1] = avrun[1] * FSCALE; - stats_all.s2.avenrun[2] = avrun[2] * FSCALE; + stats_all.s3.avenrun[0] = avrun[0] * FSCALE; + stats_all.s3.avenrun[1] = avrun[1] * FSCALE; + stats_all.s3.avenrun[2] = avrun[2] * FSCALE; mib[0] = CTL_KERN; mib[1] = KERN_BOOTTIME; @@ -234,14 +236,13 @@ syslog(LOG_ERR, "sysctl(kern.boottime): %m"); exit(1); } - - stats_all.s2.boottime.tv_sec = btm.tv_sec; - stats_all.s2.boottime.tv_usec = btm.tv_usec; + stats_all.s3.boottime.tv_sec = btm.tv_sec; + stats_all.s3.boottime.tv_usec = btm.tv_usec; #ifdef DEBUG - fprintf(stderr, "%d %d %d %d\n", stats_all.s1.cp_time[0], - stats_all.s1.cp_time[1], stats_all.s1.cp_time[2], stats_all.s1.cp_time[3]); + fprintf(stderr, "%d %d %d %d\n", stats_all.s3.cp_time[0], + stats_all.s3.cp_time[1], stats_all.s3.cp_time[2], stats_all.s3.cp_time[3]); #endif /* XXX - should use sysctl */ @@ -249,18 +250,18 @@ syslog(LOG_ERR, "rstat: can't read cnt from kmem"); exit(1); } - stats_all.s1.v_pgpgin = cnt.v_vnodepgsin; - stats_all.s1.v_pgpgout = cnt.v_vnodepgsout; - stats_all.s1.v_pswpin = cnt.v_swappgsin; - stats_all.s1.v_pswpout = cnt.v_swappgsout; - stats_all.s1.v_intr = cnt.v_intr; + stats_all.s3.v_pgpgin = cnt.v_vnodepgsin; + stats_all.s3.v_pgpgout = cnt.v_vnodepgsout; + stats_all.s3.v_pswpin = cnt.v_swappgsin; + stats_all.s3.v_pswpout = cnt.v_swappgsout; + stats_all.s3.v_intr = cnt.v_intr; gettimeofday(&tm, (struct timezone *) 0); - stats_all.s1.v_intr -= hz*(tm.tv_sec - btm.tv_sec) + + stats_all.s3.v_intr -= hz*(tm.tv_sec - btm.tv_sec) + hz*(tm.tv_usec - btm.tv_usec)/1000000; - stats_all.s2.v_swtch = cnt.v_swtch; + stats_all.s3.v_swtch = cnt.v_swtch; /* update disk transfers */ - updatexfers(RSTAT_DK_NDRIVE, stats_all.s1.dk_xfer); + updatexfers(RSTAT_DK_NDRIVE, stats_all.s3.dk_xfer); mib[0] = CTL_NET; mib[1] = PF_LINK; @@ -272,12 +273,11 @@ syslog(LOG_ERR, "sysctl(net.link.generic.system.ifcount): %m"); exit(1); } - - stats_all.s1.if_ipackets = 0; - stats_all.s1.if_opackets = 0; - stats_all.s1.if_ierrors = 0; - stats_all.s1.if_oerrors = 0; - stats_all.s1.if_collisions = 0; + stats_all.s3.if_ipackets = 0; + stats_all.s3.if_opackets = 0; + stats_all.s3.if_ierrors = 0; + stats_all.s3.if_oerrors = 0; + stats_all.s3.if_collisions = 0; for (i = 1; i <= ifcount; i++) { len = sizeof ifmd; mib[3] = IFMIB_IFDATA; @@ -287,19 +287,19 @@ if (errno == ENOENT) continue; - syslog(LOG_ERR, "sysctl(net.link.ifdata.%d.general)" - ": %m", i); + syslog(LOG_ERR, "sysctl(net.link.ifdata.%d.general): %m", i); exit(1); } - - stats_all.s1.if_ipackets += ifmd.ifmd_data.ifi_ipackets; - stats_all.s1.if_opackets += ifmd.ifmd_data.ifi_opackets; - stats_all.s1.if_ierrors += ifmd.ifmd_data.ifi_ierrors; - stats_all.s1.if_oerrors += ifmd.ifmd_data.ifi_oerrors; - stats_all.s1.if_collisions += ifmd.ifmd_data.ifi_collisions; + stats_all.s3.if_ipackets += ifmd.ifmd_data.ifi_ipackets; + stats_all.s3.if_opackets += ifmd.ifmd_data.ifi_opackets; + stats_all.s3.if_ierrors += ifmd.ifmd_data.ifi_ierrors; + stats_all.s3.if_oerrors += ifmd.ifmd_data.ifi_oerrors; + stats_all.s3.if_collisions += ifmd.ifmd_data.ifi_collisions; } - gettimeofday((struct timeval *)&stats_all.s3.curtime, - (struct timezone *) 0); + + gettimeofday(&tm, (struct timezone *) 0); + stats_all.s3.curtime.tv_sec = tm.tv_sec; + stats_all.s3.curtime.tv_usec = tm.tv_usec; alarm(1); } @@ -307,12 +307,21 @@ setup() { char errbuf[_POSIX2_LINE_MAX]; - int en; + static int is_kd_setup = 0; - if ((kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf)) == NULL) { - syslog(LOG_ERR, "rpc.rstatd, %s", errbuf); - exit(1); + /* setup() is called after each dormant->active + * transition. Since we never close the kvm files + * (there's no reason), make sure we don't open them + * each time, as that can lead to exhaustion of all open + * files! */ + if (!is_kd_setup) { + kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf); + if (kd == NULL) { + syslog(LOG_ERR, "%s", errbuf); + exit (1); + } + is_kd_setup = 1; } if ((en = kvm_nlist(kd, nl)) != 0) { From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 29 20:20:09 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7660B16A420 for ; Sun, 29 Jan 2006 20:20:09 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C62C43D4C for ; Sun, 29 Jan 2006 20:20:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0TKK7bw035658 for ; Sun, 29 Jan 2006 20:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0TKK7Jh035657; Sun, 29 Jan 2006 20:20:07 GMT (envelope-from gnats) Date: Sun, 29 Jan 2006 20:20:07 GMT Message-Id: <200601292020.k0TKK7Jh035657@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: hotlips Internet admin Cc: Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hotlips Internet admin List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 20:20:09 -0000 The following reply was made to PR amd64/92412; it has been noted by GNATS. From: hotlips Internet admin To: sean@mcneil.com (Sean McNeil) Cc: bug-followup@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info Date: Sun, 29 Jan 2006 15:19:04 -0500 (EST) Thus saith Sean McNeil: | On Sun, 2006-01-29 at 07:30 +0000, hotlips Internet admin wrote: | > The following reply was made to PR amd64/92412; it has been noted by GNATS. | > From: hotlips Internet admin | > Thus saith Kris Kennaway: | > | On Fri, Jan 27, 2006 at 11:59:15AM -0500, hotlips Internet admin wrote: | > | | > | > | > >Description: | > | > | > packets/second value reported by rpc.rstatd to remote monitor hovers around | > | > | > 8000 or so with odd downward spikes approx every 90 seconds (it's not at | > | > | all related to actual interface traffic) | > | > | > | > | > | > >How-To-Repeat: | > | > | > keep displaying rpc.rstatd data from 6.0 system | > | > | | > | > | How are you using rpc.rstatd and rup? I don't see a way to make rup | > | > | display "packets/second", it only gives uptime and load average: | > | > | | > | > | # rup | > | > | fbsd-amd64.isc. 10:02am up 4 days, 14:00, load average: 2.00 2.00 2.00 | > | > | > | > Solaris perfmeter, actually. | > | | > | Do you know how I can query this on FreeBSD? | > | > oop, wrong (older) diff - use this one below... | | The diff would be more readable if you only include useful changes and | eliminate difference caused solely from white space. For instance, with | diff -ub. sorry, I've been trained to use diff -c; "-ub" version included velow. This fix should work for all 6.x FreeBSD (and probably 5.x too) - 4.x & 3.x seem to have issues with opackets systcl mib (always returns 0), so I made a version for them which uses the kmem interface as well as the other fixes shown below.... BTW, the sysutils/xsysstats package works fine for X users... -- Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@gts.net --------- 8< --------- 8< --------- 8< --------- 8< --------- 8< --------- --- rstat_proc.c.orig Sun Jun 1 22:34:36 2003 +++ rstat_proc.c Sun Jan 29 02:17:10 2006 @@ -138,6 +138,7 @@ if (! stat_is_init) stat_init(); sincelastreq = 0; + stats_all.s2.if_opackets = stats_all.s3.if_opackets; return(&stats_all.s2); } @@ -147,6 +148,7 @@ if (! stat_is_init) stat_init(); sincelastreq = 0; + stats_all.s1.if_opackets = stats_all.s3.if_opackets; return(&stats_all.s1); } @@ -219,13 +221,13 @@ exit(1); } for(i = 0; i < RSTAT_CPUSTATES ; i++) - stats_all.s1.cp_time[i] = bsd_cp_time[cp_time_xlat[i]]; + stats_all.s3.cp_time[i] = bsd_cp_time[cp_time_xlat[i]]; (void)getloadavg(avrun, sizeof(avrun) / sizeof(avrun[0])); - stats_all.s2.avenrun[0] = avrun[0] * FSCALE; - stats_all.s2.avenrun[1] = avrun[1] * FSCALE; - stats_all.s2.avenrun[2] = avrun[2] * FSCALE; + stats_all.s3.avenrun[0] = avrun[0] * FSCALE; + stats_all.s3.avenrun[1] = avrun[1] * FSCALE; + stats_all.s3.avenrun[2] = avrun[2] * FSCALE; mib[0] = CTL_KERN; mib[1] = KERN_BOOTTIME; @@ -234,14 +236,13 @@ syslog(LOG_ERR, "sysctl(kern.boottime): %m"); exit(1); } - - stats_all.s2.boottime.tv_sec = btm.tv_sec; - stats_all.s2.boottime.tv_usec = btm.tv_usec; + stats_all.s3.boottime.tv_sec = btm.tv_sec; + stats_all.s3.boottime.tv_usec = btm.tv_usec; #ifdef DEBUG - fprintf(stderr, "%d %d %d %d\n", stats_all.s1.cp_time[0], - stats_all.s1.cp_time[1], stats_all.s1.cp_time[2], stats_all.s1.cp_time[3]); + fprintf(stderr, "%d %d %d %d\n", stats_all.s3.cp_time[0], + stats_all.s3.cp_time[1], stats_all.s3.cp_time[2], stats_all.s3.cp_time[3]); #endif /* XXX - should use sysctl */ @@ -249,18 +250,18 @@ syslog(LOG_ERR, "rstat: can't read cnt from kmem"); exit(1); } - stats_all.s1.v_pgpgin = cnt.v_vnodepgsin; - stats_all.s1.v_pgpgout = cnt.v_vnodepgsout; - stats_all.s1.v_pswpin = cnt.v_swappgsin; - stats_all.s1.v_pswpout = cnt.v_swappgsout; - stats_all.s1.v_intr = cnt.v_intr; + stats_all.s3.v_pgpgin = cnt.v_vnodepgsin; + stats_all.s3.v_pgpgout = cnt.v_vnodepgsout; + stats_all.s3.v_pswpin = cnt.v_swappgsin; + stats_all.s3.v_pswpout = cnt.v_swappgsout; + stats_all.s3.v_intr = cnt.v_intr; gettimeofday(&tm, (struct timezone *) 0); - stats_all.s1.v_intr -= hz*(tm.tv_sec - btm.tv_sec) + + stats_all.s3.v_intr -= hz*(tm.tv_sec - btm.tv_sec) + hz*(tm.tv_usec - btm.tv_usec)/1000000; - stats_all.s2.v_swtch = cnt.v_swtch; + stats_all.s3.v_swtch = cnt.v_swtch; /* update disk transfers */ - updatexfers(RSTAT_DK_NDRIVE, stats_all.s1.dk_xfer); + updatexfers(RSTAT_DK_NDRIVE, stats_all.s3.dk_xfer); mib[0] = CTL_NET; mib[1] = PF_LINK; @@ -272,12 +273,11 @@ syslog(LOG_ERR, "sysctl(net.link.generic.system.ifcount): %m"); exit(1); } - - stats_all.s1.if_ipackets = 0; - stats_all.s1.if_opackets = 0; - stats_all.s1.if_ierrors = 0; - stats_all.s1.if_oerrors = 0; - stats_all.s1.if_collisions = 0; + stats_all.s3.if_ipackets = 0; + stats_all.s3.if_opackets = 0; + stats_all.s3.if_ierrors = 0; + stats_all.s3.if_oerrors = 0; + stats_all.s3.if_collisions = 0; for (i = 1; i <= ifcount; i++) { len = sizeof ifmd; mib[3] = IFMIB_IFDATA; @@ -287,19 +287,19 @@ if (errno == ENOENT) continue; - syslog(LOG_ERR, "sysctl(net.link.ifdata.%d.general)" - ": %m", i); + syslog(LOG_ERR, "sysctl(net.link.ifdata.%d.general): %m", i); exit(1); } - - stats_all.s1.if_ipackets += ifmd.ifmd_data.ifi_ipackets; - stats_all.s1.if_opackets += ifmd.ifmd_data.ifi_opackets; - stats_all.s1.if_ierrors += ifmd.ifmd_data.ifi_ierrors; - stats_all.s1.if_oerrors += ifmd.ifmd_data.ifi_oerrors; - stats_all.s1.if_collisions += ifmd.ifmd_data.ifi_collisions; + stats_all.s3.if_ipackets += ifmd.ifmd_data.ifi_ipackets; + stats_all.s3.if_opackets += ifmd.ifmd_data.ifi_opackets; + stats_all.s3.if_ierrors += ifmd.ifmd_data.ifi_ierrors; + stats_all.s3.if_oerrors += ifmd.ifmd_data.ifi_oerrors; + stats_all.s3.if_collisions += ifmd.ifmd_data.ifi_collisions; } - gettimeofday((struct timeval *)&stats_all.s3.curtime, - (struct timezone *) 0); + + gettimeofday(&tm, (struct timezone *) 0); + stats_all.s3.curtime.tv_sec = tm.tv_sec; + stats_all.s3.curtime.tv_usec = tm.tv_usec; alarm(1); } @@ -307,12 +307,21 @@ setup() { char errbuf[_POSIX2_LINE_MAX]; - int en; + static int is_kd_setup = 0; - if ((kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf)) == NULL) { - syslog(LOG_ERR, "rpc.rstatd, %s", errbuf); - exit(1); + /* setup() is called after each dormant->active + * transition. Since we never close the kvm files + * (there's no reason), make sure we don't open them + * each time, as that can lead to exhaustion of all open + * files! */ + if (!is_kd_setup) { + kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf); + if (kd == NULL) { + syslog(LOG_ERR, "%s", errbuf); + exit (1); + } + is_kd_setup = 1; } if ((en = kvm_nlist(kd, nl)) != 0) { From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 29 21:31:34 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C3FF16A420 for ; Sun, 29 Jan 2006 21:31:34 +0000 (GMT) (envelope-from fernando@schapachnik.com.ar) Received: from servidor1.cursosvirtuales.com.ar (www.cursosvirtuales.com.ar [200.59.46.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C91443D48 for ; Sun, 29 Jan 2006 21:31:30 +0000 (GMT) (envelope-from fernando@schapachnik.com.ar) Received: from servidor1.cursosvirtuales.com.ar (localhost [127.0.0.1]) by servidor1.cursosvirtuales.com.ar (8.12.11/8.12.11) with ESMTP id k0TLVNPl049735; Sun, 29 Jan 2006 18:31:23 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: from schapachnik.com.ar (uucp@localhost) by servidor1.cursosvirtuales.com.ar (8.12.11/8.12.11/Submit) with UUCP id k0TLVNTo049734; Sun, 29 Jan 2006 18:31:23 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: from funes.schapachnik.com.ar (localhost [127.0.0.1]) by funes.schapachnik.com.ar (8.13.4/8.13.4) with ESMTP id k0TLVIG3008886; Sun, 29 Jan 2006 18:31:18 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: (from fpscha@localhost) by funes.schapachnik.com.ar (8.13.4/8.13.4/Submit) id k0TLVIOx008885; Sun, 29 Jan 2006 18:31:18 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) X-Authentication-Warning: funes.schapachnik.com.ar: fpscha set sender to fernando@schapachnik.com.ar using -f Date: Sun, 29 Jan 2006 18:31:17 -0300 From: Fernando Schapachnik To: Lennart Sorth Message-ID: <20060129213117.GH820@funes.schapachnik.com.ar> References: <20060127020350.02abf989.kgunders@teamcool.net> <200601271228.02675.groot@kde.org> <43DA1A5A.3000409@uni-c.dk> <20060127232359.GI930@funes.schapachnik.com.ar> <26820.217.157.164.63.1138560432.squirrel@webmail.uni-c.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <26820.217.157.164.63.1138560432.squirrel@webmail.uni-c.dk> User-Agent: Mutt/1.4.2.1i X-OS: FreeBSD 6.0 - http://www.freebsd.org Cc: freebsd-amd64@freebsd.org Subject: Re: fbsd-amd64 desktop X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 21:31:34 -0000 En un mensaje anterior, Lennart Sorth escribió: > Fernando Schapachnik said: > >> ... as long as you don't need win32-codecs > > > > Or vmware, or wine... > > yes, but in fact qemu runs fine :) You are right, qemu 0.8.0 does run fine (0.7.0 didn't)! Fernando P. Schapachnik fernando@schapachnik.com.ar From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 30 04:19:35 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4958016A45C for ; Mon, 30 Jan 2006 04:19:35 +0000 (GMT) (envelope-from dleigh@cs.rmit.edu.au) Received: from its-mu-mail4.its.rmit.edu.au (its-mu-mail4.its.rmit.edu.au [131.170.2.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F53943D48 for ; Mon, 30 Jan 2006 04:19:33 +0000 (GMT) (envelope-from dleigh@cs.rmit.edu.au) Received: from wombat.cs.rmit.edu.au (wombat.cs.rmit.edu.au [131.170.24.41]) by its-mu-mail4.its.rmit.edu.au (8.13.1/8.13.1/mail4) with ESMTP id k0U4JUNX020422 for ; Mon, 30 Jan 2006 15:19:30 +1100 (EST) Received: from yallara.cs.rmit.edu.au (root@yallara.cs.rmit.edu.au [131.170.24.42]) by wombat.cs.rmit.edu.au (8.12.10/8.12.10/cshub) with ESMTP id k0U4JUPq020071 for ; Mon, 30 Jan 2006 15:19:30 +1100 (EST) Received: from yallara.cs.rmit.edu.au (dleigh@localhost [127.0.0.1]) by yallara.cs.rmit.edu.au (8.13.4+Sun/8.13.4/csnode) with ESMTP id k0U4JUDj010845 for ; Mon, 30 Jan 2006 15:19:30 +1100 (EST) Received: (from dleigh@localhost) by yallara.cs.rmit.edu.au (8.13.4+Sun/8.13.3/Submit) id k0U4JTY1010843 for freebsd-amd64@freebsd.org; Mon, 30 Jan 2006 15:19:29 +1100 (EST) Date: Mon, 30 Jan 2006 15:19:29 +1100 From: Dylan Leigh To: freebsd-amd64@freebsd.org Message-ID: <20060130041929.GA9866@cs.rmit.edu.au> References: <20060129120041.6FFDE16A422@hub.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <20060129120041.6FFDE16A422@hub.freebsd.org> X-PGP-Fingerprint: D2B4 7C14 0C41 9AE5 8D2B 16B0 D3D6 F910 8E4C 5D35 X-PGP-Insecure-Machine: Yes X-RMIT-Student-Number: 3017239 X-Author-Webpage: http://yallara.cs.rmit.edu.au/~dleigh User-Agent: Mutt/1.5.10i X-Scanned-By: MIMEDefang 2.44 Subject: Re: version 6.0 and AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2006 04:19:35 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > On Monday 26 December 2005 21:35, je killen wrote: > >> I purchased Version 6.0 from FreeBSD Mall and am now concerned > >> that the packaged system will work on AMD64 which I have, The > >> processor I have and want to use is socket 754, if it makes a > >> difference. > > > > Socket 754 is an amd64 socket, so that'll be fine (unless there > > are socket 754 Semprons without 64-bit? The AMD website doesn't > > say in so many words "this is not a 64-bit processor", but > > neither does it tout 64-bitness. In that case, it's not the > > socket type that's most interesting, but the CPU family (Athlon64 > > vs. Sempron) that is.). >=20 > Until summer 2005 semprons were 32bit only. I have 2 sempron 64bit > working with freebsd 6 amd64. On 754 there is no dual channel, > cache L2 is lower (256 on most recent semprons, 128 on olders vs > 512 and 1024 on 939 amd64) etc... > I'm also running amd64 on a 64 Bit Sempron. AFAIK Semprons with the letters "BX" at the end of their serial number are 64bit (these were made after July 2005). --=20 Dylan Leigh - http://yallara.cs.rmit.edu.au/~dleigh/ --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (SunOS) iD8DBQFD3ZPRSzNTcqehJbMRAnj1AKCDwkG271gj3rl7FNeKGN7CQSwSgQCgwvMa eSGHfyiQIF3jF4iYfEqqecM= =x9HO -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 30 09:10:04 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EE8816A420 for ; Mon, 30 Jan 2006 09:10:04 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 725E843D55 for ; Mon, 30 Jan 2006 09:10:03 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0U9A3SC095464 for ; Mon, 30 Jan 2006 09:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0U9A3E7095458; Mon, 30 Jan 2006 09:10:03 GMT (envelope-from gnats) Resent-Date: Mon, 30 Jan 2006 09:10:03 GMT Resent-Message-Id: <200601300910.k0U9A3E7095458@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, lissyara Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D956916A420 for ; Mon, 30 Jan 2006 09:01:27 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1EF943D6A for ; Mon, 30 Jan 2006 09:01:18 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k0U91IP6074082 for ; Mon, 30 Jan 2006 09:01:18 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k0U91IKX074081; Mon, 30 Jan 2006 09:01:18 GMT (envelope-from nobody) Message-Id: <200601300901.k0U91IKX074081@www.freebsd.org> Date: Mon, 30 Jan 2006 09:01:18 GMT From: lissyara To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/92527: no driver for "CICADA VSC 8201 Gigabit LAN PHY " on motherboard GA-K8N51GMF-9 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2006 09:10:04 -0000 >Number: 92527 >Category: amd64 >Synopsis: no driver for "CICADA VSC 8201 Gigabit LAN PHY " on motherboard GA-K8N51GMF-9 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Mon Jan 30 09:10:02 GMT 2006 >Closed-Date: >Last-Modified: >Originator: lissyara >Release: 6.0 >Organization: OOO "DERZHAVA" >Environment: FreeBSD bsd.derzhava.com 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Wed Nov 2 19:07:38 UTC 2005 root@rat.samsco.home:/usr/obj/usr/src/sys/GENERIC amd64 >Description: No driver for "CICADA VSC 8201 Gigabit LAN PHY " on motherboard GA-K8N51GMF-9 ==== dmesg ======= Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-RELEASE #0: Wed Nov 2 19:07:38 UTC 2005 root@rat.samsco.home:/usr/obj/usr/src/sys/GENERIC ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3200+ (2009.16-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20ff2 Stepping = 2 Features=0x78bfbff Features2=0x1 AMD Features=0xe2500800,LM,3DNow+,3DNow> real memory = 1056899072 (1007 MB) avail memory = 1009012736 (962 MB) ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR pci_link0: irq 10 on acpi0 pci_link1: irq 11 on acpi0 pci_link2: on acpi0 pci_link3: on acpi0 pci_link4: on acpi0 pci_link5: on acpi0 pci_link6: irq 7 on acpi0 pci_link7: on acpi0 pci_link8: irq 11 on acpi0 pci_link9: on acpi0 pci_link10: irq 5 on acpi0 pci_link11: on acpi0 pci_link12: on acpi0 pci_link13: on acpi0 pci_link14: on acpi0 pci_link15: irq 5 on acpi0 pci_link16: irq 10 on acpi0 pci_link17: on acpi0 pci_link18: on acpi0 pci_link19: on acpi0 pci_link20: irq 0 on acpi0 pci_link21: irq 0 on acpi0 pci_link21: irq 0 on acpi0 pci_link22: irq 0 on acpi0 pci_link23: irq 0 on acpi0 pci_link24: irq 0 on acpi0 pci_link25: irq 0 on acpi0 pci_link26: irq 0 on acpi0 pci_link27: irq 0 on acpi0 pci_link28: irq 0 on acpi0 pci_link29: irq 0 on acpi0 pci_link30: irq 0 on acpi0 pci_link31: irq 0 on acpi0 pci_link32: irq 0 on acpi0 pci_link33: irq 0 on acpi0 pci_link34: irq 0 on acpi0 pci_link35: irq 0 on acpi0 pci_link36: irq 0 on acpi0 pci_link37: irq 0 on acpi0 pci_link38: irq 0 on acpi0 pci_link39: irq 0 on acpi0 pci_link40: irq 0 on acpi0 ACPI-0501: *** Error: Handler for [SystemMemory] returned AE_AML_ALIGNMENT ACPI-1304: *** Error: Method execution failed [\\_SB_.MEM_._CRS] (Node 0xffffff0000aa9dc0), AE_AML_ALIGNMENT ACPI-0239: *** Error: Method execution failed [\\_SB_.MEM_._CRS] (Node 0xffffff0000aa9dc0), AE_AML_ALIGNMENT can't fetch resources for \\_SB_.MEM_ - AE_AML_ALIGNMENT cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci_link35: BIOS IRQ 5 for -2145774616.10.INTA is invalid pci_link30: BIOS IRQ 5 for -2145774616.20.INTA is invalid pci_link26: BIOS IRQ 7 for -2145774616.5.INTA is invalid pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pci0: at device 5.0 (no driver attached) pci0: at device 9.0 (no driver attached) isab0: at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) pci0: at device 10.2 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 13.0 on pci0 ata0: on atapci0 ata1: on atapci0 pcib1: at device 16.0 on pci0 pci1: on pcib1 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd000-0xd07f mem 0xf4000000-0xf400007f irq 16 at device 6.0 on pci1 miibus0: on xl0 bmtphy0: <3c905B 10/100 internal PHY> on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:50:04:ea:34:7f sym0: <895> port 0xd400-0xd4ff mem 0xf4001000-0xf40010ff,0xf4002000-0xf4002fff irq 17 at device 7.0 on pci1 sym0: Tekram NVRAM, ID 7, Fast-40, LVD, parity checking sym0: [GIANT-LOCKED] pci0: at device 20.0 (no driver attached) fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2009158227 Hz quality 800 Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle ad0: 38165MB at ata0-master UDMA33 ad1: 286167MB at ata0-slave UDMA33 acd0: DVDR at ata1-master UDMA33 sa0 at sym0 bus 0 target 3 lun 0 sa0: Removable Sequential Access SCSI-3 device sa0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit) ======= end dmesg ========== driver `device nve` build into kernell >How-To-Repeat: boot :) >Fix: no >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 30 11:02:11 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC77916A420 for ; Mon, 30 Jan 2006 11:02:11 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7495143D45 for ; Mon, 30 Jan 2006 11:02:11 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0UB2Brq019161 for ; Mon, 30 Jan 2006 11:02:11 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0UB289r019142 for freebsd-amd64@freebsd.org; Mon, 30 Jan 2006 11:02:08 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 30 Jan 2006 11:02:08 GMT Message-Id: <200601301102.k0UB289r019142@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-amd64@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2006 11:02:11 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/08/09] amd64/84693 amd64 Keyboard not recognized during first step o [2005/11/17] amd64/89202 amd64 [ufs] [panic] Kernel crash when accessing o [2006/01/26] amd64/92337 amd64 FreeBsd 6.0 Release Intel Pro 1000 MT em1 o [2006/01/27] amd64/92410 amd64 calloc.c missing from Makefile.inc 4 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/11/26] amd64/59714 amd64 device timeout and ad0: WARNING - WRITE_D o [2004/07/28] amd64/69704 amd64 ext2/ext3 unstable in amd64 o [2004/07/28] amd64/69707 amd64 IPC32 dont work OK in amd64 FreeBSD o [2004/09/07] amd64/71471 amd64 Can not install 5.3beta3/amd64 on IBM eSe o [2004/09/12] amd64/71644 amd64 [panic] amd64 5.3-BETA4 crash when heavy o [2004/10/28] amd64/73252 amd64 ad6: WARNING - READ_DMA interrupt was see o [2004/10/30] amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdo o [2004/11/07] amd64/73650 amd64 5.3-release panics on boot o [2004/11/10] amd64/73775 amd64 Kernel panic (trap 12) when booting with o [2004/11/16] amd64/74014 amd64 5.3-RELEASE-AMD64 freezes on boot during o [2004/12/05] amd64/74747 amd64 System panic on shutdown when process wil o [2004/12/18] amd64/75209 amd64 5.3-Release panics on attempted boot from o [2004/12/23] amd64/75417 amd64 ACPI: SATA Hard-disk o [2005/01/12] amd64/76136 amd64 system halts before reboot o [2005/01/17] amd64/76336 amd64 racoon/setkey -D cases instant "Fatal Tra o [2005/02/02] amd64/77011 amd64 consisten 5.3-p5 make crash on installwor o [2005/02/23] amd64/77949 amd64 Pb boot FreeBSD 64 o [2005/03/04] amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/p o [2005/03/07] amd64/78558 amd64 installation o [2005/03/14] amd64/78848 amd64 [sis] sis driver on FreeBSD 5.x does not o [2005/04/12] amd64/79813 amd64 Will not install/run on amd64 nForce 4 pl o [2005/04/19] amd64/80114 amd64 kldload snd_ich causes interrupt storm wh o [2005/05/06] amd64/80691 amd64 amd64 kernel hangs on load o [2005/05/14] amd64/81037 amd64 SATA problem o [2005/05/28] amd64/81602 amd64 SATA crashes with parallel pcm access o [2005/06/09] amd64/82071 amd64 incorrect -march's parameter to build 32b o [2005/06/19] amd64/82425 amd64 [fxp] fxp0: device timeout, fxp interface o [2005/06/23] amd64/82555 amd64 Kernel Panic - after i connect to my "amd o [2005/07/05] amd64/83005 amd64 Memory Occupied during installation of th o [2005/08/12] amd64/84832 amd64 Installation crashes just at boot AMD64/ o [2005/08/14] amd64/84930 amd64 [msdosfs] something wrong with msdosfs on o [2005/08/29] amd64/85431 amd64 AMD64 has short but temporary freezes (ha o [2005/08/29] amd64/85451 amd64 [hang] 6.0-BETA3 lockups on AMD64 (PREEMP o [2005/09/13] amd64/86080 amd64 [radeon] [hang] radeon DRI causes system o [2005/09/23] amd64/86503 amd64 [atapicam] [panic] k3b crash the system l o [2005/10/09] amd64/87156 amd64 First Installation: Kernel crashes o [2005/10/11] amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Are o [2005/10/12] amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powe o [2005/10/12] amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD a [2005/10/12] amd64/87328 amd64 [boot] BTX halted error o [2005/10/12] amd64/87348 amd64 amd64+smp+startkde always crashing o [2005/10/15] amd64/87472 amd64 I downloaded 5.4 and went to install it, o [2005/10/16] amd64/87514 amd64 6.0-CURRENT freezes machine using >4GB on o [2005/10/19] amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron o [2005/10/25] amd64/87977 amd64 [busdma] [panic] amd64 busdma dflt_lock c o [2005/10/31] amd64/88299 amd64 swapcontext fails with errno 0 o [2005/11/06] amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not b f [2005/11/09] amd64/88746 amd64 Buffer problem with SSH2 under amd64 arch o [2005/11/10] amd64/88790 amd64 kernel panic on first boot (after the Fre o [2005/11/24] amd64/89501 amd64 System crashes on install using ftp on lo o [2005/11/24] amd64/89503 amd64 Cant Boot Installation Disk o [2005/11/25] amd64/89546 amd64 [geom] GEOM error o [2005/11/25] amd64/89549 amd64 [amd64] nve timeouts on 6.0-release o [2005/11/25] amd64/89550 amd64 [amd64] sym0: VTOBUS failed (6.0 Release) o [2005/12/05] amd64/89968 amd64 [ata] Asus A8N-E MediaShield RAID problem o [2005/12/22] amd64/90798 amd64 asking if motherboard is compatible o [2006/01/06] amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr o [2006/01/08] amd64/91492 amd64 BTX halted 58 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/01/11] amd64/61209 amd64 ppc0: cannot reserve I/O port range o [2004/02/21] amd64/63188 amd64 [ti] ti(4) broken on amd64 o [2004/07/28] amd64/69705 amd64 IPC problem (msq_queues) o [2004/12/02] amd64/74608 amd64 [mpt] [hang] mpt hangs 5 minutes when boo o [2004/12/07] amd64/74811 amd64 [nfs] df, nfs mount, negative Avail -> 32 o [2004/12/13] ports/75015 amd64 cvsup on amd64 coredumps with either runs o [2005/03/17] amd64/78954 amd64 kerberos 5 failed to build o [2005/06/18] amd64/82399 amd64 MSI K8N Neo4 Platinium is not supported o [2005/08/07] amd64/84652 amd64 kbdmap -r dumps core o [2005/08/20] amd64/85144 amd64 Asus K8S-MX mobo, integ LAN not recognize o [2005/09/06] amd64/85812 amd64 "Rebooting..." on serial console appears o [2005/09/07] amd64/85820 amd64 1.5 times slower performance with SCHED_U o [2005/10/23] amd64/87882 amd64 emu10k1 and APCI on amd64 is just noisy o [2005/11/09] amd64/88730 amd64 kernel panics during booting from the ins o [2006/01/02] amd64/91195 amd64 FreeBSD 6.0(amd64) and Asus A8R-MVP o [2006/01/09] amd64/91571 amd64 amd64 startup not initializing 32-bit lib o [2006/01/18] amd64/91966 amd64 an error in config of kernel o [2006/01/27] amd64/92412 amd64 rcp.rstatd reports bogus packets/per/seco o [2006/01/28] amd64/92463 amd64 Buttons of USB mouse do no work under KDE o [2006/01/30] amd64/92527 amd64 no driver for "CICADA VSC 8201 Gigabit LA 20 problems total. From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 30 14:36:53 2006 Return-Path: X-Original-To: amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B27E216A420; Mon, 30 Jan 2006 14:36:53 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECA7F43D4C; Mon, 30 Jan 2006 14:36:52 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id k0UEaofM023758; Mon, 30 Jan 2006 16:36:50 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ip.net.ua [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 31041-01-10; Mon, 30 Jan 2006 16:36:49 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id k0UEX2b5023522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jan 2006 16:33:02 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id k0UEX4ji073934; Mon, 30 Jan 2006 16:33:04 +0200 (EET) (envelope-from ru) Date: Mon, 30 Jan 2006 16:33:03 +0200 From: Ruslan Ermilov To: net@FreeBSD.org, amd64@FreeBSD.org Message-ID: <20060130143303.GA73838@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: Subject: mrouted on amd64 doesn't work X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2006 14:36:53 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi there, I cannot get multicast routing working on amd64, and I highly suspect mrouted(8). Can anybody confirm successfully or unsuccessfully running mrouted(8) on amd64 (5.x, 6.x or 7.0), or perhaps somebody already has patches for mrouted(8)? When I run mrouted in foreground, I get a lot of messages like this: 16:10:05.035 warning - received packet from 10.54.5.169 shorter (20 bytes) = than hdr+data length (20+80) 16:10:05.035 warning - received packet from 10.54.5.221 shorter (20 bytes) = than hdr+data length (20+76) 16:10:05.035 warning - received packet from 10.54.7.105 shorter (20 bytes) = than hdr+data length (20+73) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD3iOfqRfpzJluFF4RAk6vAJ44EzEK0Hh+ESDVHpqUjRJvLMpKzACbBBg6 woBps19U0otH54nqixWrHU4= =KSC5 -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 30 16:35:25 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E44016A420 for ; Mon, 30 Jan 2006 16:35:25 +0000 (GMT) (envelope-from ralf.folkerts@gmx.de) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id A7C5D43D5C for ; Mon, 30 Jan 2006 16:35:22 +0000 (GMT) (envelope-from ralf.folkerts@gmx.de) Received: (qmail invoked by alias); 30 Jan 2006 16:35:21 -0000 Received: from dslb-084-057-162-185.pools.arcor-ip.net (EHLO beaster) [84.57.162.185] by mail.gmx.net (mp031) with SMTP; 30 Jan 2006 17:35:21 +0100 X-Authenticated: #18511927 From: Ralf Folkerts To: freebsd-amd64@freebsd.org In-Reply-To: <20060129194358.34422cc5.torfinn.ingolfsen@broadpark.no> References: <1138555678.915.20.camel@beaster> <4cbd01f40601291019s3c0558cav@mail.gmail.com> <20060129194358.34422cc5.torfinn.ingolfsen@broadpark.no> Content-Type: text/plain Organization: Wohnzimmerrechenzentrum Date: Mon, 30 Jan 2006 17:35:20 +0100 Message-Id: <1138638920.891.11.camel@beaster> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: Installation of print/acroread7 fails on my amd64-System X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2006 16:35:25 -0000 Am Sonntag, den 29.01.2006, 19:43 +0100 schrieb Torfinn Ingolfsen: > On Mon, 30 Jan 2006 03:19:34 +0900 > Sangwoo Shim wrote: > > > I've also experienced this problem several months ago, and submitted > > PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/87985 > > ...Althogh it didn't get much attention from the maintainer. > > I can confirm that I also see this problem, and that manually installing > the linux-gtk2 port before installing acroread7 is a possible > workaround. > > HTH Hi Torfinn and Sangwoo, thanks for confirming this (so I know my System is not that mis-configured that that's the reason for not being able to install acroread7) and also many thanks for the hint to install linux-gtk2 on its own -- that worked fine and when it was installed I also was able to install acroread7 w/o any problem! Thanks again! _ralf_ From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 30 19:02:24 2006 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F7F016A420; Mon, 30 Jan 2006 19:02:24 +0000 (GMT) (envelope-from hostmaster@GTS.NET) Received: from fukspam.GTS.NET (mail.gts.t-fcn.net [204.138.66.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DF6843D66; Mon, 30 Jan 2006 19:02:18 +0000 (GMT) (envelope-from hostmaster@GTS.NET) Received: from localhost by fukspam.GTS.NET via sendmail with STDIO (/R:inet_hosts/T:inet_zone_smtp/dest:remote) id (3128 bytes from ident using UNIX) for ; Mon, 30 Jan 2006 14:02:15 -0500 (EST) (Smail-3.2.0.122-Pre 2005-Nov-17 #1; built 2006-Jan-22) Message-Id: From: hotlips Internet admin To: sean@mcneil.com (Sean McNeil) Date: Mon, 30 Jan 2006 14:02:14 -0500 (EST) In-Reply-To: <1138563761.33172.1.camel@triton.mcneil.com> from "Sean McNeil" at Jan 29, 2006 11:42:41 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: bug-followup@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2006 19:02:24 -0000 Thus saith Sean McNeil: | On Sun, 2006-01-29 at 07:30 +0000, hotlips Internet admin wrote: | > The following reply was made to PR amd64/92412; it has been noted by GNATS. | > | > From: hotlips Internet admin | > To: kris@obsecurity.org (Kris Kennaway) | > Cc: bug-followup@FreeBSD.org | > Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info | > Date: Sun, 29 Jan 2006 02:25:33 -0500 (EST) | > | > Thus saith Kris Kennaway: | > | On Fri, Jan 27, 2006 at 11:59:15AM -0500, hotlips Internet admin wrote: | > | | > | > | > >Description: | > | > | > packets/second value reported by rpc.rstatd to remote monitor hovers around | > | > | > 8000 or so with odd downward spikes approx every 90 seconds (it's not at | > | > | all related to actual interface traffic) | > | > | > | > | > | > >How-To-Repeat: | > | > | > keep displaying rpc.rstatd data from 6.0 system | > | > | | > | > | How are you using rpc.rstatd and rup? I don't see a way to make rup | > | > | display "packets/second", it only gives uptime and load average: | > | > | | > | > | # rup | > | > | fbsd-amd64.isc. 10:02am up 4 days, 14:00, load average: 2.00 2.00 2.00 | > | > | > | > Solaris perfmeter, actually. | > | | > | Do you know how I can query this on FreeBSD? | > | > | > oop, wrong (older) diff - use this one below... | | The diff would be more readable if you only include useful changes and | eliminate difference caused solely from white space. For instance, with | diff -ub. rup is also broken, sigh - patches below to account for 8-btye timevals -- Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@gts.net --------- 8< --------- 8< --------- 8< --------- 8< --------- 8< --------- --- rup.c.orig Sat May 21 05:55:07 2005 +++ rup.c Mon Jan 30 13:55:34 2006 @@ -93,6 +93,7 @@ static bool_t rstat_reply(caddr_t replyp, struct sockaddr_in *raddrp) { + long longtime; struct tm *tmp_time; struct tm host_time; struct tm host_uptime; @@ -118,12 +119,14 @@ printf("%-*s\t", HOST_WIDTH, host); - tmp_time = localtime((time_t *)&host_stat->curtime.tv_sec); + longtime = host_stat->curtime.tv_sec; + tmp_time = localtime((time_t *)&longtime); host_time = *tmp_time; host_stat->curtime.tv_sec -= host_stat->boottime.tv_sec; - tmp_time = gmtime((time_t *)&host_stat->curtime.tv_sec); + longtime = host_stat->curtime.tv_sec; + tmp_time = gmtime((time_t *)&longtime); host_uptime = *tmp_time; #define updays (host_stat->curtime.tv_sec / 86400) From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 30 19:07:54 2006 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9013C16A420; Mon, 30 Jan 2006 19:07:54 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3644143D48; Mon, 30 Jan 2006 19:07:53 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 9D202F2534; Mon, 30 Jan 2006 11:07:53 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (triton.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36887-07; Mon, 30 Jan 2006 11:07:53 -0800 (PST) Received: from [10.1.0.10] (mobile.mcneil.com [10.1.0.10]) by mail.mcneil.com (Postfix) with ESMTP id 41449F2422; Mon, 30 Jan 2006 11:07:53 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <383CC154-8322-4307-BA6D-67A0CEF358F4@mcneil.com> Content-Transfer-Encoding: 7bit From: Sean McNeil Date: Mon, 30 Jan 2006 11:07:55 -0800 To: hotlips Internet admin X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new at mcneil.com Cc: bug-followup@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2006 19:07:54 -0000 On Jan 30, 2006, at 11:02 AM, hotlips Internet admin wrote: > Thus saith Sean McNeil: > | On Sun, 2006-01-29 at 07:30 +0000, hotlips Internet admin wrote: > | > The following reply was made to PR amd64/92412; it has been > noted by GNATS. > | > > | > From: hotlips Internet admin > | > To: kris@obsecurity.org (Kris Kennaway) > | > Cc: bug-followup@FreeBSD.org > | > Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/ > second info > | > Date: Sun, 29 Jan 2006 02:25:33 -0500 (EST) > | > > | > Thus saith Kris Kennaway: > | > | On Fri, Jan 27, 2006 at 11:59:15AM -0500, hotlips Internet > admin wrote: > | > | > | > | > | > >Description: > | > | > | > packets/second value reported by rpc.rstatd to remote > monitor hovers around > | > | > | > 8000 or so with odd downward spikes approx every 90 > seconds (it's not at > | > | > | all related to actual interface traffic) > | > | > | > > | > | > | > >How-To-Repeat: > | > | > | > keep displaying rpc.rstatd data from 6.0 system > | > | > | > | > | > | How are you using rpc.rstatd and rup? I don't see a way > to make rup > | > | > | display "packets/second", it only gives uptime and load > average: > | > | > | > | > | > | # rup > | > | > | fbsd-amd64.isc. 10:02am up 4 days, 14:00, load > average: 2.00 2.00 2.00 > | > | > > | > | > Solaris perfmeter, actually. > | > | > | > | Do you know how I can query this on FreeBSD? > | > > | > > | > oop, wrong (older) diff - use this one below... > | > | The diff would be more readable if you only include useful > changes and > | eliminate difference caused solely from white space. For > instance, with > | diff -ub. > > > rup is also broken, sigh - patches below to account for > 8-btye timevals > > > -- > Bruce Becker +1 416 410 0879 > GTS Network Administration Toronto, Ont. > Email: hostmaster@gts.net > > --------- 8< --------- 8< --------- 8< --------- 8< --------- 8< > --------- > > --- rup.c.orig Sat May 21 05:55:07 2005 > +++ rup.c Mon Jan 30 13:55:34 2006 > @@ -93,6 +93,7 @@ > static bool_t > rstat_reply(caddr_t replyp, struct sockaddr_in *raddrp) > { > + long longtime; > struct tm *tmp_time; > struct tm host_time; > struct tm host_uptime; > @@ -118,12 +119,14 @@ > > printf("%-*s\t", HOST_WIDTH, host); > > - tmp_time = localtime((time_t *)&host_stat->curtime.tv_sec); > + longtime = host_stat->curtime.tv_sec; > + tmp_time = localtime((time_t *)&longtime); > host_time = *tmp_time; > Just curious, but why not declare a variable as time_t instead of long? Seems like that would be more correct. > host_stat->curtime.tv_sec -= host_stat->boottime.tv_sec; > > - tmp_time = gmtime((time_t *)&host_stat->curtime.tv_sec); > + longtime = host_stat->curtime.tv_sec; > + tmp_time = gmtime((time_t *)&longtime); > host_uptime = *tmp_time; > > #define updays (host_stat->curtime.tv_sec / 86400) > > From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 30 19:10:06 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE58916A420 for ; Mon, 30 Jan 2006 19:10:06 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C1C143D5A for ; Mon, 30 Jan 2006 19:10:06 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0UJA69k085690 for ; Mon, 30 Jan 2006 19:10:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0UJA5e6085689; Mon, 30 Jan 2006 19:10:06 GMT (envelope-from gnats) Date: Mon, 30 Jan 2006 19:10:06 GMT Message-Id: <200601301910.k0UJA5e6085689@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: hotlips Internet admin Cc: Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hotlips Internet admin List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2006 19:10:07 -0000 The following reply was made to PR amd64/92412; it has been noted by GNATS. From: hotlips Internet admin To: sean@mcneil.com (Sean McNeil) Cc: freebsd-amd64@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info Date: Mon, 30 Jan 2006 14:02:14 -0500 (EST) Thus saith Sean McNeil: | On Sun, 2006-01-29 at 07:30 +0000, hotlips Internet admin wrote: | > The following reply was made to PR amd64/92412; it has been noted by GNATS. | > | > From: hotlips Internet admin | > To: kris@obsecurity.org (Kris Kennaway) | > Cc: bug-followup@FreeBSD.org | > Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info | > Date: Sun, 29 Jan 2006 02:25:33 -0500 (EST) | > | > Thus saith Kris Kennaway: | > | On Fri, Jan 27, 2006 at 11:59:15AM -0500, hotlips Internet admin wrote: | > | | > | > | > >Description: | > | > | > packets/second value reported by rpc.rstatd to remote monitor hovers around | > | > | > 8000 or so with odd downward spikes approx every 90 seconds (it's not at | > | > | all related to actual interface traffic) | > | > | > | > | > | > >How-To-Repeat: | > | > | > keep displaying rpc.rstatd data from 6.0 system | > | > | | > | > | How are you using rpc.rstatd and rup? I don't see a way to make rup | > | > | display "packets/second", it only gives uptime and load average: | > | > | | > | > | # rup | > | > | fbsd-amd64.isc. 10:02am up 4 days, 14:00, load average: 2.00 2.00 2.00 | > | > | > | > Solaris perfmeter, actually. | > | | > | Do you know how I can query this on FreeBSD? | > | > | > oop, wrong (older) diff - use this one below... | | The diff would be more readable if you only include useful changes and | eliminate difference caused solely from white space. For instance, with | diff -ub. rup is also broken, sigh - patches below to account for 8-btye timevals -- Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@gts.net --------- 8< --------- 8< --------- 8< --------- 8< --------- 8< --------- --- rup.c.orig Sat May 21 05:55:07 2005 +++ rup.c Mon Jan 30 13:55:34 2006 @@ -93,6 +93,7 @@ static bool_t rstat_reply(caddr_t replyp, struct sockaddr_in *raddrp) { + long longtime; struct tm *tmp_time; struct tm host_time; struct tm host_uptime; @@ -118,12 +119,14 @@ printf("%-*s\t", HOST_WIDTH, host); - tmp_time = localtime((time_t *)&host_stat->curtime.tv_sec); + longtime = host_stat->curtime.tv_sec; + tmp_time = localtime((time_t *)&longtime); host_time = *tmp_time; host_stat->curtime.tv_sec -= host_stat->boottime.tv_sec; - tmp_time = gmtime((time_t *)&host_stat->curtime.tv_sec); + longtime = host_stat->curtime.tv_sec; + tmp_time = gmtime((time_t *)&longtime); host_uptime = *tmp_time; #define updays (host_stat->curtime.tv_sec / 86400) From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 30 19:10:09 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EE4A16A420 for ; Mon, 30 Jan 2006 19:10:09 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E5CA43D62 for ; Mon, 30 Jan 2006 19:10:09 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0UJA8Vc085697 for ; Mon, 30 Jan 2006 19:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0UJA8EF085696; Mon, 30 Jan 2006 19:10:08 GMT (envelope-from gnats) Date: Mon, 30 Jan 2006 19:10:08 GMT Message-Id: <200601301910.k0UJA8EF085696@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Sean McNeil Cc: Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sean McNeil List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2006 19:10:09 -0000 The following reply was made to PR amd64/92412; it has been noted by GNATS. From: Sean McNeil To: hotlips Internet admin Cc: freebsd-amd64@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info Date: Mon, 30 Jan 2006 11:07:55 -0800 On Jan 30, 2006, at 11:02 AM, hotlips Internet admin wrote: > Thus saith Sean McNeil: > | On Sun, 2006-01-29 at 07:30 +0000, hotlips Internet admin wrote: > | > The following reply was made to PR amd64/92412; it has been > noted by GNATS. > | > > | > From: hotlips Internet admin > | > To: kris@obsecurity.org (Kris Kennaway) > | > Cc: bug-followup@FreeBSD.org > | > Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/ > second info > | > Date: Sun, 29 Jan 2006 02:25:33 -0500 (EST) > | > > | > Thus saith Kris Kennaway: > | > | On Fri, Jan 27, 2006 at 11:59:15AM -0500, hotlips Internet > admin wrote: > | > | > | > | > | > >Description: > | > | > | > packets/second value reported by rpc.rstatd to remote > monitor hovers around > | > | > | > 8000 or so with odd downward spikes approx every 90 > seconds (it's not at > | > | > | all related to actual interface traffic) > | > | > | > > | > | > | > >How-To-Repeat: > | > | > | > keep displaying rpc.rstatd data from 6.0 system > | > | > | > | > | > | How are you using rpc.rstatd and rup? I don't see a way > to make rup > | > | > | display "packets/second", it only gives uptime and load > average: > | > | > | > | > | > | # rup > | > | > | fbsd-amd64.isc. 10:02am up 4 days, 14:00, load > average: 2.00 2.00 2.00 > | > | > > | > | > Solaris perfmeter, actually. > | > | > | > | Do you know how I can query this on FreeBSD? > | > > | > > | > oop, wrong (older) diff - use this one below... > | > | The diff would be more readable if you only include useful > changes and > | eliminate difference caused solely from white space. For > instance, with > | diff -ub. > > > rup is also broken, sigh - patches below to account for > 8-btye timevals > > > -- > Bruce Becker +1 416 410 0879 > GTS Network Administration Toronto, Ont. > Email: hostmaster@gts.net > > --------- 8< --------- 8< --------- 8< --------- 8< --------- 8< > --------- > > --- rup.c.orig Sat May 21 05:55:07 2005 > +++ rup.c Mon Jan 30 13:55:34 2006 > @@ -93,6 +93,7 @@ > static bool_t > rstat_reply(caddr_t replyp, struct sockaddr_in *raddrp) > { > + long longtime; > struct tm *tmp_time; > struct tm host_time; > struct tm host_uptime; > @@ -118,12 +119,14 @@ > > printf("%-*s\t", HOST_WIDTH, host); > > - tmp_time = localtime((time_t *)&host_stat->curtime.tv_sec); > + longtime = host_stat->curtime.tv_sec; > + tmp_time = localtime((time_t *)&longtime); > host_time = *tmp_time; > Just curious, but why not declare a variable as time_t instead of long? Seems like that would be more correct. > host_stat->curtime.tv_sec -= host_stat->boottime.tv_sec; > > - tmp_time = gmtime((time_t *)&host_stat->curtime.tv_sec); > + longtime = host_stat->curtime.tv_sec; > + tmp_time = gmtime((time_t *)&longtime); > host_uptime = *tmp_time; > > #define updays (host_stat->curtime.tv_sec / 86400) > > From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 30 19:30:10 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99B6116A422 for ; Mon, 30 Jan 2006 19:30:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78A9543D53 for ; Mon, 30 Jan 2006 19:30:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0UJU7Ru086384 for ; Mon, 30 Jan 2006 19:30:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0UJU7bR086383; Mon, 30 Jan 2006 19:30:07 GMT (envelope-from gnats) Date: Mon, 30 Jan 2006 19:30:07 GMT Message-Id: <200601301930.k0UJU7bR086383@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: hotlips Internet admin Cc: Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hotlips Internet admin List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2006 19:30:10 -0000 The following reply was made to PR amd64/92412; it has been noted by GNATS. From: hotlips Internet admin To: sean@mcneil.com (Sean McNeil) Cc: bug-followup@FreeBSD.org Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/second info Date: Mon, 30 Jan 2006 14:22:52 -0500 (EST) Thus saith Sean McNeil: | | | On Jan 30, 2006, at 11:02 AM, hotlips Internet admin wrote: | | > Thus saith Sean McNeil: | > | On Sun, 2006-01-29 at 07:30 +0000, hotlips Internet admin wrote: | > | > The following reply was made to PR amd64/92412; it has been | > noted by GNATS. | > | > | > | > From: hotlips Internet admin | > | > To: kris@obsecurity.org (Kris Kennaway) | > | > Cc: bug-followup@FreeBSD.org | > | > Subject: Re: amd64/92412: rcp.rstatd reports bogus packets/per/ | > second info | > | > Date: Sun, 29 Jan 2006 02:25:33 -0500 (EST) | > | > | > | > Thus saith Kris Kennaway: | > | > | On Fri, Jan 27, 2006 at 11:59:15AM -0500, hotlips Internet | > admin wrote: | > | > | | > | > | > | > >Description: | > | > | > | > packets/second value reported by rpc.rstatd to remote | > monitor hovers around | > | > | > | > 8000 or so with odd downward spikes approx every 90 | > seconds (it's not at | > | > | > | all related to actual interface traffic) | > | > | > | > | > | > | > | > >How-To-Repeat: | > | > | > | > keep displaying rpc.rstatd data from 6.0 system | > | > | > | | > | > | > | How are you using rpc.rstatd and rup? I don't see a way | > to make rup | > | > | > | display "packets/second", it only gives uptime and load | > average: | > | > | > | | > | > | > | # rup | > | > | > | fbsd-amd64.isc. 10:02am up 4 days, 14:00, load | > average: 2.00 2.00 2.00 | > | > | > | > | > | > Solaris perfmeter, actually. | > | > | | > | > | Do you know how I can query this on FreeBSD? | > | > | > | > | > | > oop, wrong (older) diff - use this one below... | > | | > | The diff would be more readable if you only include useful | > changes and | > | eliminate difference caused solely from white space. For | > instance, with | > | diff -ub. | > | > | > rup is also broken, sigh - patches below to account for | > 8-btye timevals | > | > | > -- | > Bruce Becker +1 416 410 0879 | > GTS Network Administration Toronto, Ont. | > Email: hostmaster@gts.net | > | > --------- 8< --------- 8< --------- 8< --------- 8< --------- 8< | > --------- | > | > --- rup.c.orig Sat May 21 05:55:07 2005 | > +++ rup.c Mon Jan 30 13:55:34 2006 | > @@ -93,6 +93,7 @@ | > static bool_t | > rstat_reply(caddr_t replyp, struct sockaddr_in *raddrp) | > { | > + long longtime; | > struct tm *tmp_time; | > struct tm host_time; | > struct tm host_uptime; | > @@ -118,12 +119,14 @@ | > | > printf("%-*s\t", HOST_WIDTH, host); | > | > - tmp_time = localtime((time_t *)&host_stat->curtime.tv_sec); | > + longtime = host_stat->curtime.tv_sec; | > + tmp_time = localtime((time_t *)&longtime); | > host_time = *tmp_time; | > | | | Just curious, but why not declare a variable as time_t instead of | long? Seems like that would be more correct. | | | > host_stat->curtime.tv_sec -= host_stat->boottime.tv_sec; | > | > - tmp_time = gmtime((time_t *)&host_stat->curtime.tv_sec); | > + longtime = host_stat->curtime.tv_sec; | > + tmp_time = gmtime((time_t *)&longtime); | > host_uptime = *tmp_time; | > | > #define updays (host_stat->curtime.tv_sec / 86400) it didn't seem to matter because of the "u_int tv_sec" declaration in rstat_timeval in /usr/include/rpcsvc/rstat.h, and the surrounding "(time_t *)&" - it should be as you suggest however in fact the problem mentioned seems to have been noticed recently and is fixed somewhat more cleanly in current ... Cheers, Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@gts.net From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 31 00:26:50 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 175A016A422 for ; Tue, 31 Jan 2006 00:26:50 +0000 (GMT) (envelope-from idleroux@MIT.EDU) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C7D543D53 for ; Tue, 31 Jan 2006 00:26:49 +0000 (GMT) (envelope-from idleroux@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id k0V0Qlip012922 for ; Mon, 30 Jan 2006 19:26:47 -0500 (EST) Received: from w92-130-webmail-6.mit.edu (W92-130-WEBMAIL-6.MIT.EDU [18.7.22.137]) ) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k0V0Qdk9020542 for ; Mon, 30 Jan 2006 19:26:40 -0500 (EST) Received: (from nobody@localhost) by w92-130-webmail-6.mit.edu (8.12.4) id k0V0Qduu004573; Mon, 30 Jan 2006 19:26:39 -0500 Received: from TANG-THIRTY-EIGHT.MIT.EDU (TANG-THIRTY-EIGHT.MIT.EDU [18.251.5.38]) (User authenticated as idleroux@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP for ; Mon, 30 Jan 2006 19:26:39 -0500 Message-ID: <20060130192639.in25nckcus80c8ww@webmail.mit.edu> Date: Mon, 30 Jan 2006 19:26:39 -0500 From: "Ian D. Leroux" To: freebsd-amd64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Motherboard and Video Card selection X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2006 00:26:50 -0000 Good (insert local time of day here), I'm currently putting together the parts list for my next desktop, and am planning to make it an athlon64 X2 (socket 939) system. My current computer has lasted me 5-6 years, and for 4 of those it ran FreeBSD. Consequently, I'm hoping to build something reasonably up-to-date (so it won't be obsolete too soon), but well-supported by FreeBSD (so I won't have to change my operating system). After perusing the motherboards list and googling about, it would seem that I have two options for FreeBSD-supported motherboard/graphics card combinations: 1- VIA K8T800 (e.g. Asus A8V): This seems to be mature and well-supported, but the combination of this chipset, (some) ATI Radeon cards, and SMP seems to cause problems, so I'd have to use an nVidia card. 2- NVIDIA nForce 4 (e.g. ASUS A8N5X): This is reported to be mostly-supported under 6.0, albeit using a binary driver for the network interface,and would (ironically) let me use an ATI video card. I'm not really satisfied with either option. I'm not a gamer, but I'd like my graphics card to at least work properly, including 3D, particularly since desktop software is reportedly moving towards the use of 3D extensions for rendering (e.g. cairo). For NVIDIA cards, this requires binary-only drivers that are currently unavailable for 64-bit FreeBSD. ATI cards up to the Radeon 9250 seem to have mature open-source drivers, and r300 series (Radeon 9550-9800 or so) have reverse-engineered drivers that are "almost there" (http://r300.sourceforge.net, they're also in ports somewhere), but as already mentioned they don't seem to work with the more stable and open-source friendly motherboards. Does anybody have any thoughts/comments/corrections/recommendations? Specifically: - Are there any radeon cards that have been known to work with dual-core athlons on k8t800-based boards? - Am I forgetting anybody? i.e. are any of the other motherboard chipsets (sis 965L, ati radeon crossfire) currently or soon-to-be supported? Ditto for video cards. - Are there any firms that FreeBSD developers have found particularly helpful (e.g. by releasing hardware specifications) and that I ought to support with my computer-buying funds? I don't much like NVIDIA's binary-drivers-only policy, but is anybody else out there any better? Again, the question applies to both motherboards and graphics cards. - Am I asking for the impossible? Should I just use an Intel CPU, another OS, or unsupported hardware for now and wait for the drivers to catch up? I don't think I have the skills or the time to contribute to driver development (though I'm tempted to try), so telling me to just make FreeBSD work on whatever I buy and contribute the changes back to the source tree wouldn't be terribly useful. Thank you very much for any and all comments, -- Ian Leroux From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 31 01:22:38 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD8EF16A420 for ; Tue, 31 Jan 2006 01:22:38 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64E2043D45 for ; Tue, 31 Jan 2006 01:22:38 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 3951EF80F for ; Mon, 30 Jan 2006 18:22:33 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id E15B6F805 for ; Mon, 30 Jan 2006 18:22:32 -0700 (MST) Date: Mon, 30 Jan 2006 18:22:31 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060130182231.27ab6e98.kgunders@teamcool.net> In-Reply-To: <20060130192639.in25nckcus80c8ww@webmail.mit.edu> References: <20060130192639.in25nckcus80c8ww@webmail.mit.edu> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Motherboard and Video Card selection X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2006 01:22:39 -0000 On Mon, 30 Jan 2006 19:26:39 -0500 "Ian D. Leroux" wrote: > Good (insert local time of day here), > > I'm currently putting together the parts list for my next desktop, and > am planning to make it an athlon64 X2 (socket 939) system. My current > computer has lasted me 5-6 years, and for 4 of those it ran FreeBSD. > Consequently, I'm hoping to build something reasonably up-to-date (so > it won't be obsolete too soon), but well-supported by FreeBSD (so I > won't have to change my operating system). After perusing the > motherboards list and googling about, it would seem that I have two > options for FreeBSD-supported motherboard/graphics card combinations: > I'm in pretty much the same boat... > 1- VIA K8T800 (e.g. Asus A8V): This seems to be mature and > well-supported, but the combination of this chipset, (some) ATI Radeon > cards, and SMP seems to cause problems, so I'd have to use an nVidia > card. > > 2- NVIDIA nForce 4 (e.g. ASUS A8N5X): This is reported to be > mostly-supported under 6.0, albeit using a binary driver for the > network interface,and would (ironically) let me use an ATI video card. > I opted for a Tyan K8E board: Need to update to latest BIOS revision but otherwise seems to work pretty well. Too new to report in detail as I've not really done much on it yet (too darned busy with work...). Get the version w/dual nics if you want to use the onboard. Else just add your own ethernet controller. The Marvell is what you get w/ the single nic version doesn't work. (Well, maybe in CURRENT?). Sun has been basing some impressive 1U offerings on this board that have been getting notice lately. I've got mine paired with an Opteron 180. 've not done any benchmarking but can subjectively report that "it's just wickedly fast". > I'm not really satisfied with either option. I'm not a gamer, but I'd > like my graphics card to at least work properly, including 3D, > particularly since desktop software is reportedly moving towards the > use of 3D extensions for rendering (e.g. cairo). For NVIDIA cards, > this requires binary-only drivers that are currently unavailable for > 64-bit FreeBSD. ATI cards up to the Radeon 9250 seem to have mature > open-source drivers, and r300 series (Radeon 9550-9800 or so) have > reverse-engineered drivers that are "almost there" > (http://r300.sourceforge.net, they're also in ports somewhere), but as > already mentioned they don't seem to work with the more stable and > open-source friendly motherboards. > > Does anybody have any thoughts/comments/corrections/recommendations? > > Specifically: > - Are there any radeon cards that have been known to work with dual-core > athlons on k8t800-based boards? > > - Am I forgetting anybody? i.e. are any of the other motherboard > chipsets (sis 965L, ati radeon crossfire) currently or soon-to-be > supported? Ditto for video cards. > > - Are there any firms that FreeBSD developers have found particularly > helpful (e.g. by releasing hardware specifications) and that I ought to > support with my computer-buying funds? I don't much like NVIDIA's > binary-drivers-only policy, but is anybody else out there any better? > Again, the question applies to both motherboards and graphics cards. > I try to stay away from NVidia to the extent possible for these reasons but you can't really get around it sometimes. fwiw- I used an ATI based AsusTEK EAX300. Version I got comes w/the passive heat sink so I don't have to endure the added noise of a whinny little fan that is just gonna fail every 6 mo's.anyhow... Reasonably priced around $50 w/128MB. Gonna just have to suffer through the wait for 3D until xorg drivers have the chance to play catch up... ATI (Ithink) offers the option of an NDA to certain OSS developers so there's hope at least... Otherwise it seems you're limited to an AGP based mainboard so you can use an "older" GPU's (consequently seemingly limiting you into "older" mainboards). Something I wouldn't have minded at all but I'd heard good things about the Tyan K8E board. Earlier I'd built an Athalon system for someone else based on via K8T890. I only played w/ it for a very limited time before they installed Winblows but it just felt kind of slow to me. > - Am I asking for the impossible? Should I just use an Intel CPU, > another OS, or unsupported hardware for now and wait for the drivers to > catch up? I don't think I have the skills or the time to contribute to > driver development (though I'm tempted to try), so telling me to just > make FreeBSD work on whatever I buy and contribute the changes back to > the source tree wouldn't be terribly useful. > I think you can always opt for the i386 version of FBSD. Might even be preferred for workstation useage. I'm still vacillating. Might want to check the thread on this I started a few days back entitled "fbsd amd-64 desktop". > Thank you very much for any and all comments, np;-) take them w/a grain of salt. lot's of others here more in the know than I w.r.t. fbsd-amd64. just sharing my $0.02 fwiw... -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 31 16:33:07 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D74516A422; Tue, 31 Jan 2006 16:33:07 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0924B43D45; Tue, 31 Jan 2006 16:33:07 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from freefall.freebsd.org (trhodes@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0VGX6HP068757; Tue, 31 Jan 2006 16:33:06 GMT (envelope-from trhodes@freefall.freebsd.org) Received: (from trhodes@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0VGX6Vw068753; Tue, 31 Jan 2006 16:33:06 GMT (envelope-from trhodes) Date: Tue, 31 Jan 2006 16:33:06 GMT From: Tom Rhodes Message-Id: <200601311633.k0VGX6Vw068753@freefall.freebsd.org> To: hostmaster@whois.gts.net, trhodes@FreeBSD.org, freebsd-amd64@FreeBSD.org Cc: Subject: Re: amd64/92410: calloc.c missing from Makefile.inc X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2006 16:33:07 -0000 Synopsis: calloc.c missing from Makefile.inc State-Changed-From-To: open->closed State-Changed-By: trhodes State-Changed-When: Tue Jan 31 16:32:47 UTC 2006 State-Changed-Why: Fixed mismerge, thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=92410 From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 1 13:40:02 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04EA716A420 for ; Wed, 1 Feb 2006 13:40:02 +0000 (GMT) (envelope-from idleroux@MIT.EDU) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5010343D4C for ; Wed, 1 Feb 2006 13:40:01 +0000 (GMT) (envelope-from idleroux@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id k11DdxOK021712 for ; Wed, 1 Feb 2006 08:39:59 -0500 (EST) Received: from w92-130-webmail-4.mit.edu (W92-130-WEBMAIL-4.MIT.EDU [18.7.22.135]) ) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k11DdvOw001497 for ; Wed, 1 Feb 2006 08:39:57 -0500 (EST) Received: (from nobody@localhost) by w92-130-webmail-4.mit.edu (8.12.4) id k11DdvNl024893; Wed, 1 Feb 2006 08:39:57 -0500 Received: from RLE-12-014.MIT.EDU (RLE-12-014.MIT.EDU [18.62.12.14]) (User authenticated as idleroux@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP for ; Wed, 1 Feb 2006 08:39:57 -0500 Message-ID: <20060201083957.17f7t5je0agwg8s4@webmail.mit.edu> Date: Wed, 1 Feb 2006 08:39:57 -0500 From: "Ian D. Leroux" To: freebsd-amd64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Motherboard and Video Card selection X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 13:40:02 -0000 Apologies for the threading errors, I'm stuck on webmail until I get a new machine and can't set the Reply-To headers right. > I opted for a Tyan K8E board: > [...] > Sun has been basing some impressive 1U offerings on this board that > have been getting notice lately. I've got mine paired with an Opteron > 180. 've not done any benchmarking but can subjectively report that > "it's just wickedly fast". Any particular reason you went for a socket-939 opteron rather than the equivalent Athlon64 X2? Nothing wrong with that, I'm just wondering if you know something I don't. > [...] > > I don't much like NVIDIA's binary-drivers-only policy, but is > > anybody else out there any better? > I try to stay away from NVidia to the extent possible for these > reasons but you can't really get around it sometimes. fwiw- I > used an ATI based AsusTEK EAX300. Version I got comes w/the > passive heat sink so I don't have to endure the added noise of a > whinny little fan that is just gonna fail every 6 mo's.anyhow... Yes, I should have mentioned that passive cooling was something I wanted too. > Reasonably priced around $50 w/128MB. Gonna just have to suffer > through the wait for 3D until xorg drivers have the chance to play > catch up... ATI (Ithink) offers the option of an NDA to certain OSS > developers so there's hope at least... Sadly, it looks like the ATI NDA program stops with the Radeon 9250 chips . All support for later ATI cards (that I know of) is reverse-engineered. Not that I mind getting an older Radeon, provided I can be reasonably confident of it working with the mainboard. > I think you can always opt for the i386 version of FBSD. Might even > be preferred for workstation useage. A good point, and one that I'd neglected. Thanks for the input. It sounds like an nForce4 mainboard is the way to go, if only because their ubiquity guarantees some kind of support. As for a video card, I'll get an old one if I can, or else get a modern one and wait for nvidia to release 64-bit drivers or for X.org to finish reverse-engineering the ATI cards. Hobson's Choice. Here's to open-spec hardware, and a prayer for its return someday. -- Thanks again for your time, Ian Leroux From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 1 15:53:13 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4345016A420 for ; Wed, 1 Feb 2006 15:53:13 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FCEC43D5A for ; Wed, 1 Feb 2006 15:53:11 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k11FrBoZ061405 for ; Wed, 1 Feb 2006 13:53:11 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR To: freebsd-amd64@freebsd.org Date: Wed, 1 Feb 2006 13:53:02 -0200 User-Agent: KMail/1.9.1 References: <20060201083957.17f7t5je0agwg8s4@webmail.mit.edu> In-Reply-To: <20060201083957.17f7t5je0agwg8s4@webmail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200602011353.02860.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: Motherboard and Video Card selection X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 15:53:13 -0000 On Wednesday 01 February 2006 11:39, Ian D. Leroux wrote: > > > > I try to stay away from NVidia to the extent possible for these > > reasons but you can't really get around it sometimes. fwiw- I > > used an ATI based AsusTEK EAX300. Version I got comes w/the > > passive heat sink so I don't have to endure the added noise of a > > whinny little fan that is just gonna fail every 6 mo's.anyhow... > > Yes, I should have mentioned that passive cooling was something I wanted > too. > Hi I believe passing cooling is a technology which stears down cpufrequency=20 instead raising cooling fan rotation and that has nothing to do with a=20 passive heat sink. Particulary this seems to work very well on amd64 with=20 athlon64 including X2 ones. Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 1 18:28:31 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7980416A422 for ; Wed, 1 Feb 2006 18:28:31 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFBE243D48 for ; Wed, 1 Feb 2006 18:28:30 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 83C77F824 for ; Wed, 1 Feb 2006 11:28:25 -0700 (MST) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 47A8EF81E for ; Wed, 1 Feb 2006 11:28:25 -0700 (MST) Date: Wed, 1 Feb 2006 11:28:24 -0700 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20060201112824.233c3d22.kgunders@teamcool.net> In-Reply-To: <20060201083957.17f7t5je0agwg8s4@webmail.mit.edu> References: <20060201083957.17f7t5je0agwg8s4@webmail.mit.edu> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Motherboard and Video Card selection X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 18:28:31 -0000 On Wed, 1 Feb 2006 08:39:57 -0500 "Ian D. Leroux" wrote: > Apologies for the threading errors, I'm stuck on webmail until I get a > new machine and can't set the Reply-To headers right. > > > I opted for a Tyan K8E board: > > [...] > > Sun has been basing some impressive 1U offerings on this board that > > have been getting notice lately. I've got mine paired with an Opteron > > 180. 've not done any benchmarking but can subjectively report that > > "it's just wickedly fast". > > Any particular reason you went for a socket-939 opteron rather than the > equivalent Athlon64 X2? Nothing wrong with that, I'm just wondering if > you know something I don't. > Well, it seems to be debatable on fbsd-amd64 but I read some posts on amd forums indicating that the Opterons were subjected to more stringent QA than their Athalon brethern. Per AMD's marketroid info (for whatever it might be worth...): * AMD Opteron 100 Series processors with ECC unbuffered memory all have 1MB of L2 cache. * AMD Opteron 100 Series processors with ECC unbuffered memory are produced on AMD Opteron processor die material and follow the same AMD Opteron processor manufacturing process as do the 800 Series and 200 Series. * AMD Opteron 100 Series processors with ECC unbuffered memory undergo the same AMD Opteron processor-level testing and validation as do the 800 Series and 200 Series. At the time the price diff was negligible so nugded me towards the Opteron. Granted some of the higher Athalons also do have 128K L1 and 1MB L2 per core as well. Whether these units are otherwise the same as their Opteron counterparts, as some assert, I can neither confirm nor deny. You may well be better off w/Athalon. Get a much wider selection of mainboard offerings and they'll tend to be a bit cheaper as well. The Tyan K8E is also in a couple of my recent servers, however, so having a workstation based on it is one less thing I have to track for BIOS updates, etc. > > [...] > > > I don't much like NVIDIA's binary-drivers-only policy, but is [snip] > Sadly, it looks like the ATI NDA program stops with the Radeon 9250 > chips . All support for later ATI > cards (that I know of) is reverse-engineered. Not that I mind getting > an older Radeon, provided I can be reasonably confident of it working > with the mainboard. > Ah yes, I'd forgotten about the NDA limits. Hate it when that happens... But I think bottom line is that ATI still has better reputation for playing a bit more nicely with OS developers than NVidia. > > I think you can always opt for the i386 version of FBSD. Might even > > be preferred for workstation useage. > > A good point, and one that I'd neglected. > > Thanks for the input. It sounds like an nForce4 mainboard is the way to > go, if only because their ubiquity guarantees some kind of support. As > for a video card, I'll get an old one if I can, or else get a modern > one and wait for nvidia to release 64-bit drivers or for X.org to > finish reverse-engineering the ATI cards. Hobson's Choice. Here's to > open-spec hardware, and a prayer for its return someday. An older, well supported PCI gpu may be the best fallback option for 3D at the moment. Myself, I can live w/o 3D... ATI does provide AMD64 linux drivers for their recent PCI-E cards. Don't have any clue about using them under FBSD AMD64. Maybe someone else can provide more enlightenment... -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 1 21:22:37 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4FFA16A420 for ; Wed, 1 Feb 2006 21:22:37 +0000 (GMT) (envelope-from apelisse@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id F398143D4C for ; Wed, 1 Feb 2006 21:22:36 +0000 (GMT) (envelope-from apelisse@gmail.com) Received: by uproxy.gmail.com with SMTP id h2so1315ugf for ; Wed, 01 Feb 2006 13:22:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=kBEmCxjeRBCZZokgrU0Ch1aQKISB8A4Ni4d9oWM7xCsPTanT29exJqW9zzf//9iVnm8L6DEL8BBEqcKX0h7cM2cGMW35MFTif5+xML7MQDK8VPJ7Qt2pjw4ouuaZVOU1rhB9yGOzL1uQWkhOxWCFm24lbCkhFm3+VZdv6EetJOM= Received: by 10.48.237.2 with SMTP id k2mr1579000nfh; Wed, 01 Feb 2006 13:22:35 -0800 (PST) Received: by 10.49.5.17 with HTTP; Wed, 1 Feb 2006 13:22:35 -0800 (PST) Message-ID: <61c746830602011322x13bfe7ddwfb81ba0eaf358658@mail.gmail.com> Date: Wed, 1 Feb 2006 22:22:35 +0100 From: Antoine Pelisse To: Coleman Kane In-Reply-To: <346a80220601281153y5f3c201ex8049a544a4f1ccea@mail.gmail.com> MIME-Version: 1.0 References: <43D9A099.8060909@samsco.org> <20060127043323.GA31513@xor.obsecurity.org> <61c746830601270414w44e868b9q77dd50565bc448b6@mail.gmail.com> <346a80220601281153y5f3c201ex8049a544a4f1ccea@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-amd64@freebsd.org, Kris Kennaway Subject: Re: 32-bit X libs? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 21:22:37 -0000 On 1/28/06, Coleman Kane wrote: > > What about this... > > Install 32-bit FreeBSD into ia32. and then make another ports dir there. > Then run against the 32-bit make binary that would be in there somewhere? > You could have all of the /*/(lib,bin,sbin,libexec)32 dirs as symlinks in= to > this compat section, making it easy to remove and replace your 32-bit > userland should it be necessary. > > I know on that Mac OS X, the solution is to make every dynamic binary hav= e > ppc,ppc64, and x86 sections in it (effectively 3 binaries archived in one > file) using Mach-O binaries. Dunno if this type of thing is possible, or > even desireable under ELF (or just for the FreeBSD community in general). > > It would be really cool to have the 32-bit userland (on amd64) be able to > install ports easily on the system choosing either 32 or 64 with a make > option. > > -- > coleman kane > That sounds nice, but I can't take care of it as I, ironically, have no working amd64 box. It would be great if someone else could take care of tha= t Regards, Antoine From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 1 23:56:00 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D21B16A420; Wed, 1 Feb 2006 23:56:00 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0935D43D58; Wed, 1 Feb 2006 23:55:57 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id k11NtuTL000868; Wed, 1 Feb 2006 15:55:56 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id k11Ntupg000867; Wed, 1 Feb 2006 15:55:56 -0800 (PST) (envelope-from sgk) Date: Wed, 1 Feb 2006 15:55:56 -0800 From: Steve Kargl To: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Message-ID: <20060201235556.GA708@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: HEADSUP: New pts code triggers panics on amd64 systems. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 23:56:00 -0000 After a binary search, I have determined that the new pts code is triggering kernel panics on an AMD64 system. Using this supfile file, I retrieve the src/sys *default host=cvsup10.freebsd.org *default base=/usr *default release=cvs tag=. *default delete use-rel-suffix *default prefix=/usr #*default date=2006.01.26.01.30.00 <-- Good working kernel *default date=2006.01.26.01.31.00 <-- kernel dies within 5 to 10 minutes. src-sys The difference in the src/sys between the above time stamps are Updating collection src-sys/cvs Edit src/sys/conf/files Checkout src/sys/kern/tty_pts.c Edit src/sys/kern/tty_pty.c Edit src/sys/sys/ttycom.h My kernel is UP on a dual processor Tyan K8S Pro motherboard with 12 GB of memory. I have no loaded modules. I have neither MEMGUARD or REDZONES compiled into the kernel. Attempts to use MEMGUARD results in a kernel that does not even make to single user mode. With vm.old_contigmalloc=1 Memory modified after free 0xfffffff024e38f200(504) val = deadc0dd @ 0xfffffff024e38f2d0 panic: Most recently used by DEVFS1 KDB: stack backtrace: panic() at panic+0x1c1 mtrash_ctor() at mtrash_ctor+0x78 uma_zalloc_arg() at uma_zalloc_arg+0x306 malloc() at malloc+0x3a fdinit() at fdinit+0x24 fdcopy() at fdcopy+0x24 fork1() at fork1+0x6df vfork() at vfork+0x1c syscall() at syscall+0x517 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (66, FreeBSD ELF64, vfork) rip = 0x2006a5b4d, rsp=0xfffffffda50, rbp = 0 --- With vm.old_contigmalloc=0 Memory modified after free (sorry forgot to write this down) panic: Most recently used by DEVFS1 KDB: stack backtrace: panic() at panic+0x1c1 mtrash_ctor() at mtrash_ctor+0x78 uma_zalloc_arg() at uma_zalloc_arg+0x306 malloc() at malloc+0x3a devfs_alloc() at devfs_alloc+0x1a make_dev_credv() at make_dev_credv+0x4b make_dev_cred() at make_dev_cred+0x8e ptcopen() at ptcopen+0x111 giant_open() at giant_open+0x5f devfs_open() at devfs_open+0x23b VOP_OPEN_APV() at VOP_OPEN_APV+0x74 vn_open_cred() at vn_open_cred+0x38c kern_open() at kern_open+0xfd open() at open+0x25 syscall() at syscall+0x517 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (5, FreeBSD ELF64, open) rip = 0x200aeebcc, rsp=0xfffffff2e58, rbp = 0xffffffff --- Script started on Wed Feb 1 15:32:43 2006 troutmask:root[201] kgdb /boot/kernel/kernel vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: Memory modified after free 0xffffff0254d62600(504) val=deadc0dd @ 0xffffff0254d626d0 panic: Most recently used by DEVFS1 KDB: stack backtrace: panic() at panic+0x1c1 mtrash_ctor() at mtrash_ctor+0x78 uma_zalloc_arg() at uma_zalloc_arg+0x306 malloc() at malloc+0xa3 devfs_alloc() at devfs_alloc+0x1a make_dev_credv() at make_dev_credv+0x4b make_dev_cred() at make_dev_cred+0x8e ptcopen() at ptcopen+0x111 giant_open() at giant_open+0x5f devfs_open() at devfs_open+0x23b VOP_OPEN_APV() at VOP_OPEN_APV+0x74 vn_open_cred() at vn_open_cred+0x38c kern_open() at kern_open+0xfd open() at open+0x25 syscall() at syscall+0x517 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (5, FreeBSD ELF64, open), rip = 0x200aeebcc, rsp = 0x7fffffff2e58, rbp = 0xffffffff --- KDB: enter: panic Uptime: 6m10s Dumping 12223 MB (3 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 4031MB (1031920 pages) ... ok chunk 2: 8192MB (2097152 pages) #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:172 #1 0xffffffff8027f809 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff8027f2da in panic ( fmt=0xffffffff80476e34 "Most recently used by %s\n") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xffffffff803b9ad8 in mtrash_ctor (mem=0x0, size=0, arg=0x0, flags=0) at /usr/src/sys/vm/uma_dbg.c:137 #4 0xffffffff803b8046 in uma_zalloc_arg (zone=0xffffff02fffeae40, udata=0x0, flags=1282) at /usr/src/sys/vm/uma_core.c:1846 #5 0xffffffff80273d93 in malloc (size=15, mtp=0xffffffff805aac60, flags=1282) at uma.h:275 #6 0xffffffff80228dca in devfs_alloc () at /usr/src/sys/fs/devfs/devfs_devs.c:121 #7 0xffffffff80254d1b in make_dev_credv (devsw=0xffffffff805c0e40, minornr=0, cr=0xffffff0250378380, uid=0, gid=0, mode=438, fmt=0xffffffff80462900 "tty%c%r", ap=0xffffffffbd5e2530) at /usr/src/sys/kern/kern_conf.c:523 #8 0xffffffff80254ebe in make_dev_cred (devsw=0x0, minornr=0, cr=0x0, uid=0, gid=0, mode=0, fmt=0x0) at /usr/src/sys/kern/kern_conf.c:581 #9 0xffffffff802c0ce1 in ptcopen (dev=0x0, flag=0, devtype=0, td=0xffffff0250378380) at /usr/src/sys/kern/tty_pty.c:163 #10 0xffffffff80253caf in giant_open (dev=0xffffff024d8fc400, oflags=32771, devtype=8192, td=0xffffff024fcc5000) at /usr/src/sys/kern/kern_conf.c:242 #11 0xffffffff8022bcdb in devfs_open (ap=0xffffffffbd5e2770) at /usr/src/sys/fs/devfs/devfs_vnops.c:680 #12 0xffffffff8042b3f4 in VOP_OPEN_APV (vop=0x0, a=0xffffffffbd5e2770) at vnode_if.c:365 #13 0xffffffff802f855c in vn_open_cred (ndp=0xffffffffbd5e2990, flagp=0xffffffffbd5e28dc, cmode=8, cred=0xffffff0250378380, fdidx=6) at vnode_if.h:198 #14 0xffffffff802ee83d in kern_open (td=0xffffff024fcc5000, path=0x519fab
, pathseg=UIO_USERSPACE, flags=32771, mode=-1117902448) at /usr/src/sys/kern/vfs_syscalls.c:977 #15 0xffffffff802eef35 in open (td=0x0, uap=0xffffffffbd5e2c00) at /usr/src/sys/kern/vfs_syscalls.c:943 #16 0xffffffff803ea0e7 in syscall (frame= {tf_rdi = 5349291, tf_rsi = 32770, tf_rdx = 10, tf_rcx = 8601451180, tf_r8 = -2142762872, tf_r9 = 140737488301656, tf_rax = 5, tf_rbx = 0, tf_rbp = 4294967295, tf_r10 = 1, tf_r11 = 514, tf_r12 = 6, tf_r13 = 5349291, tf_r14 = 5349280, tf_r15 = 1, tf_trapno = 22, tf_addr = 0, tf_flags = 0, tf_err = 2, tf_rip = 8601398220, tf_cs = 43, tf_rflags = 582, tf_rsp = 140737488301656, tf_ss = 35}) at /usr/src/sys/amd64/amd64/trap.c:821 #17 0xffffffff803d8048 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:270 #18 0x0000000200aeebcc in ?? () -- Steve From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 2 04:02:53 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAB2E16A420 for ; Thu, 2 Feb 2006 04:02:53 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from omta03sl.mx.bigpond.com (omta03sl.mx.bigpond.com [144.140.92.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F87643D48 for ; Thu, 2 Feb 2006 04:02:50 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from areilly.bpc-users.org ([141.168.4.160]) by omta03sl.mx.bigpond.com with ESMTP id <20060202040248.BLPR1358.omta03sl.mx.bigpond.com@areilly.bpc-users.org> for ; Thu, 2 Feb 2006 04:02:48 +0000 Received: (qmail 20502 invoked by uid 501); 2 Feb 2006 04:02:53 -0000 Date: Thu, 2 Feb 2006 15:02:53 +1100 From: Andrew Reilly To: freebsd-amd64@freebsd.org Message-ID: <20060202040253.GA20444@gurney.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Driver failed to allocate 49152 bytes of DMA buffer? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 04:02:54 -0000 Hi there, Still with the teething problems on my new AMD Athlon-X2 system: I've been a happy user of an M-Audio Delta 1010 sound card for several years. This card isn't supported by FreeBSD's drivers (no doubt because device information is not available without NDA), but I've been happily using 4front-technologies OSS driver for FreeBSD. That was on my old single-processor Pentium-III system, under FreeBSD 4, 5 and 6. 4Front have a driver available for FreeBSD 6.0-RELEASE-amd64, which should do the job, but it won't start properly, giving the following boot-time error messages: Feb 1 15:52:00 duncan kernel: OSS: Unable to allocate 49152 bytes for a DMA buffer Feb 1 15:52:00 duncan kernel: run soundoff and run soundon again. Feb 1 15:52:00 duncan kernel: Envy24: Failed to allocate 49152 bytes of DMA buffer Feb 1 15:52:00 duncan kernel: oss: Probing the hardware for IC Ensemble ENVY24 failed. I've been starting it from /etc/rc.local, which always seemed to be the right spot, but even so, the log file shows 11 seconds of uptime before "soundon" gets run. This machine has 1G of memory, and seems to behave the same way irrespective of whether I boot with the second processor enabled or not. uname -a says: FreeBSD duncan.reilly.home 6.0-STABLE FreeBSD 6.0-STABLE #3: Wed Feb 1 15:38:17 EST 2006 root@duncan.reilly.home:/usr/obj/usr/src/sys/SMP amd64 What are the chances that there has been a regression of some sort in this area since 6.0-RELEASE (which didn't boot on the board because of ACPI issues that have since been fixed)? Is there any kernel memory debugging information that I can investigate, to see why such a (seemingly) small amount of memory can't be allocated? Cheers, -- Andrew From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 2 04:33:47 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3E2416A420 for ; Thu, 2 Feb 2006 04:33:46 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by mx1.FreeBSD.org (Postfix) with SMTP id 660AF43D46 for ; Thu, 2 Feb 2006 04:33:46 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 63900 invoked from network); 2 Feb 2006 04:33:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=4D4cQm1iuqpx+cZ+9lOZgCnfxrqBhapSATCPJrs5X/aiv44Svj5cvN32Qak23twvJgiEpP/HGTGlC829HjlKjMqz4Lc+bGOUZowQUrD0NXn2BjcrFvqdZqNRgGb/+xrozduZxr8NT24wfjoR8iIAhbddfKS9aJdN++C7+JAglNk= ; Received: from unknown (HELO ?70.30.133.184?) (mikej@rogers.com@70.30.133.184 with plain) by smtp102.rog.mail.re2.yahoo.com with SMTP; 2 Feb 2006 04:33:45 -0000 Message-ID: <43E18BE6.4010502@rogers.com> Date: Wed, 01 Feb 2006 23:34:46 -0500 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Reilly References: <20060202040253.GA20444@gurney.reilly.home> In-Reply-To: <20060202040253.GA20444@gurney.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: Driver failed to allocate 49152 bytes of DMA buffer? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 04:33:47 -0000 Andrew Reilly wrote: > What are the chances that there has been a regression of some > sort in this area since 6.0-RELEASE (which didn't boot on the > board because of ACPI issues that have since been fixed)? > /usr/src/UPDATING: 20051230: A lot of fixes and new features in the soundsystem. To get all benefits, you may want to recompile mplayer (if installed) after booting the new world. Always read this file before updating. From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 2 05:02:26 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F18216A420 for ; Thu, 2 Feb 2006 05:02:26 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from omta02sl.mx.bigpond.com (omta02sl.mx.bigpond.com [144.140.93.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F49D43D48 for ; Thu, 2 Feb 2006 05:02:25 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from areilly.bpc-users.org ([141.168.4.160]) by omta02sl.mx.bigpond.com with ESMTP id <20060202050223.XLED18661.omta02sl.mx.bigpond.com@areilly.bpc-users.org> for ; Thu, 2 Feb 2006 05:02:23 +0000 Received: (qmail 21184 invoked by uid 501); 2 Feb 2006 05:02:24 -0000 Date: Thu, 2 Feb 2006 16:02:24 +1100 From: Andrew Reilly To: Mike Jakubik Message-ID: <20060202050223.GA21154@gurney.reilly.home> References: <20060202040253.GA20444@gurney.reilly.home> <43E18BE6.4010502@rogers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43E18BE6.4010502@rogers.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: Driver failed to allocate 49152 bytes of DMA buffer? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 05:02:26 -0000 On Wed, Feb 01, 2006 at 11:34:46PM -0500, Mike Jakubik wrote: > Andrew Reilly wrote: > >What are the chances that there has been a regression of some > >sort in this area since 6.0-RELEASE (which didn't boot on the > >board because of ACPI issues that have since been fixed)? > > > > /usr/src/UPDATING: > > 20051230: > A lot of fixes and new features in the soundsystem. To get all > benefits, you may want to recompile mplayer (if installed) after > booting the new world. > > > Always read this file before updating. I'm afraid that I don't understand how this relates to my question. Could you clarify, please? I'm not trying to use the native sound drivers (they still don't support my envy24-based card), but rather the third-party, closed-source driver from www.4front-tech.com. That UPDATING comment reads to me to refer to an ioctl API change that affects user-land programs. I already have to deal with that anyway, because the FreeBSD native sound drivers, and their APIs have diverged somewhat from the original OSS (which is more or less what the 4front driver supports). Cheers, -- Andrew From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 2 05:24:58 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7295C16A420 for ; Thu, 2 Feb 2006 05:24:58 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by mx1.FreeBSD.org (Postfix) with SMTP id C8A9A43D4C for ; Thu, 2 Feb 2006 05:24:57 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 33453 invoked from network); 2 Feb 2006 05:24:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FQrPguhAjEqG3+UEfbecWTLoB/YWtlgHYJtdCvpxF7rAlEJS0HwkqgeQmYKULCzpbT2tMIjPhI9PRj5wfJP1ruXyl3+/H3gKGsoHTBEi774HHjg1GsYqfxQ9hY1OVzVz+SgHh62djnaXiGaq1moPypeAU8sPUQzFVHzfixpe9s0= ; Received: from unknown (HELO ?70.30.133.184?) (mikej@rogers.com@70.30.133.184 with plain) by smtp101.rog.mail.re2.yahoo.com with SMTP; 2 Feb 2006 05:24:57 -0000 Message-ID: <43E197E6.4030302@rogers.com> Date: Thu, 02 Feb 2006 00:25:58 -0500 From: Mike Jakubik User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Reilly References: <20060202040253.GA20444@gurney.reilly.home> <43E18BE6.4010502@rogers.com> <20060202050223.GA21154@gurney.reilly.home> In-Reply-To: <20060202050223.GA21154@gurney.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: Driver failed to allocate 49152 bytes of DMA buffer? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 05:24:58 -0000 Andrew Reilly wrote: > On Wed, Feb 01, 2006 at 11:34:46PM -0500, Mike Jakubik wrote: > >> Andrew Reilly wrote: >> >>> What are the chances that there has been a regression of some >>> sort in this area since 6.0-RELEASE (which didn't boot on the >>> board because of ACPI issues that have since been fixed)? >>> >>> >> /usr/src/UPDATING: >> >> 20051230: >> A lot of fixes and new features in the soundsystem. To get all >> benefits, you may want to recompile mplayer (if installed) after >> booting the new world. >> >> >> Always read this file before updating. >> > > I'm afraid that I don't understand how this relates to my question. > Could you clarify, please? I'm not trying to use the native sound > drivers (they still don't support my envy24-based card), but rather > the third-party, closed-source driver from www.4front-tech.com. > > That UPDATING comment reads to me to refer to an ioctl API change > that affects user-land programs. I already have to deal with that > anyway, because the FreeBSD native sound drivers, and their APIs > have diverged somewhat from the original OSS (which is more or less > what the 4front driver supports). > I'm just saying that this may be the cause, since thats the only thing sound related thats changed since -RELEASE. Have you brought up the issue with 4front? From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 2 09:33:39 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D72316A420; Thu, 2 Feb 2006 09:33:39 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.178.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98E7943D45; Thu, 2 Feb 2006 09:33:38 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from [83.242.61.219] (219-61-242-83.dip.h-tel.de [83.242.61.219]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate2.zdv.Uni-Mainz.DE (Postfix) with ESMTP id A8C7A300068D; Thu, 2 Feb 2006 10:33:35 +0100 (CET) Message-ID: <43E1D1E9.3000302@mail.uni-mainz.de> Date: Thu, 02 Feb 2006 10:33:29 +0100 From: "O. Hartmann" User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: freebsd-amd64@freebsd.org, freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary="------------010809030804050606080304" X-Virus-Scanned: by amavisd-new at uni-mainz.de X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: missing fpresetsticky in ieeefp.h X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 09:33:39 -0000 This is a multi-part message in MIME format. --------------010809030804050606080304 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello. I do not know whether this should be a bug report or not, I will ask prior to any further action. Reading 'man fpresetsticky' show up a man page for FPGETROUND(3) and tells me the existence of the fpresetsticky routine. Now take a look into , where this function should be declared. Nothing, I can not find this routine, it seems to be 'not available' on my FreeBSD6.1-PRERELEASE AMD64 (no 32Bit compatibility). Background is, I try to compile GMT 4.1 and ran into this problem again (I reveal this error since FBSD 5.4-PRE also on i386). If fpresetsticky() isn't available on amd64 anymore, it shouldn't be mentioned in the manpage. But it seems to me to be a bug, so somebody should confirm this. Or there is a mistake I do all the time, in that case, you should correct me. Thanks for your patience, Oliver P.S. uname -a tells: FreeBSD thor.schanze.de 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #36: Wed Feb 1 21:26:07 CET 2006 root@thor.schanze.de:/usr/obj/usr/src/sys/THOR amd64 --------------010809030804050606080304-- From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 2 11:10:36 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F009F16A420; Thu, 2 Feb 2006 11:10:36 +0000 (GMT) (envelope-from ohartman@uni-mainz.de) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.178.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86CA043D49; Thu, 2 Feb 2006 11:10:36 +0000 (GMT) (envelope-from ohartman@uni-mainz.de) Received: from [134.93.180.123] (ipamzra.Physik.Uni-Mainz.DE [134.93.180.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate1.zdv.Uni-Mainz.DE (Postfix) with ESMTP id E0BBD3000794; Thu, 2 Feb 2006 12:10:34 +0100 (CET) Message-ID: <43E1E8B0.3030702@uni-mainz.de> Date: Thu, 02 Feb 2006 12:10:40 +0100 From: "O. Hartmann" User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "O. Hartmann" References: <43E1D1E9.3000302@mail.uni-mainz.de> In-Reply-To: <43E1D1E9.3000302@mail.uni-mainz.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: missing fpresetsticky in ieeefp.h X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 11:10:37 -0000 O. Hartmann schrieb: > Hello. > I do not know whether this should be a bug report or not, I will ask > prior to any further action. > > Reading 'man fpresetsticky' show up a man page for FPGETROUND(3) and > tells me the existence of the fpresetsticky routine. > Now take a look into , where this function should be > declared. Nothing, I can not find this routine, it seems to be 'not > available' on my FreeBSD6.1-PRERELEASE AMD64 (no 32Bit compatibility). > > Background is, I try to compile GMT 4.1 and ran into this problem again > (I reveal this error since FBSD 5.4-PRE also on i386). > > If fpresetsticky() isn't available on amd64 anymore, it shouldn't be > mentioned in the manpage. But it seems to me to be a bug, so somebody > should confirm this. > > Or there is a mistake I do all the time, in that case, you should > correct me. > > Thanks for your patience, > Oliver > > P.S. > uname -a tells: > FreeBSD thor.schanze.de 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #36: Wed > Feb 1 21:26:07 CET 2006 > root@thor.schanze.de:/usr/obj/usr/src/sys/THOR amd64 Oh, sorry for the noise, I need to correct the i386 issue. On a FreeBSD 6.1-PRERELEASE box GMT 4.1 compiles without a mess, it seems the fpresetsticky() funtion is only available in anm i386 environment. Commenting out this on a amd64 box solves the problem, but I doubt this will be the right way, although there is no such function available on amd64. From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 2 12:01:13 2006 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DF1E16A422; Thu, 2 Feb 2006 12:01:13 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4530643D45; Thu, 2 Feb 2006 12:01:12 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id k12C14wo019431; Thu, 2 Feb 2006 23:01:06 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id k12C102j000862; Thu, 2 Feb 2006 23:01:01 +1100 Date: Thu, 2 Feb 2006 23:01:00 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "O. Hartmann" In-Reply-To: <43E1E8B0.3030702@uni-mainz.de> Message-ID: <20060202224815.K7234@delplex.bde.org> References: <43E1D1E9.3000302@mail.uni-mainz.de> <43E1E8B0.3030702@uni-mainz.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "O. Hartmann" , freebsd-stable@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: missing fpresetsticky in ieeefp.h X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 12:01:13 -0000 On Thu, 2 Feb 2006, O. Hartmann wrote: > O. Hartmann schrieb: >> Hello. >> I do not know whether this should be a bug report or not, I will ask prior >> to any further action. >> >> Reading 'man fpresetsticky' show up a man page for FPGETROUND(3) and tells >> me the existence of the fpresetsticky routine. This is a bug in the man page. fpresetsticky() is supposed to only exist on i386's, but the man page and its link to fpresetsticky.3 are installed for all arches. >> Now take a look into , where this function should be >> declared. Nothing, I can not find this routine, it seems to be 'not >> available' on my FreeBSD6.1-PRERELEASE AMD64 (no 32Bit compatibility). It was removed for amd64 and never existed for some other arches. It was apparently unused when it was removed a year ago. >> Background is, I try to compile GMT 4.1 and ran into this problem again (I >> reveal this error since FBSD 5.4-PRE also on i386). >> >> If fpresetsticky() isn't available on amd64 anymore, it shouldn't be >> mentioned in the manpage. But it seems to me to be a bug, so somebody >> should confirm this. % RCS file: /home/ncvs/src/sys/amd64/include/ieeefp.h,v % Working file: ieeefp.h % head: 1.14 % ... % ---------------------------- % revision 1.13 % date: 2005/03/15 15:53:39; author: das; state: Exp; lines: +0 -20 % Remove fpsetsticky(). This was added for SysV compatibility, but due % to mistakes from day 1, it has always had semantics inconsistent with % SVR4 and its successors. In particular, given argument M: % % - On Solaris and FreeBSD/{alpha,sparc64}, it clobbers the old flags % and *sets* the new flag word to M. (NetBSD, too?) % - On FreeBSD/{amd64,i386}, it *clears* the flags that are specified in M % and leaves the remaining flags unchanged (modulo a small bug on amd64.) % - On FreeBSD/ia64, it is not implemented. % % There is no way to fix fpsetsticky() to DTRT for both old FreeBSD apps % and apps ported from other operating systems, so the best approach % seems to be to kill the function and fix any apps that break. I % couldn't find any ports that use it, and any such ports would already % be broken on FreeBSD/ia64 and Linux anyway. % % By the way, the routine has always been undocumented in FreeBSD, % except for an MLINK to a manpage that doesn't describe it. This % manpage has stated since 5.3-RELEASE that the functions it describes % are deprecated, so that must mean that functions that it is *supposed* % to describe but doesn't are even *more* deprecated. ;-) % % Note that fpresetsticky() has been retained on FreeBSD/i386. As far % as I can tell, no other operating systems or ports of FreeBSD % implement it, so there's nothing for it to be inconsistent with. % % PR: 75862 % Suggested by: bde % ---------------------------- Bruce From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 2 12:38:14 2006 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA3CA16A420; Thu, 2 Feb 2006 12:38:14 +0000 (GMT) (envelope-from ohartman@uni-mainz.de) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.178.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ADEC43D45; Thu, 2 Feb 2006 12:38:13 +0000 (GMT) (envelope-from ohartman@uni-mainz.de) Received: from [134.93.180.123] (ipamzra.Physik.Uni-Mainz.DE [134.93.180.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate2.zdv.Uni-Mainz.DE (Postfix) with ESMTP id A7E9930007F5; Thu, 2 Feb 2006 13:38:12 +0100 (CET) Message-ID: <43E1FD40.9060408@uni-mainz.de> Date: Thu, 02 Feb 2006 13:38:24 +0100 From: "O. Hartmann" User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Bruce Evans References: <43E1D1E9.3000302@mail.uni-mainz.de> <43E1E8B0.3030702@uni-mainz.de> <20060202224815.K7234@delplex.bde.org> In-Reply-To: <20060202224815.K7234@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Cc: "O. Hartmann" , freebsd-stable@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: missing fpresetsticky in ieeefp.h X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 12:38:15 -0000 Bruce Evans schrieb: > On Thu, 2 Feb 2006, O. Hartmann wrote: > >> O. Hartmann schrieb: >>> Hello. >>> I do not know whether this should be a bug report or not, I will ask >>> prior to any further action. >>> >>> Reading 'man fpresetsticky' show up a man page for FPGETROUND(3) and >>> tells me the existence of the fpresetsticky routine. > > This is a bug in the man page. fpresetsticky() is supposed to only exist > on i386's, but the man page and its link to fpresetsticky.3 are installed > for all arches. > >>> Now take a look into , where this function should >>> be declared. Nothing, I can not find this routine, it seems to be >>> 'not available' on my FreeBSD6.1-PRERELEASE AMD64 (no 32Bit >>> compatibility). > > It was removed for amd64 and never existed for some other arches. It was > apparently unused when it was removed a year ago. > >>> Background is, I try to compile GMT 4.1 and ran into this problem >>> again (I reveal this error since FBSD 5.4-PRE also on i386). >>> >>> If fpresetsticky() isn't available on amd64 anymore, it shouldn't be >>> mentioned in the manpage. But it seems to me to be a bug, so somebody >>> should confirm this. > > % RCS file: /home/ncvs/src/sys/amd64/include/ieeefp.h,v > % Working file: ieeefp.h > % head: 1.14 > % ... > % ---------------------------- > % revision 1.13 > % date: 2005/03/15 15:53:39; author: das; state: Exp; lines: +0 -20 > % Remove fpsetsticky(). This was added for SysV compatibility, but due > % to mistakes from day 1, it has always had semantics inconsistent with > % SVR4 and its successors. In particular, given argument M: > % % - On Solaris and FreeBSD/{alpha,sparc64}, it clobbers the old flags > % and *sets* the new flag word to M. (NetBSD, too?) > % - On FreeBSD/{amd64,i386}, it *clears* the flags that are specified in M > % and leaves the remaining flags unchanged (modulo a small bug on amd64.) > % - On FreeBSD/ia64, it is not implemented. > % % There is no way to fix fpsetsticky() to DTRT for both old FreeBSD apps > % and apps ported from other operating systems, so the best approach > % seems to be to kill the function and fix any apps that break. I > % couldn't find any ports that use it, and any such ports would already > % be broken on FreeBSD/ia64 and Linux anyway. > % % By the way, the routine has always been undocumented in FreeBSD, > % except for an MLINK to a manpage that doesn't describe it. This > % manpage has stated since 5.3-RELEASE that the functions it describes > % are deprecated, so that must mean that functions that it is *supposed* > % to describe but doesn't are even *more* deprecated. ;-) > % % Note that fpresetsticky() has been retained on FreeBSD/i386. As far > % as I can tell, no other operating systems or ports of FreeBSD > % implement it, so there's nothing for it to be inconsistent with. > % % PR: 75862 > % Suggested by: bde > % ---------------------------- > > Bruce Thanks a lot. In prior software compilations of GMT on FBSD/AMD64 I commented out the appropriate line in gmt_init.c without any hazardous effects - but I never used GMT that intensive having ever recognozed any malicious side effects. I should contact the guys from Soest/Hawaii asking them for any serious effects commenting out this line on amd64 architectures. Oliver From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 2 16:01:14 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25D4316A420; Thu, 2 Feb 2006 16:01:14 +0000 (GMT) (envelope-from owner-freebsd-stable@freebsd.org) Received: from magnum.mistaken-identity.co.uk (slayer-of.demon.co.uk [62.49.5.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49FAF43D4C; Thu, 2 Feb 2006 16:01:12 +0000 (GMT) (envelope-from owner-freebsd-stable@freebsd.org) Received: from mail pickup service by magnum.mistaken-identity.co.uk with Microsoft SMTPSVC; Thu, 2 Feb 2006 16:01:05 +0000 thread-index: AcYoEd+nj0EPH9/KQUuW/kt8WTavvw== X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Date: Thu, 2 Feb 2006 16:01:05 -0000 From: "O. Hartmann" Message-ID: <000501c62811$dfa95750$fe07000a@Home.local> User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: References: <43E1D1E9.3000302@mail.uni-mainz.de> In-Reply-To: <43E1D1E9.3000302@mail.uni-mainz.de> Content-Type: text/plain; format=flowed; charset="UTF-8" X-Mailer: Microsoft CDO for Exchange 2000 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-mainz.de X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Content-Class: urn:content-classes:message Importance: normal Sender: Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Errors-To: owner-freebsd-stable@freebsd.org X-OriginalArrivalTime: 02 Feb 2006 16:01:05.0981 (UTC) FILETIME=[DFBBA6D0:01C62811] Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: missing fpresetsticky in ieeefp.h X-BeenThere: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 16:01:14 -0000 O. Hartmann schrieb: > Hello. > I do not know whether this should be a bug report or not, I will ask > prior to any further action. > > Reading 'man fpresetsticky' show up a man page for FPGETROUND(3) and > tells me the existence of the fpresetsticky routine. > Now take a look into , where this function should be > declared. Nothing, I can not find this routine, it seems to be 'not > available' on my FreeBSD6.1-PRERELEASE AMD64 (no 32Bit compatibility). > > Background is, I try to compile GMT 4.1 and ran into this problem again > (I reveal this error since FBSD 5.4-PRE also on i386). > > If fpresetsticky() isn't available on amd64 anymore, it shouldn't be > mentioned in the manpage. But it seems to me to be a bug, so somebody > should confirm this. > > Or there is a mistake I do all the time, in that case, you should > correct me. > > Thanks for your patience, > Oliver > > P.S. > uname -a tells: > FreeBSD thor.schanze.de 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #36: Wed > Feb 1 21:26:07 CET 2006 > root@thor.schanze.de:/usr/obj/usr/src/sys/THOR amd64 Oh, sorry for the noise, I need to correct the i386 issue. On a FreeBSD 6.1-PRERELEASE box GMT 4.1 compiles without a mess, it seems the fpresetsticky() funtion is only available in anm i386 environment. Commenting out this on a amd64 box solves the problem, but I doubt this will be the right way, although there is no such function available on amd64. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 2 16:01:18 2006 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1045B16A420; Thu, 2 Feb 2006 16:01:18 +0000 (GMT) (envelope-from owner-freebsd-stable@freebsd.org) Received: from magnum.mistaken-identity.co.uk (slayer-of.demon.co.uk [62.49.5.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BAE943D4C; Thu, 2 Feb 2006 16:01:15 +0000 (GMT) (envelope-from owner-freebsd-stable@freebsd.org) Received: from mail pickup service by magnum.mistaken-identity.co.uk with Microsoft SMTPSVC; Thu, 2 Feb 2006 16:01:05 +0000 thread-index: AcYoEd+p9TE0sYEkS6mwR/wGVOn/AA== X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Date: Thu, 2 Feb 2006 16:01:05 -0000 Message-ID: <000601c62811$dfaaddf0$fe07000a@Home.local> From: "Bruce Evans" Content-Transfer-Encoding: 7bit X-X-Sender: bde@delplex.bde.org To: In-Reply-To: <43E1E8B0.3030702@uni-mainz.de> References: <43E1D1E9.3000302@mail.uni-mainz.de><43E1E8B0.3030702@uni-mainz.de> X-Mailer: Microsoft CDO for Exchange 2000 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset="US-ASCII" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Content-Class: urn:content-classes:message Importance: normal Sender: Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Errors-To: owner-freebsd-stable@freebsd.org X-OriginalArrivalTime: 02 Feb 2006 16:01:05.0911 (UTC) FILETIME=[DFB0F870:01C62811] Cc: "O. Hartmann" , freebsd-stable@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: missing fpresetsticky in ieeefp.h X-BeenThere: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 16:01:18 -0000 On Thu, 2 Feb 2006, O. Hartmann wrote: > O. Hartmann schrieb: >> Hello. >> I do not know whether this should be a bug report or not, I will ask prior >> to any further action. >> >> Reading 'man fpresetsticky' show up a man page for FPGETROUND(3) and tells >> me the existence of the fpresetsticky routine. This is a bug in the man page. fpresetsticky() is supposed to only exist on i386's, but the man page and its link to fpresetsticky.3 are installed for all arches. >> Now take a look into , where this function should be >> declared. Nothing, I can not find this routine, it seems to be 'not >> available' on my FreeBSD6.1-PRERELEASE AMD64 (no 32Bit compatibility). It was removed for amd64 and never existed for some other arches. It was apparently unused when it was removed a year ago. >> Background is, I try to compile GMT 4.1 and ran into this problem again (I >> reveal this error since FBSD 5.4-PRE also on i386). >> >> If fpresetsticky() isn't available on amd64 anymore, it shouldn't be >> mentioned in the manpage. But it seems to me to be a bug, so somebody >> should confirm this. % RCS file: /home/ncvs/src/sys/amd64/include/ieeefp.h,v % Working file: ieeefp.h % head: 1.14 % ... % ---------------------------- % revision 1.13 % date: 2005/03/15 15:53:39; author: das; state: Exp; lines: +0 -20 % Remove fpsetsticky(). This was added for SysV compatibility, but due % to mistakes from day 1, it has always had semantics inconsistent with % SVR4 and its successors. In particular, given argument M: % % - On Solaris and FreeBSD/{alpha,sparc64}, it clobbers the old flags % and *sets* the new flag word to M. (NetBSD, too?) % - On FreeBSD/{amd64,i386}, it *clears* the flags that are specified in M % and leaves the remaining flags unchanged (modulo a small bug on amd64.) % - On FreeBSD/ia64, it is not implemented. % % There is no way to fix fpsetsticky() to DTRT for both old FreeBSD apps % and apps ported from other operating systems, so the best approach % seems to be to kill the function and fix any apps that break. I % couldn't find any ports that use it, and any such ports would already % be broken on FreeBSD/ia64 and Linux anyway. % % By the way, the routine has always been undocumented in FreeBSD, % except for an MLINK to a manpage that doesn't describe it. This % manpage has stated since 5.3-RELEASE that the functions it describes % are deprecated, so that must mean that functions that it is *supposed* % to describe but doesn't are even *more* deprecated. ;-) % % Note that fpresetsticky() has been retained on FreeBSD/i386. As far % as I can tell, no other operating systems or ports of FreeBSD % implement it, so there's nothing for it to be inconsistent with. % % PR: 75862 % Suggested by: bde % ---------------------------- Bruce _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 2 16:53:56 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF3C416A420; Thu, 2 Feb 2006 16:53:56 +0000 (GMT) (envelope-from nvidican@wmptl.com) Received: from wmptl.net (mail.wmptl.com [216.8.159.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69AA743D46; Thu, 2 Feb 2006 16:53:55 +0000 (GMT) (envelope-from nvidican@wmptl.com) Received: from [10.0.0.104] (r3140ca.wmptl.net [10.0.0.104]) by wmptl.net (8.13.1/8.13.1) with ESMTP id k12GrsIr026715; Thu, 2 Feb 2006 11:53:54 -0500 (EST) (envelope-from nvidican@wmptl.com) Message-ID: <43E23969.6070309@wmptl.com> Date: Thu, 02 Feb 2006 11:55:05 -0500 From: Nathan Vidican User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.111 () RATWR10_MESSID X-Scanned-By: MIMEDefang 2.44 Cc: amd64@freebsd.org Subject: changelog from 6.0-RC1 to 6.0-RELEASE X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 16:53:57 -0000 Where may I find a changelog from 6.0-RC1, to 6.0-RELEASE; what has/was changed? Reason being, I still have a box running 6.0-RC1... and as much as I would like to update to 6.0-RELEASE, if it ain't broke - don't fix it. -- Nathan Vidican nvidican@wmptl.com Windsor Match Plate & Tool Ltd. http://www.wmptl.com/ From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 2 17:00:53 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8ABB216A420 for ; Thu, 2 Feb 2006 17:00:53 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9F9443D48 for ; Thu, 2 Feb 2006 17:00:52 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so429533nzo for ; Thu, 02 Feb 2006 09:00:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rDhNbO+MsC5YTRi9eva7rjRr3s35W7QjobC8lHfKNyVNpBnU5ndS0wIO4cVq5OS+oi55MeeVb3vwdUUY8FNPME8G2JJK/0jUDMjLVGjor51JED2GamdkFrujHchJVYmwnp9frMqM8zEcMnhJScWAfWx6+e9J/+lIYMYn6QOPP48= Received: by 10.37.2.70 with SMTP id e70mr813491nzi; Thu, 02 Feb 2006 09:00:51 -0800 (PST) Received: by 10.37.20.11 with HTTP; Thu, 2 Feb 2006 09:00:51 -0800 (PST) Message-ID: Date: Thu, 2 Feb 2006 20:00:51 +0300 From: Andrew Pantyukhin To: Nathan Vidican In-Reply-To: <43E23969.6070309@wmptl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43E23969.6070309@wmptl.com> Cc: amd64@freebsd.org, questions@freebsd.org Subject: Re: changelog from 6.0-RC1 to 6.0-RELEASE X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 17:00:53 -0000 On 2/2/06, Nathan Vidican wrote: > Where may I find a changelog from 6.0-RC1, to 6.0-RELEASE; what has/was c= hanged? > > Reason being, I still have a box running 6.0-RC1... and as much as I woul= d like > to update to 6.0-RELEASE, if it ain't broke - don't fix it. > > -- > Nathan Vidican > nvidican@wmptl.com > Windsor Match Plate & Tool Ltd. > http://www.wmptl.com/ > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > You are certainly advised to upgrade to RELENG_6_0, because there are several security advisories which affect RC1 and RELEASE. The upgrade process is as seamless as it gets. From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 2 23:36:21 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FEDA16A422 for ; Thu, 2 Feb 2006 23:36:21 +0000 (GMT) (envelope-from garrigue@math.nagoya-u.ac.jp) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB82643D45 for ; Thu, 2 Feb 2006 23:36:20 +0000 (GMT) (envelope-from garrigue@math.nagoya-u.ac.jp) Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id k12NaIZg002726; Fri, 3 Feb 2006 08:36:18 +0900 (JST) Date: Fri, 03 Feb 2006 08:36:12 +0900 (JST) Message-Id: <20060203.083612.07456737.garrigue@math.nagoya-u.ac.jp> To: freebsd-amd64@freebsd.org From: Jacques Garrigue X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: calmasy@gmail.com Subject: Freebsd on HP xw9300 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 23:36:21 -0000 Trying to boot off the 6.0-release amd64 installation CD on an HP xw9300 workstation (1 opteron 280 / nvidia nforce professional / 4GB memory), it aborts with the following message: panic: No BIOS smap info from loader! This looks very similar with the following report, also on an HP workstation. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=61050+0+/usr/local/www/db/text/2004/freebsd-amd64/20041114.freebsd-amd64 Does anybody run freebsd on an xw9300? Has anybody seen the above message? Is there a workaround? (Looking at the boot code, it seems a symptom that a BIOS interrupt is not working correctly, but this alone doesn't help...) Jacques Garrigue From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 3 05:10:12 2006 Return-Path: X-Original-To: freebsd-amd64@hub.freebsd.org Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 423C116A420 for ; Fri, 3 Feb 2006 05:10:12 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B417343D45 for ; Fri, 3 Feb 2006 05:10:11 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k135ABiG040863 for ; Fri, 3 Feb 2006 05:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k135ABTU040862; Fri, 3 Feb 2006 05:10:11 GMT (envelope-from gnats) Date: Fri, 3 Feb 2006 05:10:11 GMT Message-Id: <200602030510.k135ABTU040862@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: David Xu Cc: Subject: Re: amd64/88299: swapcontext fails with errno 0 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Xu List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2006 05:10:12 -0000 The following reply was made to PR amd64/88299; it has been noted by GNATS. From: David Xu To: bug-followup@FreeBSD.org, arjo.hooimeijer@xs4all.nl Cc: Subject: Re: amd64/88299: swapcontext fails with errno 0 Date: Fri, 03 Feb 2006 13:06:26 +0800 I have committed a change in -HEAD, file /usr/src/sys/amd64/amd64/machdep.c, revision 1.646, I suspect this change may have fixed the problem. David Xu From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 3 17:58:49 2006 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C2AC16A420; Fri, 3 Feb 2006 17:58:49 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3ADB43D45; Fri, 3 Feb 2006 17:58:48 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id k13HwhM6002091; Sat, 4 Feb 2006 04:58:44 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id k13HweDZ024530; Sat, 4 Feb 2006 04:58:41 +1100 Date: Sat, 4 Feb 2006 04:58:40 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "O. Hartmann" In-Reply-To: <43E1FD40.9060408@uni-mainz.de> Message-ID: <20060204042336.F11473@delplex.bde.org> References: <43E1D1E9.3000302@mail.uni-mainz.de> <43E1E8B0.3030702@uni-mainz.de> <20060202224815.K7234@delplex.bde.org> <43E1FD40.9060408@uni-mainz.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "O. Hartmann" , freebsd-stable@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: missing fpresetsticky in ieeefp.h X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2006 17:58:49 -0000 On Thu, 2 Feb 2006, O. Hartmann wrote: > Bruce Evans schrieb: >> On Thu, 2 Feb 2006, O. Hartmann wrote: >> ... >>>> Now take a look into , where this function should be >>>> declared. Nothing, I can not find this routine, it seems to be 'not >>>> available' on my FreeBSD6.1-PRERELEASE AMD64 (no 32Bit compatibility). >> >> It was removed for amd64 and never existed for some other arches. It was [fresetsticky()] >> apparently unused when it was removed a year ago. >> ... >> % RCS file: /home/ncvs/src/sys/amd64/include/ieeefp.h,v >> ... >> % revision 1.13 > ... > Thanks a lot. In prior software compilations of GMT on FBSD/AMD64 I commented > out the appropriate line in gmt_init.c without any hazardous effects - but I > never used GMT that intensive having ever recognozed any malicious side > effects. > > I should contact the guys from Soest/Hawaii asking them for any serious > effects commenting out this line on amd64 architectures. I think it is probably used only for error detection, if at all. Accumulated IEEE exceptions are supposed to be read using fpgetsticky() and then cleared using fp[re]setsticky() so that the next set accumulated can be distinguished from the old set. Applications should now use fesetexceptflag() instead of fp[re]setsticky(). BTW, the most useful fp* functions other than fp[re]setsticky(), namely fp{get,set}round(), never worked on ia64 due to the rounding flags values being misspelled, so there are unlikely to be any portable uses of the fp* functions in ports. The corresponding fe{get,set}round() functions work on at least i386, amd64 and ia64. Bruce From owner-freebsd-amd64@FreeBSD.ORG Fri Feb 3 23:07:58 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A23616A420; Fri, 3 Feb 2006 23:07:58 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7489243D46; Fri, 3 Feb 2006 23:07:57 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.4/8.13.4) with ESMTP id k13N7uic060225; Fri, 3 Feb 2006 18:07:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id k13N7tUG038402; Fri, 3 Feb 2006 18:07:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B8CA57302F; Fri, 3 Feb 2006 18:07:55 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060203230755.B8CA57302F@freebsd-current.sentex.ca> Date: Fri, 3 Feb 2006 18:07:55 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2006 23:07:58 -0000 TB --- 2006-02-03 21:15:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-02-03 21:15:17 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-02-03 21:15:17 - cleaning the object tree TB --- 2006-02-03 21:15:55 - checking out the source tree TB --- 2006-02-03 21:15:55 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-02-03 21:15:55 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-02-03 21:23:09 - building world (CFLAGS=-O2 -pipe) TB --- 2006-02-03 21:23:09 - cd /src TB --- 2006-02-03 21:23:09 - /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: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2006-02-03 22:55:48 - generating LINT kernel config TB --- 2006-02-03 22:55:48 - cd /src/sys/amd64/conf TB --- 2006-02-03 22:55:48 - /usr/bin/make -B LINT TB --- 2006-02-03 22:55:48 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-02-03 22:55:48 - cd /src TB --- 2006-02-03 22:55:48 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 3 22:55:48 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/posix4/ksched.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/posix4/p1003_1b.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/posix4/posix4_mib.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/rpc/rpcclnt.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/security/audit/audit_arg.c /src/sys/security/audit/audit_arg.c: In function `audit_arg_upath': /src/sys/security/audit/audit_arg.c:676: warning: long long unsigned int format, u_int64_t arg (arg 2) /src/sys/security/audit/audit_arg.c:678: warning: long long unsigned int format, u_int64_t arg (arg 2) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-02-03 23:07:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-02-03 23:07:55 - ERROR: failed to build lint kernel TB --- 2006-02-03 23:07:55 - tinderbox aborted TB --- 1.33 user 7.00 system 6757.84 real From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 4 06:10:15 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3777A16A438 for ; Sat, 4 Feb 2006 06:10:15 +0000 (GMT) (envelope-from zombyfork@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADF3843D45 for ; Sat, 4 Feb 2006 06:10:14 +0000 (GMT) (envelope-from zombyfork@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so772949nzo for ; Fri, 03 Feb 2006 22:10:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=feI2ytnm/lUlh6nMbWrZ9lYx4nouuJ37gyL2SZqybMBZ0mIFRI2F59ZxDriUYiBI8HQIop2qgTVPQixk4voFRlS1cgGkBqNJ6CGARiUBA67IvejI+2f3BCoU4kbtJS8BQySOYCR3NfGGvHOYaCWarhCRAEVOasbCJZ9ucKf0TOw= Received: by 10.36.227.37 with SMTP id z37mr2260518nzg; Fri, 03 Feb 2006 22:10:13 -0800 (PST) Received: by 10.36.77.17 with HTTP; Fri, 3 Feb 2006 22:10:13 -0800 (PST) Message-ID: <346a80220602032210o71367220v74033da94e3d83bb@mail.gmail.com> Date: Sat, 4 Feb 2006 01:10:13 -0500 From: Coleman Kane To: Antoine Pelisse In-Reply-To: <61c746830602011322x13bfe7ddwfb81ba0eaf358658@mail.gmail.com> MIME-Version: 1.0 References: <43D9A099.8060909@samsco.org> <20060127043323.GA31513@xor.obsecurity.org> <61c746830601270414w44e868b9q77dd50565bc448b6@mail.gmail.com> <346a80220601281153y5f3c201ex8049a544a4f1ccea@mail.gmail.com> <61c746830602011322x13bfe7ddwfb81ba0eaf358658@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-amd64@freebsd.org, Kris Kennaway Subject: Re: 32-bit X libs? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2006 06:10:15 -0000 On 2/1/06, Antoine Pelisse wrote: > > > On 1/28/06, Coleman Kane wrote: > > > > What about this... > > > > Install 32-bit FreeBSD into ia32. and then make another ports dir there= . > > Then run against the 32-bit make binary that would be in there somewher= e? > > You could have all of the /*/(lib,bin,sbin,libexec)32 dirs as symlinks = into > > this compat section, making it easy to remove and replace your 32-bit > > userland should it be necessary. > > > > I know on that Mac OS X, the solution is to make every dynamic binary > > have ppc,ppc64, and x86 sections in it (effectively 3 binaries archived= in > > one file) using Mach-O binaries. Dunno if this type of thing is possibl= e, or > > even desireable under ELF (or just for the FreeBSD community in general= ). > > > > It would be really cool to have the 32-bit userland (on amd64) be able > > to install ports easily on the system choosing either 32 or 64 with a m= ake > > option. > > > > -- > > coleman kane > > > > > That sounds nice, but I can't take care of it as I, ironically, have no > working amd64 box. It would be great if someone else could take care of t= hat > > Regards, > Antoine > It is difficult for me to believe that I am the only one with a working amd64 box. I am more than happy to help in this endevaour, but I lack the available time to appropriately spearhead this project. If enough people ar= e willing to help, I might be able to get something rolling. -- coleman kane From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 4 07:43:47 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A990716A420 for ; Sat, 4 Feb 2006 07:43:47 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11B6043D46 for ; Sat, 4 Feb 2006 07:43:46 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by uproxy.gmail.com with SMTP id j3so173781ugf for ; Fri, 03 Feb 2006 23:43:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MPkq7wQT3LpbiMoSFR7TBA63hBJFjtLVDT/BF3RX4U7g9St2CfAMAHpHwWZxRhdVzM99b8bMqts2fJHPU4jm+oMjlXALISEbhYX+P63FVPUXRSIHxZeY+H/xOO5RdqcfONtFT6jL5bYk4m1d6SkTNEzwF3oS1G5HNqduPOLIowY= Received: by 10.66.216.11 with SMTP id o11mr1295578ugg; Fri, 03 Feb 2006 23:43:45 -0800 (PST) Received: by 10.66.240.5 with HTTP; Fri, 3 Feb 2006 23:43:45 -0800 (PST) Message-ID: <2fd864e0602032343w9143655l6db9b82cc63d66e6@mail.gmail.com> Date: Sat, 4 Feb 2006 01:43:45 -0600 From: Astrodog To: freebsd-amd64@freebsd.org In-Reply-To: <2fd864e0602032333t6c8879e3u6e1901c4ebcf12bc@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43D9A099.8060909@samsco.org> <20060127043323.GA31513@xor.obsecurity.org> <61c746830601270414w44e868b9q77dd50565bc448b6@mail.gmail.com> <346a80220601281153y5f3c201ex8049a544a4f1ccea@mail.gmail.com> <61c746830602011322x13bfe7ddwfb81ba0eaf358658@mail.gmail.com> <346a80220602032210o71367220v74033da94e3d83bb@mail.gmail.com> <2fd864e0602032333t6c8879e3u6e1901c4ebcf12bc@mail.gmail.com> Subject: Fwd: 32-bit X libs? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2006 07:43:47 -0000 Stupid gmail... ---------- Forwarded message ---------- From: Astrodog Date: Feb 4, 2006 1:33 AM Subject: Re: 32-bit X libs? To: Coleman Kane This seems to be an ongoing thing. I see 3 fundamental requirements that need to be met in the ia32 compat. #1. Allow installation of 32-bit binary packages on AMD64 machines. #2. Provide the bits nessisary to build i386-only ports on an AMD64 machine to run in compat mode #3. Have some logical way to split the 32-bit system, from the main AMD64 base. Otherwise, there's no chance we'll get configure scripts to ever work properly. I like the "/usr/compat/ia32" idea, myself. From owner-freebsd-amd64@FreeBSD.ORG Sat Feb 4 20:47:59 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95A8616A426 for ; Sat, 4 Feb 2006 20:47:59 +0000 (GMT) (envelope-from conrads@cox.net) Received: from eastrmmtao03.cox.net (eastrmmtao03.cox.net [68.230.240.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id C162C43D49 for ; Sat, 4 Feb 2006 20:47:58 +0000 (GMT) (envelope-from conrads@cox.net) Received: from serene.no-ip.org ([68.14.59.177]) by eastrmmtao03.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060204204806.CSSU29285.eastrmmtao03.cox.net@serene.no-ip.org>; Sat, 4 Feb 2006 15:48:06 -0500 Received: from serene.no-ip.org (localhost [127.0.0.1]) by serene.no-ip.org (8.13.4/8.13.4) with ESMTP id k14KlvKZ034684; Sat, 4 Feb 2006 14:47:57 -0600 (CST) (envelope-from conrads@serene.no-ip.org) Received: (from conrads@localhost) by serene.no-ip.org (8.13.4/8.13.4/Submit) id k14Klp3T034683; Sat, 4 Feb 2006 14:47:52 -0600 (CST) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <346a80220602032210o71367220v74033da94e3d83bb@mail.gmail.com> Date: Sat, 04 Feb 2006 14:47:51 -0600 (CST) From: Conrad Sabatier To: Coleman Kane Cc: freebsd-amd64@freebsd.org, Kris Kennaway Subject: Re: 32-bit X libs? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2006 20:47:59 -0000 On 04-Feb-2006 Coleman Kane wrote: > It is difficult for me to believe that I am the only one with a working > amd64 box. I am more than happy to help in this endevaour, but I lack the > available time to appropriately spearhead this project. If enough people > are willing to help, I might be able to get something rolling. If there's anything I can do to help, please let me know. At this time I have *only* an amd64 box (my i386 box having been ruined in the floodwaters of Hurricane Katrina). I like the /usr/compat/ia32 idea, too. -- Conrad J. Sabatier -- "In Unix veritas"