Re: psm problem
On Thu, Aug 15, 2002 at 12:14:37AM +0200, Anselm Garbe wrote: Hi there, after make world of today: my mouse behaves sometimes curios (while moving around, some selections are done, without clicking)... OK, after installing a new world (source code of Aug 15, 2002 at 00:00 MEZ), the psm problem still exists, here's what /var/log/messages says: Aug 15 08:30:36 odin named[183]: Ready to answer queries. Aug 15 08:34:13 odin kernel: drm0: ATI Radeon QW 7500 (AGP) port 0x9000-0x90ff mem 0xdd00-0xdd00,0xd000-0xd7ff irq 5 at device 0.0 on pci1 Aug 15 08:34:13 odin kernel: info: [drm] AGP at 0xd800 64MB Aug 15 08:34:13 odin kernel: info: [drm] Initialized radeon 1.1.1 20010405 on minor 0 Aug 15 08:34:41 odin kernel: psmintr: out of sync ( != 0008). Aug 15 08:34:41 odin kernel: psmintr: discard a byte (1). Aug 15 08:34:41 odin kernel: psmintr: out of sync ( != 0008). Aug 15 08:34:41 odin kernel: psmintr: discard a byte (2). Aug 15 08:34:41 odin kernel: psmintr: out of sync ( != 0008). Aug 15 08:34:41 odin kernel: psmintr: discard a byte (3). It's clear now, that this problem starts after launching X. The last world I tried was of Aug 06, 2002 without these problems. XFree86 was installed also on Aug 06, 2002 via ports. Anselm To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CFLAGS=-O and WARN=5
On Thu, Aug 15, 2002 at 08:07:29AM +0900, Jun Kuriyama wrote: What I want to know is, our buildworld does not been supported without -O or not. AFAIK it world should compile with -O (I seem to remember parts breaking with -O0 for instance). - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
emulators/rtc and vmware2
Is anybody successfully using the port emulators/rtc with vmware2 on -current? While the port builds and installs fine, a /dev/rtc device never appears. ISTM that the rtc device does a make_dev as part of the device open() rather than at module load and that vmware doesn't work like that. Having no kernel (module) hacking experience, I come to the list for pointers. I am trying to wrap my head around rtc enough to try make_dev() at module load time, but maybe someone can give me a hint as to what's going on. I'm breaking the rules and running an old -CURRENT from Feb 4, 2002, so I'll humbly swallow suggestions that I upgrade. Thanks loads, dan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Weirdness trying -STABLE - -CURRENT
On Wed, 14 Aug 2002 21:31:35 -0700 (PDT) Nate Lawson wrote:
:I upgraded a machine from 4.6R to -CURRENT today and had similar
:problems. Comments below.
:
I upgraded from 4.5R to -CURRENT last night, and had /no/ issues.
:On Wed, 14 Aug 2002, David Wolfskill wrote:
: To upgrade from 4.x-stable to current
: -
: make buildworld
: make buildkernel KERNCONF=YOUR_KERNEL_HERE
: cp src/sys/${MACHINE_ARCH}/conf/GENERIC.hints /boot/device.hints [2]
: make installkernel KERNCONF=YOUR_KERNEL_HERE
:
: No problem up to here.
:
:Same.
:
Ditto
: reboot in single user [3]
:
: OK; here we have a fundamental problem, illustrated by the following
: commands I issued just after the make installkernel:
:
: freebeast(4.6-S)[3] grep '^kernel' /boot/defaults/loader.conf
: kernel=/kernel
: kernel_options=
: freebeast(4.6-S)[4]
:
: The clue that I had was reviewing the transcript, and when I did the
: single-user boot, the system identified itself as 4.6-STABLE.
:
:This happened to me too. Perhaps the instructions should say to unload
:kernel; load /boot/kernel/kernel on reboot or maybe explicitly copy in the
:new /boot/defaults/loader.conf like you do with device.hints?
:
unload kernel; load /boot/kernel/kernel; boot -s brought up 5-CURRENT.
/snip errors that I didn't get and problems I didn't experiance/
fsck -p
mount -u /
mount -a
cd /usr/src
make installworld #Note the lack of option '-k'
mergemaster
Everything went perfect (well, except my hands hurting from pressing 'i'
and [enter] about 7 bajillion times. ;-)
So possibly, the only thing that needs to be added to UPDATING is
the recommendation to do the unload/load dance?
--
Peter Hessler [[EMAIL PROTECTED]]
[http://www.theapt.org]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: emulators/rtc and vmware2
On Thu, Aug 15, 2002 at 07:11:05AM -0500 I heard the voice of
dmk, and lo! it spake thus:
Is anybody successfully using the port emulators/rtc with vmware2 on
-current?
[...]
Replying to myself...
I have since hacked rtc so it works with vmware2 on my -CURRENT system
dated February 4, 2002.
In the shocking case that anyone is interested, I have attached the
diff. (I would appreciate anybody looking at the diff as it is my first
kernel hack.)
Thanks loads,
dan
--- rtc.c.bkThu Aug 15 03:50:21 2002
+++ rtc.c Thu Aug 15 03:51:30 2002
-177,9 +177,8
rtc_open(dev_t dev, int oflag, int otyp, struct proc *p)
#endif
{
- struct rtc_softc *sc;
+ struct rtc_softc *sc = (struct rtc_softc *) dev-si_drv1;
- sc = rtc_attach(dev);
if (sc==NULL)
return (EAGAIN);
-264,7 +263,21
static int
init_module(void)
{
-int error;
+ int error;
+ struct rtc_softc *sc;
+ dev_t dev;
+
+ dev = make_dev(rtc_cdevsw, 0, UID_ROOT, GID_WHEEL, 0600, DEVICE_NAME);
+ if(dev==NULL)
+ return (NULL);
+
+ MALLOC(sc, struct rtc_softc*, sizeof(*sc), M_DEVBUF, M_WAITOK);
+ if(sc==NULL)
+ return NULL;
+
+ bzero(sc, sizeof(*sc));
+ rtc_sc = sc;
+ dev-si_drv1 = sc; /* Link together */
error = cdevsw_add(rtc_cdevsw);
if (error)
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === games/grdc cc1: warnings being treated as errors In file included from /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include/ncurses.h:112, from /local0/scratch/des/src/games/grdc/grdc.c:15: /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include/stdbool.h:41: warning: useless keyword or type name in empty declaration /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include/stdbool.h:41: warning: empty declaration *** Error code 1 Stop in /local0/scratch/des/src/games/grdc. *** Error code 1 Stop in /local0/scratch/des/src/games. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
See my HEADS UP message to -CURRENT and the 20020815 entry to src/UPDATING. On Thu, Aug 15, 2002 at 08:38:41AM -0700, Dag-Erling Smorgrav wrote: -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === games/grdc cc1: warnings being treated as errors In file included from /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include/ncurses.h:112, from /local0/scratch/des/src/games/grdc/grdc.c:15: /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include/stdbool.h:41: warning: useless keyword or type name in empty declaration /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include/stdbool.h:41: warning: empty declaration *** Error code 1 Stop in /local0/scratch/des/src/games/grdc. *** Error code 1 Stop in /local0/scratch/des/src/games. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg41916/pgp0.pgp Description: PGP signature
Re: OT: Debian GNU/FreeBSD???
I'd debate silly, but you're more or less correct. The userland is really a bit mixed. Most of /sbin and /usr/sbin is from FreeBSD (kind of necessary), while most of /usr/bin is from Debian. ---Nathan Brooks Davis wrote: On Thu, Aug 15, 2002 at 12:51:49AM +0200, Mario Goebbels wrote: I'm slightly offtopic with this, but what the heck is that: http://www.debian.org/ports/freebsd/index I was slightly irritated when a pal showed me that! It's Debian people being silly. Someone decided they liked the FreeBSD kernel and the Debian way of doing userland and combined the two. As you can see from the webpage, it's not exactly popular (the site hasn't been updated in four months.) It's more or less legal and doesn't hurt anything. -- Brooks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pkg-comment
That will certainly be a big help. When we got rid of the pkg/ and
patches/ directories I begged Satoshi to go farther and put patches in
main port directory and get rid of pkg/COMMENT. That was back when we
hit 3000 ports -- I guess people didn't want to accept we would hit 8000
in only a few years.
Of course why we don't just put COMMENT=blah in the ports's Makefile
Posted patch uses `head -1 ${DESCR}` however.
I'd prefer to go NetBSD way and use COMMENT=blah for ports comments
This patch is small and simple and allows us to reclaim a huge number of
inodes. It also allows for an easy transition.
I think the information in the comment probably belongs at the top of the
description as well, but either way is fine as soon as I see a patch for
other proposed placement. I just want my inodes back, sooner rather than
later.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic: system call accept returning with mutex(s) held
Hmm. This could be my bug due to mixing up a -stable and a -current
patch. I modified accept() to reject negative sockaddr name lengths, but
it looks like I botched the return path:
if (uap-name) {
error = copyin(uap-anamelen, namelen, sizeof (namelen));
if(error)
goto done2;
if (namelen 0)
return (EINVAL);
}
Try turning that 'return (EINVAL);' into a 'goto done2;' and see if that
helps.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Thu, 15 Aug 2002, Mike Heffner wrote:
With -current from earlier this week, panics whenever I start
gaim. Didn't see anything similar in the archives. I'll be happy to
provide more information if needed.
Mounting root from ufs:/dev/ad0s2a
exclusive sleep mutex Giant r = 0 (0xc02da9a0) locked @ ../../../kern/subr_trap.c:80
panic: system call accept returning with mutex(s) held
syncing disks... panic: bremfree: bp 0xc3c32ee4 not locked
Uptime: 3m18s
pfs_vncache_unload(): 1 entries remaining
Dumping 127 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01aaa86 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc01aaca3 in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc01dfc47 in bremfree (bp=0xc02b0f05) at ../../../kern/vfs_bio.c:633
#4 0xc01e1668 in vfs_bio_awrite (bp=0xc1525840) at ../../../kern/vfs_bio.c:1627
#5 0xc022e991 in ffs_fsync (ap=0xc8e7bc1c) at ../../../ufs/ffs/ffs_vnops.c:231
#6 0xc022df8e in ffs_sync (mp=0xc1471400, waitfor=2, cred=0xc0babe00, td=0xc02d6480)
at vnode_if.h:545
#7 0xc01f162c in sync (td=0xc02d6480, uap=0x0) at ../../../kern/vfs_syscalls.c:129
#8 0xc01aa6a2 in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#9 0xc01aaca3 in panic () at ../../../kern/kern_shutdown.c:493
#10 0xc027d8a2 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135554112, tf_esi = 135604464,
tf_ebp = -1077940868, tf_isp = -924336780, tf_ebx = 673945180, tf_edx = 1, tf_ecx =
0, tf_eax = 22, tf_trapno = 12, tf_err = 2, tf_eip = 676290179, tf_cs = 31, tf_eflags
= 663, tf_esp = -1077941024, tf_ss = 47}) at ../../../i386/i386/trap.c:1120
#11 0xc026e76d in Xint0x80_syscall () at {standard input}:140
FreeBSD 5.0-CURRENT #1: Wed Aug 14 12:19:54 EDT 2002
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/SATELLIT
E
Preloaded elf kernel /boot/kernel/kernel at 0xc03ff000.
Preloaded elf module /boot/kernel/random.ko at 0xc03ff0a8.
Preloaded elf module /boot/kernel/acpi.ko at 0xc03ff154.
Timecounter i8254 frequency 1193182 Hz
Timecounter TSC frequency 746339059 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (746.34-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x686 Stepping = 6
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA
T,PSE36,MMX,FXSR,SSE
real memory = 134086656 (130944K bytes)
avail memory = 125779968 (122832K bytes)
Mike
--
Mike Heffner mheffner@[acm.]vt.edu
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic: system call accept returning with mutex(s) held
Actually, I've gone ahead and committed the change, update to
uipc_syscalls.c:1.128 and see if the problem goes away. (if you do it by
hand locally, make sure to assign error = EINVAL before jumping).
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Thu, 15 Aug 2002, Robert Watson wrote:
Hmm. This could be my bug due to mixing up a -stable and a -current
patch. I modified accept() to reject negative sockaddr name lengths, but
it looks like I botched the return path:
if (uap-name) {
error = copyin(uap-anamelen, namelen, sizeof (namelen));
if(error)
goto done2;
if (namelen 0)
return (EINVAL);
}
Try turning that 'return (EINVAL);' into a 'goto done2;' and see if that
helps.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Thu, 15 Aug 2002, Mike Heffner wrote:
With -current from earlier this week, panics whenever I start
gaim. Didn't see anything similar in the archives. I'll be happy to
provide more information if needed.
Mounting root from ufs:/dev/ad0s2a
exclusive sleep mutex Giant r = 0 (0xc02da9a0) locked @
../../../kern/subr_trap.c:80
panic: system call accept returning with mutex(s) held
syncing disks... panic: bremfree: bp 0xc3c32ee4 not locked
Uptime: 3m18s
pfs_vncache_unload(): 1 entries remaining
Dumping 127 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01aaa86 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc01aaca3 in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc01dfc47 in bremfree (bp=0xc02b0f05) at ../../../kern/vfs_bio.c:633
#4 0xc01e1668 in vfs_bio_awrite (bp=0xc1525840) at ../../../kern/vfs_bio.c:1627
#5 0xc022e991 in ffs_fsync (ap=0xc8e7bc1c) at ../../../ufs/ffs/ffs_vnops.c:231
#6 0xc022df8e in ffs_sync (mp=0xc1471400, waitfor=2, cred=0xc0babe00,
td=0xc02d6480)
at vnode_if.h:545
#7 0xc01f162c in sync (td=0xc02d6480, uap=0x0) at ../../../kern/vfs_syscalls.c:129
#8 0xc01aa6a2 in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#9 0xc01aaca3 in panic () at ../../../kern/kern_shutdown.c:493
#10 0xc027d8a2 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135554112, tf_esi = 135604464,
tf_ebp = -1077940868, tf_isp = -924336780, tf_ebx = 673945180, tf_edx = 1, tf_ecx =
0, tf_eax = 22, tf_trapno = 12, tf_err = 2, tf_eip = 676290179, tf_cs = 31, tf_eflags
= 663, tf_esp = -1077941024, tf_ss = 47}) at ../../../i386/i386/trap.c:1120
#11 0xc026e76d in Xint0x80_syscall () at {standard input}:140
FreeBSD 5.0-CURRENT #1: Wed Aug 14 12:19:54 EDT 2002
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/SATELLIT
E
Preloaded elf kernel /boot/kernel/kernel at 0xc03ff000.
Preloaded elf module /boot/kernel/random.ko at 0xc03ff0a8.
Preloaded elf module /boot/kernel/acpi.ko at 0xc03ff154.
Timecounter i8254 frequency 1193182 Hz
Timecounter TSC frequency 746339059 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (746.34-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x686 Stepping = 6
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA
T,PSE36,MMX,FXSR,SSE
real memory = 134086656 (130944K bytes)
avail memory = 125779968 (122832K bytes)
Mike
--
Mike Heffner mheffner@[acm.]vt.edu
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: emulators/rtc and vmware2
My recollection is that the problem relates to calling make_dev() from the attach routine, and attach from the open call, and of course you can't open before you make_dev with devfs. Someone needs to restructure the driver to match some our other pseudo-device drivers where the device is properly created as part of module initialization. If fixed this and other things locally at one point on my notebook, but eventually got sufficiently sick of always fixing the kernel module for the latest -CURRENT change that I gave up on updating it. I have since lost the changes, but they shouldn't be too hard to reproduce. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Thu, 15 Aug 2002, dmk wrote: Is anybody successfully using the port emulators/rtc with vmware2 on -current? While the port builds and installs fine, a /dev/rtc device never appears. ISTM that the rtc device does a make_dev as part of the device open() rather than at module load and that vmware doesn't work like that. Having no kernel (module) hacking experience, I come to the list for pointers. I am trying to wrap my head around rtc enough to try make_dev() at module load time, but maybe someone can give me a hint as to what's going on. I'm breaking the rules and running an old -CURRENT from Feb 4, 2002, so I'll humbly swallow suggestions that I upgrade. Thanks loads, dan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emulators/rtc and vmware2
On Thu, Aug 15, 2002 at 07:11:05AM -0500, dmk wrote: Is anybody successfully using the port emulators/rtc with vmware2 on -current? While the port builds and installs fine, a /dev/rtc device never appears. ISTM that the rtc device does a make_dev as part of the device open() rather than at module load and that vmware doesn't work like that. Having no kernel (module) hacking experience, I come to the list for pointers. I am trying to wrap my head around rtc enough to try make_dev() at module load time, but maybe someone can give me a hint as to what's going on. I'm breaking the rules and running an old -CURRENT from Feb 4, 2002, so I'll humbly swallow suggestions that I upgrade. I committed to changes to rtc and vmware2 in the last few days to make it compile on recent -current. There have been a lot of changes since Feb!! On my system rtc compiles and kldload and vmware works. I don't know if rtc actually works though. Maybe not. I'll take a look at your patch in due course. Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg41923/pgp0.pgp Description: PGP signature
RE: GCC 3.2
Hi, Are any plans to move to GCC 3.2 in current? Since it is just an ABI change it should work, without changing anything. It would give us a stable, multivendor ABI to work off of for the next line of 5.x releases. Just a thought. Jesse Gross Yes, moving to gcc32 is highly desirable for -current, otherwise we will be stuck at gcc311 for the entire life of FreeBSD 5.x. The important question to ask is, who will do the dirty work? Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2
Yes, moving to gcc32 is highly desirable for -current, otherwise we will be stuck at gcc311 for the entire life of FreeBSD 5.x. The important question to ask is, who will do the dirty work? Moving to GCC 3.2 will do us no good. The lifetime of the 3.2 release will be pretty short and 3.3 is supposed to replace it pretty soon. If we stick with 3.2 in -CURRENT, we'll find ourself tied to an old and unsupported release for the whole 5.x line, i.e. we'll risk to repeat 2.95.x story yet again. David O'Brien proposes to move -CURRENT directly to the 3.3 CVS shanshots, bypassing the GCC 3.2 version altogether. Early FreeBSD 5.x release(s) will not be polished for general consumption anyway, so that makes sense. By the time FreeBSD stabilizes, GCC 3.3 release will be ready. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2
On Thu, Aug 15, 2002 at 11:59:11AM -0600, Long, Scott wrote: Hi, Are any plans to move to GCC 3.2 in current? Since it is just an ABI change it should work, without changing anything. It would give us a stable, multivendor ABI to work off of for the next line of 5.x releases. Just a thought. Jesse Gross Yes, moving to gcc32 is highly desirable for -current, otherwise we will be stuck at gcc311 for the entire life of FreeBSD 5.x. The important question to ask is, who will do the dirty work? Scott I'd be willing to help. I'm not exactly sure on what modifications to gcc are required to shove it into the base, but I have time (not working right now). :) -- -Erik [EMAIL PROTECTED] [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
buildworld breakage
I don't know if I'm the only one having this problem, but I haven't been able to make a complete buildworld for a couple of days now. The last time I upgraded was arround August 5. I have been getting a signal 11 consistently in the same spot. === secure/usr.sbin/sshd === share === share/colldef colldef -I /daemon/build/current/src/share/colldef -o bg_BG.CP1251.out /daemon/build/current/src/share/colldef/bg_BG.CP1251.src *** Signal 11 Stop in /daemon/build/current/src/share/colldef. *** Error code 1 Stop in /daemon/build/current/src/share. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld breakage
I got that but a recent cvsup fixed it. Not sure what the problem was but there were a few patches to colldef on Wednesday. -Nate On Thu, 15 Aug 2002, Mike Makonnen wrote: I don't know if I'm the only one having this problem, but I haven't been able to make a complete buildworld for a couple of days now. The last time I upgraded was arround August 5. I have been getting a signal 11 consistently in the same spot. === secure/usr.sbin/sshd === share === share/colldef colldef -I /daemon/build/current/src/share/colldef -o bg_BG.CP1251.out /daemon/build/current/src/share/colldef/bg_BG.CP1251.src *** Signal 11 Stop in /daemon/build/current/src/share/colldef. *** Error code 1 Stop in /daemon/build/current/src/share. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: GCC 3.2
Yes, moving to gcc32 is highly desirable for -current, otherwise we will be stuck at gcc311 for the entire life of FreeBSD 5.x. The important question to ask is, who will do the dirty work? Moving to GCC 3.2 will do us no good. The lifetime of the 3.2 release will be pretty short and 3.3 is supposed to replace it pretty soon. If we stick with 3.2 in -CURRENT, we'll find ourself tied to an old and unsupported release for the whole 5.x line, i.e. we'll risk to repeat 2.95.x story yet again. David O'Brien proposes to move -CURRENT directly to the 3.3 CVS shanshots, bypassing the GCC 3.2 version altogether. Early FreeBSD 5.x release(s) will not be polished for general consumption anyway, so that makes sense. By the time FreeBSD stabilizes, GCC 3.3 release will be ready. I agree that gcc32 is not an ideal target either, but by going to it, we can upgrade to gcc33 when it's available and not loose binary compatibility (at least, according to the gcc folks). I'd rather move to gcc32 right now and get the binary compatibility pain out of the way, rather than wait for the last second to move to gcc33, then have to delay FreeBSD 5.0 because everything in c++ land is broken. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2
I agree that gcc32 is not an ideal target either, but by going to it, we can upgrade to gcc33 when it's available and not loose binary compatibility (at least, according to the gcc folks). I'd rather move to gcc32 right now and get the binary compatibility pain out of the way, rather than wait for the last second to move to gcc33, then have to delay FreeBSD 5.0 because everything in c++ land is broken. The idea is to move to gcc 3.3-pre _now_ If GCC 3.2 has C++ ABI kinks worked out, GCC 3.3 surely has the same code in. GCC developers are trying to keep C++ ABI compatible between 3.2 and 3.3, but they are not giving any guaranrtees. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: system call accept returning with mutex(s) held
On Thu, Aug 15, 2002 at 01:34:47PM -0400, Robert Watson wrote: | Actually, I've gone ahead and committed the change, update to | uipc_syscalls.c:1.128 and see if the problem goes away. (if you do it by | hand locally, make sure to assign error = EINVAL before jumping). | That did it. Thanks! Mike -- Mike Heffner mheffner@[acm.]vt.edu [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2
Alexander Kabaev wrote: The idea is to move to gcc 3.3-pre _now_ If GCC 3.2 has C++ ABI kinks worked out, GCC 3.3 surely has the same code in. GCC developers are trying to keep C++ ABI compatible between 3.2 and 3.3, but they are not giving any guaranrtees. Cool. We can call it 3.3 in the release. Just like RedHat jumped the gun on the compiler release. And we all know how successful that was, right? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2
Jesse Gross wrote: Are any plans to move to GCC 3.2 in current? Since it is just an ABI change it should work, without changing anything. It would give us a stable, multivendor ABI to work off of for the next line of 5.x releases. I believe David O'brien answer this the last 3 times it was asked. I will paraphrase: No, we are waiting for 3.3. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2
Cool. We can call it 3.3 in the release. Terry, we will name it the same way we name our current GCC 3.1 snapshots. FreeBSD always shipped tweaked version of GCC with a bunch of local changes merges in. In STABLE, for example, we have gcc version 2.95.4 20020320 [FreeBSD] Just like RedHat jumped the gun on the compiler release. We are not _releasing_ our own version of GCC and we do not invent our own version numbers for it, so your attempt to compare us with RedHat is unjustified. Again, FreeBSD 5.0 will be in no shape for serious production use and putting GCC 3.2 there just to replace it with newer and possibly binary incompatible 3.3 release shortly afterwards is a complete waste of time. And we all know how successful that was, right? On the other side, we all know how successfull we were trying to get GCC 2.95.x bugs fixed for us, right? Do you really want to repeat this deeply satisfying experiment again? -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
world broken
cc -pg -O -pipe -I. -I/vol/share/src/lib/libncurses -I/vol/share/src/lib/libncu rses/../../contrib/ncurses/ncurses -I/vol/share/src/lib/libncurses/../../contrib /ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -c u nctrl.c -o unctrl.po In file included from curses.h:112, from /vol/share/src/contrib/ncurses/ncurses/curses.priv.h:250, from expanded.c:2: /usr/obj/vol/share/src/i386/usr/include/stdbool.h:41: warning: useless keyword o r type name in empty declaration /usr/obj/vol/share/src/i386/usr/include/stdbool.h:41: warning: empty declaration In file included from curses.h:112, from /vol/share/src/contrib/ncurses/ncurses/curses.priv.h:250, from fallback.c:5: /usr/obj/vol/share/src/i386/usr/include/stdbool.h:41: warning: useless keyword o r type name in empty declaration /usr/obj/vol/share/src/i386/usr/include/stdbool.h:41: warning: empty declaration In file included from curses.h:112, from /vol/share/src/contrib/ncurses/ncurses/curses.priv.h:250, from expanded.c:2: /usr/obj/vol/share/src/i386/usr/include/stdbool.h:41: warning: useless keyword o r type name in empty declaration /usr/obj/vol/share/src/i386/usr/include/stdbool.h:41: warning: empty declaration cc -fpic -DPIC -O -pipe -I. -I/vol/share/src/lib/libncurses -I/vol/share/src/li b/libncurses/../../contrib/ncurses/ncurses -I/vol/share/src/lib/libncurses/../.. /contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMI I get those a lot now... please fix. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADSUP: cam_extend gone
Sorry this is a little late. I committed a change today that removes cam_extend.[ch] and removes usage of it from all periphs. If you're working on a new CAM periph driver, please use dev-si_drv1 instead. See cam/scsi/scsi_da.c for an example. I've tested a full build of the patch for a while with da and cd but don't have equipment to test the rest. Please let me know if you find any problems. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2
Alexander Kabaev wrote: We are not _releasing_ our own version of GCC and we do not invent our own version numbers for it, so your attempt to compare us with RedHat is unjustified. Again, FreeBSD 5.0 will be in no shape for serious production use and putting GCC 3.2 there just to replace it with newer and possibly binary incompatible 3.3 release shortly afterwards is a complete waste of time. There's always waiting for 3.3 to be released before trying to incorporate it... And we all know how successful that was, right? On the other side, we all know how successfull we were trying to get GCC 2.95.x bugs fixed for us, right? Do you really want to repeat this deeply satisfying experiment again? That was because the patches were not being submitted back against the unadulterated distribution code someone who had signed the assignment of rights to the FSF. The inability to get patches into 2.95 is totally unrelated to the fact that it was an older GCC, and completely related to the fact that the patches were not submitted in accordance with the GCC maintainer's guidelines, combined with not a little Linux advocacy and ELF advocacy. This issue is *nothing* like FreeBSD's steadfast refusal for *two years* to adopt ELF, and GCC treating non-ELF support as legacy support, with no expectations of continued developement. In the context the question was asked, it was *also* not about FreeBSD trying to get patches into GCC, it was about upgrading to GCC 3.2. It was also about trolling the mailing lists to cause just this sort of heated discussion (congradulations on playing into Jesse Gross's trolling here). It's all well and good to volunteer David O'Brien for additional *useless* work that he has already stated is *useless work*. I could understand raising the issue (though not over and over and over in a short period of time, as Mr. Gross has done recently) if the works was considered something that needed to be done immediately, or if patches to bmake the GCC 3.3 experimental release people want FreeBSD to user were being submitted, but all it's been so far is request for David O'Brien to do work he considers useless. FreeBSD has been conservative in its adoption of new compilers in the past; it would, in fact be reasonable, from an historical perspective, to not see 3.3 adopted for over a year following its release. I don't see why waiting for 3.3 to actually be released is such a terrible idea. Can *you* absolutely *guarantee* no binary incompatabilities between 3.3, as it sits now, in experimental form, and the final release of 3.3? If not, then I don't see why are exploding at me. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emulators/rtc and vmware2
At 1:36 PM -0400 8/15/02, Robert Watson wrote: Someone needs to restructure the driver to match some our other pseudo-device drivers where the device is properly created as part of module initialization. If fixed this and other things locally at one point on my notebook, but eventually got sufficiently sick of always fixing the kernel module for the latest -CURRENT change that I gave up on updating it. I have since lost the changes, but they shouldn't be too hard to reproduce. Someone had posted fixes to rtc for -current awhile back, and I have those updates saved away somewhere. If Josef's recent changes haven't fixed everything, I'll try to dig up that message. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emulators/rtc and vmware2
On Thu, Aug 15, 2002 at 07:09:26PM -0400, Garance A Drosihn wrote: Someone had posted fixes to rtc for -current awhile back, and I have those updates saved away somewhere. If Josef's recent changes haven't fixed everything, I'll try to dig up that message. My recent commit just fixed for MODDEPS having gone away in -current. It doesn't change any code. (It was a fix submitted to -emulation a little while ago.) Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg41939/pgp0.pgp Description: PGP signature
Re: GCC 3.2
That was because the patches were not being submitted back against the unadulterated distribution code someone who had signed the assignment of rights to the FSF. That was because GCC 2.95.x branch is closed for maintenance. The is no need in complex theory when a simple explanation is more than adequate. It was also about trolling the mailing lists to cause just this sort of heated discussion (congradulations on playing into Jesse Gross's trolling here). Sorry, guilty as charged. I was trying to get a people opinion on the issue. I will gladly volunteer to import a new version of GCC into -CURRENT myself, if there are no objections and if nobody is doing that already. I think David got a point though and I want his proposal to be discussed more. GCC 3.2 is an interim release and under no circumstances we should get tied to it through all the 5.x branch lifetime. No one will give a damn about it once 3.3 goes into maintenance. Can *you* absolutely *guarantee* no binary incompatabilities between 3.3, as it sits now, in experimental form, and the final release of 3.3? If not, then I don't see why are exploding at me. 3.1-pre to 3.2 upgrade breaks compatibility already. Can you guarantee that 3.3 will be backwards compatible with 3.2? This is yet another potential ABI breakage at the time when we'll be _forced_ to upgrade. How often do you expect GCC developers to break ABI with release scheduled to happed and the end of the year? -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2
It was also about trolling the mailing lists to cause just this sort of heated discussion (congradulations on playing into Jesse Gross's trolling here). This was *not* about trolling the mailing list. I wish I were intelligent enough to predict the behavior of thousands of people, most of whose names I don't even know, to cause a chain reaction to result in something like this. I do know that I did not intend for this particular result to happen, and am sorry I started this thread. Believe it or not, sometimes things are actually what they seem, in this case it really was a simple question. Terry, please do not bother replying to this message. Unless people wish to discuss technical details, this thread should be ended. Jesse Gross __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2
Alexander Kabaev wrote: Can *you* absolutely *guarantee* no binary incompatabilities between 3.3, as it sits now, in experimental form, and the final release of 3.3? If not, then I don't see why are exploding at me. 3.1-pre to 3.2 upgrade breaks compatibility already. Can you guarantee that 3.3 will be backwards compatible with 3.2? This is yet another potential ABI breakage at the time when we'll be _forced_ to upgrade. How often do you expect GCC developers to break ABI with release scheduled to happed and the end of the year? Once for every time the code is imported into FreeBSD, plus one. I think Murphy is a GCC committer... 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === games/grdc cc1: warnings being treated as errors In file included from /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include/ncurses.h:112, from /local0/scratch/des/src/games/grdc/grdc.c:15: /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include/stdbool.h:41: warning: useless keyword or type name in empty declaration /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include/stdbool.h:41: warning: empty declaration *** Error code 1 Stop in /local0/scratch/des/src/games/grdc. *** Error code 1 Stop in /local0/scratch/des/src/games. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld breakage
On 12:10-0700, Aug 15, 2002, Mike Makonnen wrote: I don't know if I'm the only one having this problem, but I haven't been able to make a complete buildworld for a couple of days now. The last time I upgraded was arround August 5. I have been getting a signal 11 consistently in the same spot. === secure/usr.sbin/sshd === share === share/colldef colldef -I /daemon/build/current/src/share/colldef -o bg_BG.CP1251.out /daemon/build/current/src/share/colldef/bg_BG.CP1251.src *** Signal 11 ache has fixed that. -- Maxim Konovalov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
