Re: PPP problems in -CURRENT
At 09:24 4/9/99 +0100, Brian Somers wrote: >Does anything different happen if you > > set accmap 000a > >in your ppp.conf ? If not, you're going to have to approach your ISP >and ask them why their ppp implementation is ignoring our requests >(which needless to say violates the rfc). It would appear that a few more things are wrong, because the setting doesn't help on my 4.0-CURRENT box, but downgrading to 3.1-RELEASE fixes the problem. With this in mind, I copied and gzipped the 3.1-RELEASE ppp binaries (known to work) to a safe place, upgraded to 4.0-CURRENT once more, and attempted to use the 3.1-REL binaries with 4.0. The strange thing is that it doesn't work. I'm retreating to the relative sanity of 3.1-STABLE, will let you know what happens. -- K To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users (fwd)
On Fri, 9 Apr 1999, Chris Costello wrote: > Date: Fri, 9 Apr 1999 18:30:31 -0500 > From: Chris Costello > Reply-To: ch...@calldei.com > To: Dmitry Valdov > Cc: freebsd-questi...@freebsd.org > Subject: Re: DoS from local users > > On Fri, Apr 9, 1999, Dmitry Valdov wrote: > > Hi! > > > > Try it: > > > > cat > qqq > > echo $$ > > echo ~/qqq|~/qqq|~/qqq|~/qqq|~/qqq > > > > Ctrl-D > > > > ./qqq > > > > Is there Any way to fix it? > >You typically want to set a restriction as to how many > processes a user can spawn. This is done by editing > /etc/login.conf and changing the user's login class, see the man > page for 'login.conf'. > I'm about CPU usage, not about many processes. See: CPU states: 17.8% user, 0.0% nice, 81.7% system, 0.5% interrupt, 0.0% idle on any (tested on P2-45) machine. CPU is used by SYSTEM, not by USER. So I can't restrict it with login.conf And load average can be up to 20-40 :( Please don't redirect me to -questions, it's a kernel problem, not just config. Dmitry. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users
On Sat, 10 Apr 1999, oZZ!!! wrote: > Date: Sat, 10 Apr 1999 02:27:22 +0400 (MSD) > From: oZZ!!! > To: Dmitry Valdov > Cc: freebsd-current@FreeBSD.ORG > Subject: Re: DoS from local users > > > > Hi! > > Try it: > > > > cat > qqq > > echo $$ > > echo ~/qqq|~/qqq|~/qqq|~/qqq|~/qqq > > > > Ctrl-D > > > > ./qqq > > > > Is there Any way to fix it? > > > > Dmitry. > > > % cat > qqq > echo $$ > echo ~/qqq|~/qqq|~/qqq|~/qqq|~/qqq > % ./qqq > ./qqq: Permission denied. > % > & what fix? > Oh, sorry, chmod 555 qqq. I was drunk a little :) Machine will have load average about 20-40. Dmitry. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: msdosfs problems?
On Sat, Apr 10, 1999 at 11:39:20AM +0800, adr...@freebsd.org wrote: > >In its defense, mpg123 is not ancient, and is the _BEST_ MP3 player. I have > >no idea what kinda of b0rked up MP3s there are nowadays it won't play. > Crappy Windows encoders. I have a bunch of mp3s that play under xaudio but > not mpg123. And I have several mp3s that play just fine for mpg123 but not for xaudio. Maybe I just have an older version of xaudio (April 24, 1998 is the timestamp). -- Zach Heilig To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
On Fri, 9 Apr 1999, eagle wrote: > > > On Sat, 10 Apr 1999, Chuck Robey wrote: > > > On Fri, 9 Apr 1999, eagle wrote: > > > > > > Whelp... I vote to break tradition. Hack away...The installer takes > > > > care of alot of stuff like ports installs. Perhaps different standard > > > > setups could be configured as ports. Ie. 'bloated setup' would require > > > > all the ports which are currently included. > > > > > > > > 'Server setup' port wouldn't have any Client stuff. > > > > > > > > 'Desktop' could install a 'nicer' windomanager (kde? gnome?) for teh > > > > user, > > > > and be pre-setup to start xdm, etc. > > > > > > > > The installer can currently install packages, so reworking those 'system > > > > install options' to fit simpler naming convention than 'Kernel Hacker, X > > > > user, X+ source, etc.' may be appropriate. > > > > > > > > I know.. lots of talk and no action. Oh well... my thoughts :) > > > > > > > well geeze Xwindows isnt in the base source tree anymore, what more do > > > ya want ;) > > > > Anymore? It's never been there to begin with. > perhaps i'm wrong but i woulda swore it was in /usr/src/contrib in > 4.4lite2 at least It's never ever been in any FreeBSD sources. I didn't take a look at the 4.4Lite2 sources before they were brought into FreeBSD, but it's not been any part of FreeBSD, of that I'm certain. > > > rob > > > +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
On Sat, 10 Apr 1999, Chuck Robey wrote: > On Fri, 9 Apr 1999, eagle wrote: > > > > Whelp... I vote to break tradition. Hack away...The installer takes > > > care of alot of stuff like ports installs. Perhaps different standard > > > setups could be configured as ports. Ie. 'bloated setup' would require > > > all the ports which are currently included. > > > > > > 'Server setup' port wouldn't have any Client stuff. > > > > > > 'Desktop' could install a 'nicer' windomanager (kde? gnome?) for teh user, > > > and be pre-setup to start xdm, etc. > > > > > > The installer can currently install packages, so reworking those 'system > > > install options' to fit simpler naming convention than 'Kernel Hacker, X > > > user, X+ source, etc.' may be appropriate. > > > > > > I know.. lots of talk and no action. Oh well... my thoughts :) > > > > > well geeze Xwindows isnt in the base source tree anymore, what more do > > ya want ;) > > Anymore? It's never been there to begin with. perhaps i'm wrong but i woulda swore it was in /usr/src/contrib in 4.4lite2 at least rob To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
On Fri, 9 Apr 1999, eagle wrote: > > Whelp... I vote to break tradition. Hack away...The installer takes > > care of alot of stuff like ports installs. Perhaps different standard > > setups could be configured as ports. Ie. 'bloated setup' would require > > all the ports which are currently included. > > > > 'Server setup' port wouldn't have any Client stuff. > > > > 'Desktop' could install a 'nicer' windomanager (kde? gnome?) for teh user, > > and be pre-setup to start xdm, etc. > > > > The installer can currently install packages, so reworking those 'system > > install options' to fit simpler naming convention than 'Kernel Hacker, X > > user, X+ source, etc.' may be appropriate. > > > > I know.. lots of talk and no action. Oh well... my thoughts :) > > > well geeze Xwindows isnt in the base source tree anymore, what more do > ya want ;) Anymore? It's never been there to begin with. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
On Sat, 10 Apr 1999, Rod Taylor wrote: > > Right or wrong, you forgot: > > > > 5. BSD tradition. > > > > Case 5 justifies Fortran. > > > > Me, I'd rather have Fortran as a port. I'd even grudgingly accept > > fortune as a port, as a matter of fact. Our base system is bloated. > > While a lot of widely used programs are only available through > > ports, a lot of obscure and obsolete stuff remains on our tree. They > > are there because of 5. As long as 5 exists, Fortran belongs in the > > tree. If we ever get rid of 5, then it's time to get the knife to > > our tree... Or the axe, if the vikings decide to have the first cut. > > :-) > > > > Whelp... I vote to break tradition. Hack away...The installer takes > care of alot of stuff like ports installs. Perhaps different standard > setups could be configured as ports. Ie. 'bloated setup' would require > all the ports which are currently included. > > 'Server setup' port wouldn't have any Client stuff. > > 'Desktop' could install a 'nicer' windomanager (kde? gnome?) for teh user, > and be pre-setup to start xdm, etc. > > The installer can currently install packages, so reworking those 'system > install options' to fit simpler naming convention than 'Kernel Hacker, X > user, X+ source, etc.' may be appropriate. > > I know.. lots of talk and no action. Oh well... my thoughts :) > well geeze Xwindows isnt in the base source tree anymore, what more do ya want ;) rob To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
> Right or wrong, you forgot: > > 5. BSD tradition. > > Case 5 justifies Fortran. > > Me, I'd rather have Fortran as a port. I'd even grudgingly accept > fortune as a port, as a matter of fact. Our base system is bloated. > While a lot of widely used programs are only available through > ports, a lot of obscure and obsolete stuff remains on our tree. They > are there because of 5. As long as 5 exists, Fortran belongs in the > tree. If we ever get rid of 5, then it's time to get the knife to > our tree... Or the axe, if the vikings decide to have the first cut. > :-) > Whelp... I vote to break tradition. Hack away...The installer takes care of alot of stuff like ports installs. Perhaps different standard setups could be configured as ports. Ie. 'bloated setup' would require all the ports which are currently included. 'Server setup' port wouldn't have any Client stuff. 'Desktop' could install a 'nicer' windomanager (kde? gnome?) for teh user, and be pre-setup to start xdm, etc. The installer can currently install packages, so reworking those 'system install options' to fit simpler naming convention than 'Kernel Hacker, X user, X+ source, etc.' may be appropriate. I know.. lots of talk and no action. Oh well... my thoughts :) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: msdosfs problems?
On Sat, 10 Apr 1999 adr...@freebsd.org wrote: > >No. The mp3s stored on the UFS partition are fine. And it's not just > >some of the MP3s on the fat partition, it's all of them, which is really > >really weird. I couldn't find xaudio, but amp belched a bit too. All in > >all it's really strange, I'm willing to accept random data corruption > >(although, scandisk didn't find any problems with the partition).. > > > > Ok, so if you copy them onto your UFS partition first, do they play ok? > (Just to be clear here..) No. I'm thinking a big magnet walked up while I was sleeping or something, b/c if I copy from UFS -> FAT it plays fine from FAT. Well, I just tried playing an mp3 from the zip drive and here's the panic I got (couldn't catch it from X): panic: vm_page_bits: illegal base/size 4096/2048 Haven't run scandisk on the disk recently, but windows groks it fine - alex To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: CD Mount Troubles
Daniel O'Connor wrote: > On 09-Apr-99 Rod Taylor wrote: > > My Joliet formated cd's aren't mounting with the Joliet extensions. I > > believe I saw that FreeBSD supported these extensions. I'm mounting > > mostly recorded cds, in older nec cdrom drives. (OS/2 mounts joliet > > extensions fine on same machine). > > There are patches which add Joliet support, but they don't work 100%.. > > I have a CD which gets mangled with the patches, so I haven't submitted them > yet :) > > > Some disks done mount at all, and are complained about. It reports that > > the cd just plain old 'does not exist'. > > ? You mean you get an I/O error? A Joliet CD should mount, just that you'll > get > Windows short names instead of long names. Nope (Nec 4x4 changer using OLD drivers). --- in fstab --- /dev/wcd0a/mnt/cd0cd9660ro,noauto00 /dev/wcd1a/mnt/cd1cd9660ro,noauto00 /dev/wcd2a/mnt/cd2cd9660ro,noauto00 /dev/wcd3a/mnt/cd3cd9660ro,noauto00 mount /mnt/cd0 cd9660: Invalid argument mount /mnt/cd1 mount /mnt/cd2 cd9660: Invalid argument mount /mnt/cd3 (cd0, cd1, cd2 ==> CD's burned with easy cd for windows (joliet filesystem)) (cd3 ==> Purchassed cd. 'Regular Filesystem'). cd1 mounted, but without the joliet extensions. cd0, cd2 didn't mount (with above error). cd3 mounted with long filenames (unsure of filesystem type). That help clarify things a bit more? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: msdosfs problems?
>> Sound system problem? > >No. The mp3s stored on the UFS partition are fine. And it's not just >some of the MP3s on the fat partition, it's all of them, which is really >really weird. I couldn't find xaudio, but amp belched a bit too. All in >all it's really strange, I'm willing to accept random data corruption >(although, scandisk didn't find any problems with the partition).. > Ok, so if you copy them onto your UFS partition first, do they play ok? (Just to be clear here..) Adrian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: msdosfs problems?
Brian Feldman writes: [snip] >> mpg123 is an ancient player. It won't play most newer MP3s. Use a newer >> player, like x11amp or xaudio. > >In its defense, mpg123 is not ancient, and is the _BEST_ MP3 player. I have >no idea what kinda of b0rked up MP3s there are nowadays it won't play. Crappy Windows encoders. I have a bunch of mp3s that play under xaudio but not mpg123. The mp3s I've encoded under various unix based encoders happily played under unix. But windows ones have all sorts of fun - some don't play at all, some have large skips (sound like 'smudges' in the music where it says "can't rewind stream by x bits!"..) but play perfect in xaudio/windows players. Which is all fine and good, except xaudio for some reason doesn't like my 2.2.7-REL laptop (plays sound at a fraction of the real speed).. Whether mpg123 is at fault from a 'standards' point of view, or the encoder is just crappy (more likely IMHO) and xaudio caters for it is something I don't have the answer for. MPEG heads out there, care to comment .. ? Adrian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: msdosfs problems?
On Fri, 9 Apr 1999, Doug White wrote: > > It's not mpg123. There were some files that never caused a problem with > > the same version of mpg123 before. And besides, x11amp is based on mpg123 > > isn't it? > > No. Hrm. I thought I saw that x11amp 0.9* was based on mpg123.. > How does xaudio react? > I don't buy that it's a FS-related difficulty; > you can play MP3s over NFS without trouble. Over UFS. The only NFS related mount I have is via Sharity-Lite (rumba), over a 33.6 modem. I already know how that would turn out. > > That still doesn't explain how it would cause my system to hang. > > Grr. Back to CDs it is. > > Sound system problem? No. The mp3s stored on the UFS partition are fine. And it's not just some of the MP3s on the fat partition, it's all of them, which is really really weird. I couldn't find xaudio, but amp belched a bit too. All in all it's really strange, I'm willing to accept random data corruption (although, scandisk didn't find any problems with the partition).. - alex To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: msdosfs problems?
On Fri, 9 Apr 1999, Doug White wrote: > On Thu, 8 Apr 1999, Alex Zepeda wrote: > > > I've got all my mp3s stored on my fat16 partition so I can easily share > > them between Win98 and fbsd. However recently mpg123 has been complaining > > about once valid mp3s: > > > > zippy:~/mp3s#mpg123 -b10240 U2/U2\ -\ Sunday\ Bloody\ Sunday.mp3 > > High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3. > > Version 0.59q (1999/Jan/26). Written and copyrights by Michael Hipp. > > Uses code from various people. See 'README' for more! > > THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK! > > Title : Sunday Bloody SundayArtist: U2 > > Album : Year: 83 > > Comment: Genre: Alternative > > > > Directory: U2/ > > Playing MPEG stream from U2 - Sunday Bloody Sunday.mp3 ... > > MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo > > Illegal Audio-MPEG-Header 0x at offset 0x80af. > > Skipped 4170 bytes in input. > > mpg123: Can't rewind stream by 679 bits! > > mpg123 is an ancient player. It won't play most newer MP3s. Use a newer > player, like x11amp or xaudio. In its defense, mpg123 is not ancient, and is the _BEST_ MP3 player. I have no idea what kinda of b0rked up MP3s there are nowadays it won't play. > > Doug White > Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve > http://gladstone.uoregon.edu/~dwhite| www.freebsd.org > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: 3.1 stable bootloader vs. 4.0 kernel...
> > Update your sources and install a new /boot. 4.x kernels need the > latest boot code due to the kernel's new start address. > Ah. Well, I'm fine at Feral where I do stuff- it's just an interesting gotcha for folks running 3.X now. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: 3.1 stable bootloader vs. 4.0 kernel...
:Did I miss something obvious here? I have a system over in England :somewhere which I'm remotely booting. It's 3.1Stable. When I try and put a :4.0/-current kernel (which boots fine on *my* much overwritten and not :reinstalled since 2.2.2 system), I get: : :Type '?' for a list of commands, 'help' for more detailed help. :disk1s1a:> :boot kernel.tst :/kernel.tst text=0x1a312e :elf_loadexec: archsw.readin failed :can't load module '/kernel.tst': input/output error : :Eh? : :-matt Update your sources and install a new /boot. 4.x kernels need the latest boot code due to the kernel's new start address. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: integer divide fault with vinum
On Saturday, 10 April 1999 at 4:05:10 +0200, Michael Reifenberger wrote: > On Sat, 10 Apr 1999, Greg Lehey wrote: >>> The panic occurs only, if I first use the incorrect config file with >>> 'stripe', then the corrected one with 'striped' and then detaching >>> the plex and the subdisks. > > This point is still valid. In fact, it's not necessary. It happens any time you detach the last subdisk from a striped or RAID-5 plex. > # vinum detach raid.p0 > # vinum detach raid.p0.s0 > # vinum detach raid.p0.s1 > ..panic.. > > It seems to be important to remove the last stale subdisk. Correct. What happened to the stack traces? Don't bother, though, I've reproduced it here. Expect a fix in a couple of hours. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: integer divide fault with vinum
On Sat, 10 Apr 1999, Greg Lehey wrote: ... > It looks like you have them now, but you didn't then. Strange, I'm shure I haven't touched them. > > > The only fault where the misspelling of 'stripe' versus 'striped' in > > the configfile! > > That's not what your error messages are trying to tell you. That seems right. > ... > >>> S raid.p0.s0State: stalePO:0 B Size: 50 > >>> MB > >>> S raid.p0.s1State: stalePO: 256 kB Size: 50 > >>> MB > >>> (Hmm, stale sigh. The vinum(8) GOTCHAS 2. is not explicit about my > >>> situation. > >> ... > > The panic occurs only, if I first use the incorrect config file with > > 'stripe', then the corrected one with 'striped' and then detaching > > the plex and the subdisks. This point is still valid. I just reproduced the panic again. This time the disks showed up and the errormessages where slightly different. They are not important for the panic. I did: )# vinum l Configuration summary Drives: 2 (4 configured) Volumes:2 (4 configured) Plexes: 1 (8 configured) Subdisks: 2 (16 configured) D d1State: up Device /dev/da1dAvail: 8664/8714 MB (99%) D d2State: up Device /dev/da2dAvail: 8664/8714 MB (99%) V raid State: down Plexes: 1 Size:100 MB P raid.p0 S State: down Subdisks: 2 Size:100 MB S raid.p0.s0State: stalePO:0 B Size: 50 MB S raid.p0.s1State: stalePO: 256 kB Size: 50 MB # vinum detach raid.p0 # vinum detach raid.p0.s0 # vinum detach raid.p0.s1 ..panic.. It seems to be important to remove the last stale subdisk. Bye! Michael Reifenberger Plaut Software GmbH, R/3 Basis To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: PPP problems in -CURRENT
Does anything different happen if you set accmap 000a in your ppp.conf ? If not, you're going to have to approach your ISP and ask them why their ppp implementation is ignoring our requests (which needless to say violates the rfc). > cvsupped, built CURRENT as of April 8th, upgrading a 3.1-STABLE system to > 4.0. A reboot later, all seems fine, except that I'm experiencing severe > problems connecting to my ISP. Everything goes well till after the login > phase, when entering the lcp negotiation phase, then things get FUBARed. > > (passwords have been deliberately blanked, of course. :P) > > I believe that both peers are attempting to negotiate an IP address, but > are failing to do so as shown by the repeated negotiation attempts. The > same PPP configuration file worked as of 24 hours ago on 3.1-STABLE. Any > insight would be greatly appreciated. > > Apr 8 21:15:56 Tasha ppp[294]: Phase: Using interface: tun0 > Apr 8 21:15:56 Tasha ppp[294]: Phase: deflink: Created in closed state > Apr 8 21:15:56 Tasha ppp[294]: tun0: Command: default: set device /dev/cuaa1 > Apr 8 21:15:56 Tasha ppp[294]: tun0: Command: default: set speed 115200 > Apr 8 21:15:56 Tasha ppp[294]: tun0: Command: default: deny lqr > Apr 8 21:15:56 Tasha ppp[294]: tun0: Command: default: set dial ABORT BUSY > ABORT NO\sCARRIER TIMEOUT 5 "" AT > OK-AT-OK ATE1Q0 OK \dATDT\T TIMEOUT 40 CONNECT > Apr 8 21:15:56 Tasha ppp[294]: tun0: Command: default: alias enable yes > Apr 8 21:15:56 Tasha ppp[294]: tun0: Command: pmdemand: set phone xxx > Apr 8 21:15:56 Tasha ppp[294]: tun0: Command: pmdemand: set login ABORT > NO\sCARRIER TIMEOUT 5 ogin:--ogin: > login word: word > Apr 8 21:15:56 Tasha ppp[294]: tun0: Command: pmdemand: set server > > Apr 8 21:15:56 Tasha ppp[294]: tun0: Phase: Listening at port 4040. > Apr 8 21:15:56 Tasha ppp[294]: tun0: Command: pmdemand: set timeout 0 > Apr 8 21:15:56 Tasha ppp[294]: tun0: Command: pmdemand: set ifaddr > 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0 > Apr 8 21:15:56 Tasha ppp[294]: tun0: Command: pmdemand: add default HISADDR > Apr 8 21:15:56 Tasha ppp[295]: tun0: Phase: PPP Started (background mode). > Apr 8 21:15:56 Tasha ppp[295]: tun0: Phase: bundle: Establish > Apr 8 21:15:56 Tasha ppp[295]: tun0: Phase: deflink: closed -> opening > Apr 8 21:15:56 Tasha ppp[295]: tun0: Phase: deflink: Connected! > Apr 8 21:15:56 Tasha ppp[295]: tun0: Phase: deflink: opening -> dial > Apr 8 21:15:56 Tasha ppp[295]: tun0: Phase: Phone: xxx > Apr 8 21:15:56 Tasha ppp[295]: tun0: Chat: deflink: Dial attempt 1 of 1 > Apr 8 21:15:56 Tasha ppp[295]: tun0: Chat: Send: AT^M > Apr 8 21:15:56 Tasha ppp[295]: tun0: Chat: Expect(5): OK > Apr 8 21:15:56 Tasha ppp[295]: tun0: Chat: Received: AT^M^M > Apr 8 21:15:56 Tasha ppp[295]: tun0: Chat: Received: OK^M > Apr 8 21:15:56 Tasha ppp[295]: tun0: Chat: Send: ATE1Q0^M > Apr 8 21:15:56 Tasha ppp[295]: tun0: Chat: Expect(5): OK > Apr 8 21:15:56 Tasha ppp[295]: tun0: Chat: Received: ATE1Q0^M^M > Apr 8 21:15:56 Tasha ppp[295]: tun0: Chat: Received: OK^M > Apr 8 21:15:56 Tasha ppp[295]: tun0: Chat: Send: ATDT^M > Apr 8 21:15:58 Tasha ppp[295]: tun0: Chat: Expect(40): CONNECT > Apr 8 21:16:13 Tasha ppp[295]: tun0: Chat: Received: ATDT^M^M > Apr 8 21:16:13 Tasha ppp[295]: tun0: Chat: Received: CONNECT > 33600/ARQ/V34/LAPM/V42BIS^M > Apr 8 21:16:13 Tasha ppp[295]: tun0: Phase: deflink: dial -> login > Apr 8 21:16:13 Tasha ppp[295]: tun0: Chat: Expect(5): ogin: > Apr 8 21:16:13 Tasha ppp[295]: tun0: Chat: Received: ^M > Apr 8 21:16:13 Tasha ppp[295]: tun0: Chat: Received: login: > Apr 8 21:16:13 Tasha ppp[295]: tun0: Chat: Send: login^M > Apr 8 21:16:13 Tasha ppp[295]: tun0: Chat: Expect(5): word: > Apr 8 21:16:13 Tasha ppp[295]: tun0: Chat: Received: Password: > Apr 8 21:16:13 Tasha ppp[295]: tun0: Chat: Send: password^M > Apr 8 21:16:13 Tasha ppp[295]: tun0: Phase: deflink: login -> lcp > Apr 8 21:16:13 Tasha ppp[295]: tun0: LCP: FSM: Using "deflink" as a > transport > Apr 8 21:16:13 Tasha ppp[295]: tun0: LCP: deflink: State change Initial > --> Closed > Apr 8 21:16:13 Tasha ppp[295]: tun0: LCP: deflink: State change Closed --> > Stopped > Apr 8 21:16:14 Tasha ppp[295]: tun0: LCP: deflink: LayerStart > Apr 8 21:16:14 Tasha ppp[295]: tun0: LCP: deflink: SendConfigReq(1) state > = Stopped > Apr 8 21:16:14 Tasha ppp[295]: tun0: LCP: ACFCOMP[2] > Apr 8 21:16:14 Tasha ppp[295]: tun0: LCP: PROTOCOMP[2] > Apr 8 21:16:14 Tasha ppp[295]: tun0: LCP: ACCMAP[6] 0x > Apr 8 21:16:14 Tasha ppp[295]: tun0: LCP: MRU[4] 1500 > Apr 8 21:16:14 Tasha ppp[295]: tun0: LCP: MAGICNUM[6] 0x49e522ff > Apr 8 21:16:14 Tasha ppp[295]: tun0: LCP: deflink: State change Stopped > --> Req-Sent > Apr 8 21:16:16 Tasha ppp[295]: tun0: LCP: deflink: RecvConfigReq(6) state > = Req-Sent > Apr 8 21:16:16 Tasha ppp[295]: tun0: LCP: ACCMAP[6] 0x000a
Re: EGCS troubles
At 09:37 AM 4/9/99 -0700, David O'Brien wrote: The Only way I could get Jade to work with the new compiler was with CFLAGS= -O -pipe That is not so bad. Before EGCS, we would state that "-O" is the only optimization that is know to always work and what we tell people to use. Mike Smith has written about this many times in Hackers and Current. mysql322 from ports is another one, if you try and compile it with the stock -O -pipe it builds up till almost the end but when it gets to sql.yacc.cc the machine just hangs there and finally dies (no input or output). I have to go into the debugger and reboot. But if you add -fno-exceptions it builds fine.It's taken a couple of days but I've weeded out all of the programs that depended on old gcc libs and rebuilt them. Manfred = ||man...@pacbell.net || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: integer divide fault with vinum
[Format recovered--see http://www.lemis.com/email/email-format.html] On Saturday, 10 April 1999 at 3:37:47 +0200, Michael Reifenberger wrote: > On Sat, 10 Apr 1999, Greg Lehey wrote: > ... >> You need to configure it. Use disklabel -e. > > No, they where configured. > I have one ' d: 17848151 63 vinum' slice per drive. It looks like you have them now, but you didn't then. > The only fault where the misspelling of 'stripe' versus 'striped' in > the configfile! That's not what your error messages are trying to tell you. >>> (Ok, after repairing 'striped' in x) >>> # vinum create x >>> Configuration summary >>> >>> Drives: 0 (4 configured) >>> Volumes:2 (4 configured) >>> Plexes: 1 (8 configured) >>> Subdisks: 2 (16 configured) >>> >>> >>> V raid State: down Plexes: 1 Size:100 MB >>> >>> P raid.p0 S State: down Subdisks: 2 Size:100 MB >>> >>> S raid.p0.s0State: stalePO:0 B Size: 50 MB >>> S raid.p0.s1State: stalePO: 256 kB Size: 50 MB >>> (Hmm, stale sigh. The vinum(8) GOTCHAS 2. is not explicit about my >>> situation. >> >> Well, I would have thought that the fact you have no drives would give >> you something to think about. > > Hmm, strange - see my above comment regarding the drive configuration. Nope, the error messages are clear. > The same disks, the same configfile (but with proper spelled 'striped': > > # cat x > drive d1 device /dev/da1d > drive d2 device /dev/da2d > volume raid > plex org striped 256k > sd length 50m drive d1 > sd length 50m drive d2 > # vinum create x > Configuration summary > > Drives: 2 (4 configured) This isn't what you had last time > Volumes:1 (4 configured) > Plexes: 1 (8 configured) > Subdisks: 2 (16 configured) > > D d1State: up Device /dev/da1dAvail: > 8664/8714 MB (99%) > D d2State: up Device /dev/da2dAvail: > 8664/8714 MB (99%) > > V raid State: up Plexes: 1 Size:100 MB > > P raid.p0 S State: up Subdisks: 2 Size:100 MB > > S raid.p0.s0State: up PO:0 B Size: 50 MB > S raid.p0.s1State: up PO: 256 kB Size: 50 MB > > The panic occurs only, if I first use the incorrect config file with > 'stripe', then the corrected one with 'striped' and then detaching > the plex and the subdisks. > BTW: It should'n panic in any case. Of course not. >> Well, you could RTFM, in this case vinum(4). It tells you in some >> detail what to do if you have a panic. The stack trace you have there > I haven't set up remote debugging. > > Sorry, its behind a firewall which I can't manipulate and it blocks > telnet and ssh at the moment. Well, then at least you could do what I explain in vinum(4). > But I'm shure you can reproduce the panic by following the steps I > have taken. Possibly. I'll try it. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: integer divide fault with vinum
On Sat, 10 Apr 1999, Greg Lehey wrote: ... > You need to configure it. Use disklabel -e. No, they where configured. I have one ' d: 17848151 63 vinum' slice per drive. The only fault where the misspelling of 'stripe' versus 'striped' in the configfile! ... > Not much of anything, in fact. > > > (Ok, after repairing 'striped' in x) > > # vinum create x > > Configuration summary > > > > Drives: 0 (4 configured) > > Volumes:2 (4 configured) > > Plexes: 1 (8 configured) > > Subdisks: 2 (16 configured) > > > > > > V raid State: down Plexes: 1 Size:100 MB > > > > P raid.p0 S State: down Subdisks: 2 Size:100 MB > > > > S raid.p0.s0State: stalePO:0 B Size: 50 MB > > S raid.p0.s1State: stalePO: 256 kB Size: 50 MB > > (Hmm, stale sigh. The vinum(8) GOTCHAS 2. is not explicit about my > > situation. > > Well, I would have thought that the fact you have no drives would give > you something to think about. Hmm, strange - see my above comment regarding the drive configuration. The same disks, the same configfile (but with proper spelled 'striped': # cat x drive d1 device /dev/da1d drive d2 device /dev/da2d volume raid plex org striped 256k sd length 50m drive d1 sd length 50m drive d2 # vinum create x Configuration summary Drives: 2 (4 configured) Volumes:1 (4 configured) Plexes: 1 (8 configured) Subdisks: 2 (16 configured) D d1State: up Device /dev/da1dAvail: 8664/8714 MB (99%) D d2State: up Device /dev/da2dAvail: 8664/8714 MB (99%) V raid State: up Plexes: 1 Size:100 MB P raid.p0 S State: up Subdisks: 2 Size:100 MB S raid.p0.s0State: up PO:0 B Size: 50 MB S raid.p0.s1State: up PO: 256 kB Size: 50 MB The panic occurs only, if I first use the incorrect config file with 'stripe', then the corrected one with 'striped' and then detaching the plex and the subdisks. BTW: It should'n panic in any case. ... > Well, you could RTFM, in this case vinum(4). It tells you in some > detail what to do if you have a panic. The stack trace you have there I haven't set up remote debugging. Sorry, its behind a firewall which I can't manipulate and it blocks telnet and ssh at the moment. But I'm shure you can reproduce the panic by following the steps I have taken. Bye! Michael Reifenberger Plaut Software GmbH, R/3 Basis To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
On Fri, 9 Apr 1999 p...@phoenix.volant.org wrote:
> > I always thought the criteria for inclusion of things into the base
> > system was:
> >
> > 1. Needed for 'make world';
> > 2. Needed to get a basic functioning server up and running;
> > 3. Something usefull only within FreeBSD (like the kernel ;), or
> > 4. Can't be effectively built outside of /usr/src.
> >
> > If {g77|f77} can be built as a port, using the system EGCS, then to
> > port's it goes. Otherwise why don't we include the Top 20 ports, or
> > maybe the Top 25, or...
>
> The criteria for adding something to the base system is different
> than the criteria for removing something from it. In both cases,
> it requires compelling reasons to change the status quo.
>
> Replacing an existing component is somewhat easier, particularly
> if backwards compatability is retained. I may be mistaken, but I
> believe the current discussion is whether or not to replace f77
> with g77.
Didn't we just have this discussion a few months ago???
just put it in the tree already ;)
rob
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users
Dmitry Valdov wrote: > Is there Any way to fix it? Yes. Limit the number of processes they can have in /etc/login.conf. If they've already done it once, appropriate use of a baseball bat may make them think twice about doing it again. -- Ben Smithurst b...@scientia.demon.co.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: integer divide fault with vinum
On Friday, 9 April 1999 at 15:01:51 +0200, Michael Reifenberger wrote:
> Hi,
> next try.
> Please forgive if gets too stupid :-)
>
> # cat x
> drive d1 device /dev/da1d
> drive d2 device /dev/da2d
> volume raid
> plex org stripe 256k
> sd length 50m drive d1
> sd length 50m drive d2
> (please note again the misspelling of striped)
> # vinum create x
>1: drive d1 device /dev/da1d
> ** 1 Can't initialize drive d1: Device not configured
You need to configure it. Use disklabel -e.
>2: drive d2 device /dev/da2d
> ** 2 Can't initialize drive d2: Device not configured
>4: plex org stripe 256k
> ** 4 Invalid plex organization: Invalid argument
As advertised. But this isn't your primary fault, it's the one above.
>5: sd length 50m drive d1
> ** 5 Unnamed sd is not associated with a plex: Invalid argument
Since you don't have a plex, you don't have a subdisk.
>6: sd length 50m drive d2
> ** 6 Unnamed sd is not associated with a plex: Invalid argument
> Configuration summary
>
> Drives: 0 (4 configured)
> Volumes:1 (4 configured)
> Plexes: 0 (8 configured)
> Subdisks: 0 (16 configured)
>
>
> V raid State: down Plexes: 0 Size: 0 B
> (juppie no panic!)
Not much of anything, in fact.
> (Ok, after repairing 'striped' in x)
> # vinum create x
> Configuration summary
>
> Drives: 0 (4 configured)
> Volumes:2 (4 configured)
> Plexes: 1 (8 configured)
> Subdisks: 2 (16 configured)
>
>
> V raid State: down Plexes: 1 Size:100 MB
>
> P raid.p0 S State: down Subdisks: 2 Size:100 MB
>
> S raid.p0.s0State: stalePO:0 B Size: 50 MB
> S raid.p0.s1State: stalePO: 256 kB Size: 50 MB
> (Hmm, stale sigh. The vinum(8) GOTCHAS 2. is not explicit about my
> situation.
Well, I would have thought that the fact you have no drives would give
you something to think about.
> this time, no `vinum resetconfig`, so:)
>
> # vinum detach raid.p0
> # vinum detach raid.p0.s0
> # vinum detach raid.p0.s1
>
> (Maybe this was too stupid and I get a deserved:)
> ..panic..
>
> IdlePTD 3686400
> initial pcb at 2f747c
> panicstr: integer divide fault
> panic messages:
> ---
> Fatal trap 18: integer divide fault while in kernel mode
> instruction pointer = 0x8:0xc0283b27
> stack pointer = 0x10:0xc377cc64
> frame pointer = 0x10:0xc377ccd8
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 330 (vinum)
> interrupt mask =
> trap number = 18
> panic: integer divide fault
>
> syncing disks... 3 3 done
>
> running gdb post mortem:
>
> #0 boot (howto=256) at ../../kern/kern_shutdown.c:287
> #1 0xc016e6f5 in panic (fmt=0xc02c9ea9 "integer divide fault")
> at ../../kern/kern_shutdown.c:448
> #2 0xc025a8ce in trap_fatal (frame=0xc377cc28, eva=0)
> at ../../i386/i386/trap.c:943
> #3 0xc025a32c in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 0,
> tf_esi = 102400, tf_ebp = -1015558952, tf_isp = -1015559088, tf_ebx = 0,
> tf_edx = 0, tf_ecx = 102400, tf_eax = 1, tf_trapno = 18, tf_err = 0,
> tf_eip = -1071105241, tf_cs = 8, tf_eflags = 66118, tf_esp = 0,
> tf_ss = -1065135960}) at ../../i386/i386/trap.c:586
> #4 0xc0283b27 in __qdivrem (uq=102400, vq=0, arq=0xc377ccf4)
> at ../../libkern/qdivrem.c:100
> #5 0xc028496f in __umoddi3 (a=102400, b=0) at ../../libkern/umoddi3.c:51
> #6 0xc0842fe6 in ?? ()
> #7 0xc0848dc4 in ?? ()
> #8 0xc0848528 in ?? ()
> #9 0xc01a0567 in spec_ioctl (ap=0xc377ce0c)
> at ../../miscfs/specfs/spec_vnops.c:440
> #10 0xc019fe79 in spec_vnoperate (ap=0xc377ce0c)
> at ../../miscfs/specfs/spec_vnops.c:129
> #11 0xc02309a9 in ufs_vnoperatespec (ap=0xc377ce0c)
> at ../../ufs/ufs/ufs_vnops.c:2327
> #12 0xc019aae5 in vn_ioctl (fp=0xc0811040, com=3223602776,
> data=0xc377ced0 "\001", p=0xc352b780) at vnode_if.h:395
> #13 0xc017a114 in ioctl (p=0xc352b780, uap=0xc377cf84)
> at ../../kern/sys_generic.c:564
> #14 0xc025ab17 in syscall (frame={tf_es = 47, tf_ds = 47,
> tf_edi = -1077945576, tf_esi = 1, tf_ebp = -1077945696,
> tf_isp = -1015558188, tf_ebx = -1077945732, tf_edx = 0,
> tf_ecx = 134781696, tf_eax = 54, tf_trapno = 12, tf_err = 2,
> tf_eip = 134619728, tf_cs = 31, tf_eflags = 663, tf_esp = -1077945760,
> tf_ss = 47}) at ../../i386/i386/trap.c:1101
> #15 0xc024f20c in Xint0x80_syscall ()
> #16 0x80483d1 in ?? ()
> #17 0x8048295 in ?? ()
> #18 0x80480ec in ?? ()
>
> Anything else I can do or inspect?
Well, you could RTFM, in this case vinum(4). It tells you in some
detail what to do if you have a panic. The stack trace you have there
doesn't help. If you give me (root) access to your machine,
Re: Panic: Invalid longjmp with vinum configured by novice
On Friday, 9 April 1999 at 21:59:57 +0200, Michael Reifenberger wrote: > On Fri, 9 Apr 1999, Jacques Vidrine wrote: > >> Date: Fri, 09 Apr 1999 12:30:41 -0500 >> From: Jacques Vidrine >> To: Michael Reifenberger >> Cc: Greg Lehey , FreeBSD-Current >> Subject: Re: Panic: Invalid longjmp with vinum configured by novice >> >> On 9 April 1999 at 11:31, Michael Reifenberger wrote: >> [snip] But vinum(8) doesn't offer you much in the way of editing facilities either. >>> A command history and commandline editing :-) >> >> Use ile in ports/misc/lile [sic], e.g. ``ile vinum'' > > No, vinum has allready a command history which makes it superior over `ed`. You can't go back a line with vinum. Once you've entered it, it gets processed. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users
On Fri, Apr 9, 1999, Dmitry Valdov wrote: > Hi! > > Try it: > > cat > qqq > echo $$ > echo ~/qqq|~/qqq|~/qqq|~/qqq|~/qqq > > Ctrl-D > > ./qqq > > Is there Any way to fix it? You typically want to set a restriction as to how many processes a user can spawn. This is done by editing /etc/login.conf and changing the user's login class, see the man page for 'login.conf'. > > Dmitry. > Followups set to -questions. > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > -- = * "This process can check if this value is * * zero, and if it is, it does something* * child-like." -Forbes Burkowski, CS 454 * = To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: 990409 make world fail & more
> After cvsupping a couple of times make world still fails at : ..snip.. BDE fixed this in rev 1.25 of src/gnu/usr.bin/cc/cc_tools/Makefile. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Make world is broken for days now... :(
> > I have *NO* idea where you are getting this from. > > I bet he ran ./configure in contrib/egcs at some point in the past. I think I'll commit a change to ./configure so that it tells the person the right thing to do. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Make world is broken for days now... :(
In article <19990409111621.a24...@nuxi.com>, David O'Brien wrote: > > Everytime I try to make world, I get the following: > ..snip.. > > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/tm.h:3: > > linux.h: No such file or directory > > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/tm.h:4: > > i386/freebsd-elf.h: No such file or directory > > Something is seriously wrong with your CVSup'ing. I have never committed > (to the main source tree) any reference to linux.h and freebsd-elf.h. > > I have *NO* idea where you are getting this from. I bet he ran ./configure in contrib/egcs at some point in the past. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ports dependencies
On Thu, 08 Apr 1999 19:10:18 MST, Satoshi - the Ports Wraith - Asami wrote: > People, I know you are annoyed by many stupid things software authors > have done in the past to make your life miserable Actually, the only thing having any negative impact on my life right now is the lengthy discussion on port dependencies that's taking place on the freebsd-current mailing list. :-P Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Confused about egcs and c++
In message Chuck Robey writes: : Keep recompiling, Warner, it does work. Yup. My build world just finished, and now it works. Yippie! Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: msdosfs problems?
On Fri, 9 Apr 1999, Alex Zepeda wrote: > On Fri, 9 Apr 1999, Doug White wrote: > > > mpg123 is an ancient player. It won't play most newer MP3s. Use a newer > > player, like x11amp or xaudio. > > It's not mpg123. There were some files that never caused a problem with > the same version of mpg123 before. And besides, x11amp is based on mpg123 > isn't it? No. How does xaudio react? I don't buy that it's a FS-related difficulty; you can play MP3s over NFS without trouble. > That still doesn't explain how it would cause my system to hang. > Grr. Back to CDs it is. Sound system problem? Doug White Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
3.1 stable bootloader vs. 4.0 kernel...
Did I miss something obvious here? I have a system over in England somewhere which I'm remotely booting. It's 3.1Stable. When I try and put a 4.0/-current kernel (which boots fine on *my* much overwritten and not reinstalled since 2.2.2 system), I get: Type '?' for a list of commands, 'help' for more detailed help. disk1s1a:> boot kernel.tst /kernel.tst text=0x1a312e elf_loadexec: archsw.readin failed can't load module '/kernel.tst': input/output error Eh? -matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DoS from local users
> Hi! > Try it: > > cat > qqq > echo $$ > echo ~/qqq|~/qqq|~/qqq|~/qqq|~/qqq > > Ctrl-D > > ./qqq > > Is there Any way to fix it? > > Dmitry. > % cat > qqq echo $$ echo ~/qqq|~/qqq|~/qqq|~/qqq|~/qqq % ./qqq ./qqq: Permission denied. % & what fix? Rgdz, Osokin Sergey aka oZZ, o...@etrust.ru To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Panic: Invalid longjmp with vinum configured by novice
On Fri, 9 Apr 1999, Jacques Vidrine wrote: > Date: Fri, 09 Apr 1999 12:30:41 -0500 > From: Jacques Vidrine > To: Michael Reifenberger > Cc: Greg Lehey , FreeBSD-Current > Subject: Re: Panic: Invalid longjmp with vinum configured by novice > > On 9 April 1999 at 11:31, Michael Reifenberger wrote: > [snip] > > > But vinum(8) doesn't offer > > > you much in the way of editing facilities either. > > A command history and commandline editing :-) > > Use ile in ports/misc/lile [sic], e.g. ``ile vinum'' No, vinum has allready a command history which makes it superior over `ed`. Bye! Michael Reifenberger Plaut Software GmbH, R/3 Basis To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Confused about egcs and c++
On Fri, 9 Apr 1999, Warner Losh wrote: > > OK. I've done two make worlds. One on April 2 or 3 and One on April > 8th. I'm still getting the C++ error for simple C++ programs. Do I > need to do yet another one to fix the problem? I'm doing one anyway, > but am confused because I thought this had been fixed (or would be > fixed by two build worlds). I had to do two build/installworlds before the simple C++ progs worked right, and then I had to dive in and check that any libs that linked in libstdc++.so.2 got relinked, so that they used libstdc++.so.3 instead. This killed some unobvious things, like the kde apps which used converters/kdeutils, which has a libQwSpriteField, which itself linked in libstdc++.so.2, which caused some progs to link BOTH versions 2 and 3 (fatal and unobvious problem). Keep recompiling, Warner, it does work. > > Warner > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: emacs* broken in -current (was Re: Vtable thunks with egcs)
On 9 Apr 1999, Joel Ray Holveck wrote: # > I've found where this problem is coming from. It's in # > emacs20.3/src/s/freebsd.h. It sets a macro called BSD_SYSTEM based upon the # > version number contained in __FreeBSD__, checking for 1, 2 and 3. Of # > course, -current uses 4. I have found that you can check for __FreeBSD__ >= # > 3, and it will work, but this feels a bit like a hack. I've never updated a # > port, so I can either get some instruction from someone to put in a patch, # > or let someone else do it. # # I'll make the patch if a committer can get it in. Send it to me. I'll commit it. :) BTW, good catch David! -steve # -- # Joel Ray Holveck - jo...@gnu.org #Fourth law of programming: #Anything that can go wrong wi # sendmail: segmentation violation - core dumped # To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
latest make world problem
This is the latest error that I get with make world cvsupped about an hour ago: /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c: In fu nction `type_from_format': /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c:87: `F ATAL_EXIT_CODE' undeclared (first use this function) /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c:87: (E ach undeclared identifier is reported only once /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c:87: fo r each function it appears in.) /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c: In fu nction `accessor_from_format': /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c:113: ` FATAL_EXIT_CODE' undeclared (first use this function) *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
On Fri, Apr 09, 1999 at 03:52:58PM +0200, Jeremy Lea wrote:
> Hi,
>
> On Fri, Apr 09, 1999 at 10:37:55AM -0300, The Hermit Hacker wrote:
> > Geez, and I used to think it was only the commercial OSs that had a
> > problem with bloat and creeping featurisms ... :( Chuck's idea makes more
> > sense...how many programs does the average system run that needs a fortran
> > compiler? *raised eyebrow*
>
> I always thought the criteria for inclusion of things into the base
> system was:
>
> 1. Needed for 'make world';
> 2. Needed to get a basic functioning server up and running;
> 3. Something usefull only within FreeBSD (like the kernel ;), or
> 4. Can't be effectively built outside of /usr/src.
>
> If {g77|f77} can be built as a port, using the system EGCS, then to
> port's it goes. Otherwise why don't we include the Top 20 ports, or
> maybe the Top 25, or...
>
> Regards,
> -Jeremy
First off, g77 is not your typical port. The build of g77 depends on
having the source to gcc on your system. The last time I checked,
installing the source was optional. The reason the current port of g77
is marked broken is because of this.
History: Newer versions of g77 cannot be built against gcc 2.7.2 and
older versions that can be built against gcc 2.7.2 don't work with
FreeBSD. This is because the FreeBSD gcc 2.7.2 was hacked too far away
from what g77 was developed for.
I would expect to see the same type of scenario arise with egcs as the
FreeBSD version becomes significantly changed from stock egcs. David has
already said that "ports/egcs != src/contrib/egcs".
Future: Now it may be true that newer versions of g77 may not build
against whatever version of egcs we have but at least we would be
guaranteed of having a functional Fortran compiler.
Many people don't seem to understand that FreeBSD can be used for
workstations as well as servers and Fortran is *essential* on a
scientific/engineering workstation. I don't doubt that there are more
people using FreeBSD as a server but that doesn't mean that workstation
users should be denied an essential tool because it takes up a few
hundred kilobytes. I would predict that with SGI's entry into the NT
market you will see more people looking at "Unix on Intel" to replace
their aging SGI Irix boxes. It would be a shame for them to choose
Linux over FreeBSD because Linux can compile their Fortran programs and
FreeBSD cannot.
--
Glenn Johnson
Technician
USDA, ARS, SRRC
New Orleans, LA
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
On Fri, 9 Apr 1999, Thomas David Rivers wrote: > > Geez, and I used to think it was only the commercial OSs that had a > > problem with bloat and creeping featurisms ... :( Chuck's idea makes more > > sense...how many programs does the average system run that needs a fortran > > compiler? *raised eyebrow* > > Personally, I'm not sure g77 is needed, but let me play devil's > advocate here and turn your question around: > > "How many programs does the average system not run because >the system doesn't have a FORTRAN compiler?" > > That seems to be a more pertinent question... and - a good bit > more difficult to answer. Not as hard as all that. Just go about compiling from ports/math, and notice how many programs use f2c. Some also from graphics, and from others. Especially when you consider the low cost in terms of source size and executeable size, getting rid of fortran, or not allowing the upgraded fortran, it just doesn't make sense. We have NO_SENDMAIL now as a precedent, we just need NO_FORTRAN and NO_GCJ. This is very, very doable, and can only make FreeBSD look better. OTOH, as Jordan pointed out, maybe we need a *little* more experience with gcj, but fortran, it's ready *now*. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
David O'Brien wrote:
> > Speaking of ports, I have a working port of f2c and a new
> > f77(1) wrapper sitting on my machine.
>
> I guess naming is going to get sticky here... if f2c has `f77', then *if*
> I put egcs/g77 in the main tree, do I install it as `g77' or `f77'?
>
> The Egcs port installs it as `g77'... and what if someone makes some port
> of an updated g77?
>
I would expect that you'll want to have a symlink from f77 to
g77 in /usr/bin. If g77 includes a man page, you'll also want
a symlink from f77.1 to g77.1.
In the Makefile for the port of my f77 wrapper I have:
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/f77 ${PREFIX}/bin
${INSTALL_MAN} ${WRKSRC}/f77.1 ${PREFIX}/man/man1
This could be changed to:
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/f77 ${PREFIX}/bin/${F77NAME}
${INSTALL_MAN} ${WRKSRC}/f77.1 ${PREFIX}/man/man1/${F77NAME}.1
where F77NAME would default to fc. Why fc? Because, f2c provides
an old Bourne shell script of the same name.
--
Steve
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Make world is broken for days now... :(
In article <370df25c.9ae69...@ein-hashofet.co.il>, Gilad Rom wrote: > Hello, > > For the past week, I've been trying to build world, in order to > get then new egcs up and running. > > Everytime I try to make world, I get the following: > > ===> cc_tools > cc -O > -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/objc > -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc > -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/config > -DFREEBSD_NATIVE -DDEFAULT_TARGET_VERSION=\"egcs-2.91.66\" > -DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" > -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools > -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -c > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c > > In file included from > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/config/i386/xm-i386.h:43, > from > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/hconfig.h:2, > from > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c:22: > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/tm.h:3: > linux.h: No such file or directory > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/tm.h:4: > i386/freebsd-elf.h: No such file or directory > *** Error code 1 Your sources are unclean. The files "hconfig.h" and "tm.h" should not exist in "src/contrib/egcs/gcc". You must have run ./configure in there at some point (don't do that). I recommend that you delete "src/contrib/egcs" and fetch a fresh copy of it. Or, if there is a Makefile in there too, you could try running "make distclean" to see if that solves the problem. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: make world breakage?!?
In article , Brian Feldman wrote: > Am I the only one to get this error?? > cc -nostdinc -O -pipe -I/usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd > -I. -I/usr/src/usr.sbin/amd/amd -I/usr/src/usr.sbin/amd/amd/../include > -I/usr/src/usr.sbin/amd/amd/../../../contrib/amd/include > -I/usr/src/usr.sbin/amd/amd/../../../contrib/amd -DHAVE_CONFIG_H > -I/usr/obj/usr/src/tmp/usr/include -c > /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c > /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c:66: redefinition > of `struct callout' > *** Error code 1 > > Stop. > > It's been like this here for days, and noone's reported it. I've been doing a lot of make worlds the past few days, and I haven't run into it. It didn't appear in the make world I did last night. Have you tried "make cleandir; make cleandir" (yes, twice) in "src/usr.sbin/amd"? If you have, I can only suggest that you wipe out the amd trees in both contrib and usr.sbin, grab fresh sources, and try again. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: -soname and shared libs (was Re: /sys/boot, egcs vs. gcc, -Os)
On Fri, 9 Apr 1999, Mikhail Teterin wrote: > This is a good knews. Does this mean, I can drop-in some GTk library > and make libXaw.so a symlink to it? This would only support my > point... That's like trying to replace libz with libc. Did you notice what I said about the themes? > But in any case, the drop-in replacement is one of the promises shared > libraries pledge to deliver and do indeed deliver quite often. Using > smth like -soname _may_ break this, if the run-time linker will refuse > to use a different version of a library even if I want it to. Drop in replacements are perhaps a promise to you, but hardly a guarantee. The reason shared lib numbers were bumped up (or this was proposed anyways) was because of source and binary incompatable changes being made. Leaving the version number the same would introduce problems. Nothing's stopping you from creating a replacement for an older version of Gtk+ or symlinking a specific version of Gtk+ to another library. Besides why whine hopelessly about something I'm sure you're never going to do? Think about all the other things that shared libs provide, like a reduction in disk and memory usage. Exhale once in a while. It helps. - alex To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
> I'd like to voice my opposition to this. While it maybe an acceptable > way to work around poor (or non-existant) release engineering of SOME > software, making this a rule may defeat one of the major purposes of > shared libraries: drop-in replacement. Think of libXaw3d, for example. > What's wrong with different filenames for different libs? Do you think that the Gnome libs are going to stand still long enough for someone (you) to write a drop in replacement? Besides, most of the functionality that libXaw3d provides over libXaw is provided by Gtk+ themes. - alex To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: msdosfs problems?
On Fri, 9 Apr 1999, Doug White wrote: > mpg123 is an ancient player. It won't play most newer MP3s. Use a newer > player, like x11amp or xaudio. It's not mpg123. There were some files that never caused a problem with the same version of mpg123 before. And besides, x11amp is based on mpg123 isn't it? That still doesn't explain how it would cause my system to hang. Grr. Back to CDs it is. - alex To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: EGCS troubles
At 09:58 AM 4/9/99 +0300, Maxim Sobolev wrote: > Compile Jade with "-g" and see where in the coredump the signal 11 is > occuring. What does ``ldd jade'' show? You might be mixing shared libs, > that doesn't work for C++. Could also be an exceptions problem. Try > compiling with -fnoexpcetions. [asmo...@daemon] (163) $ ldd /usr/local/bin/jade /usr/local/bin/jade: libstyle.so.1 => /usr/local/lib/libstyle.so.1 (0x280b6000) libspgrove.so.1 => /usr/local/lib/libspgrove.so.1 (0x282ac000) libgrove.so.1 => /usr/local/lib/libgrove.so.1 (0x282ef000) libsp.so.1 => /usr/local/lib/libsp.so.1 (0x282f7000) libintl.so.1 => /usr/local/lib/libintl.so.1 (0x284ce000) libstdc++.so.3 => /usr/lib/libstdc++.so.3 (0x284d2000) libm.so.2 => /usr/lib/libm.so.2 (0x2850d000) libc.so.3 => /usr/lib/libc.so.3 (0x28527000) I know for certain that libintl is gcc. Will go and do recompilations of all stuff this weekend *sigh* ;) In my case (it seems all libs compiled under egcs - exactly when jade compiled): /usr/local/bin/jade: libstyle.so.1 => /usr/local/lib/libstyle.so.1 (0x280b9000) libspgrove.so.1 => /usr/local/lib/libspgrove.so.1 (0x282b6000) libgrove.so.1 => /usr/local/lib/libgrove.so.1 (0x282f9000) libsp.so.1 => /usr/local/lib/libsp.so.1 (0x28301000) libstdc++.so.3 => /usr/lib/libstdc++.so.3 (0x284e4000) libm.so.2 => /usr/lib/libm.so.2 (0x28521000) libc.so.3 => /usr/lib/libc.so.3 (0x2853c000) The Only way I could get Jade to work with the new compiler was with CFLAGS= -O -pipe The only way I have tested it is by building the Handbook -O2 -pipe built ,but Signal 11 -O2 -fno-exceptions won't build Manfred = ||man...@pacbell.net || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: building world
> In gnu/usr.bin/cc mine fails as well, but complains of a missing > `hconfig.h`, which in turn causes a screenfull of errrors. cd /usr/src make cleandir ; make cleandir then build your world normally and tell me if you still have the error. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: building world
> gnu/usr.bin/cc mine fails as well, but complains of a missing > `hconfig.h`, which in turn causes a screenfull of errrors. Two days ago I know you've heard this before WRT to cc_tools/, but... is should be fixed now. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: EGCS troubles
> The Only way I could get Jade to work with the new compiler > was with CFLAGS= -O -pipe That is not so bad. Before EGCS, we would state that "-O" is the only optimization that is know to always work and what we tell people to use. Mike Smith has written about this many times in Hackers and Current. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Make world is broken for days now... :(
> Everytime I try to make world, I get the following: ..snip.. > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/tm.h:3: > linux.h: No such file or directory > /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/tm.h:4: > i386/freebsd-elf.h: No such file or directory Something is seriously wrong with your CVSup'ing. I have never committed (to the main source tree) any reference to linux.h and freebsd-elf.h. I have *NO* idea where you are getting this from. What is the revision of /usr/src/gnu/usr.bin/cc/cc_tools/Makefile? Can you send it to me? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: -soname and shared libs (was Re: /sys/boot, egcs vs. gcc, -Os)
Alex Zepeda once wrote: > > This is a good knews. Does this mean, I can drop-in some GTk library > > and make libXaw.so a symlink to it? This would only support my > > point... > That's like trying to replace libz with libc. Did you notice what I > said about the themes? I noticed, that you discarded my example of a useful drop-in replacement of shared libXaw.so with libXaw3d.so, saying: az: Besides, most of the functionality that libXaw3d az: provides over libXaw is provided by Gtk+ themes. This lead me to conclude, you are aware of some other drop-in replacement for libXaw. > > But in any case, the drop-in replacement is one of the promises > > shared libraries pledge to deliver and do indeed deliver quite > > often. Using smth like -soname _may_ break this, if the run-time > > linker will refuse to use a different version of a library even if I > > want it to. > Drop in replacements are perhaps a promise to you, but hardly a > guarantee. I resent the personal reference here. > The reason shared lib numbers were bumped up (or this was proposed > anyways) was because of source and binary incompatable changes being > made. Leaving the version number the same would introduce problems. I have no objections whatsoever to changes to shared lib numbers. I oppose to storing the information _in the binary_ and _relying on it_. The initial post I responded to, did not suggest such reliance outside of resolving interports' dependencies, but I'm afraid we may end up using it in the run-time linker. > Nothing's stopping you from creating a replacement for an older > version of Gtk+ or symlinking a specific version of Gtk+ to another > library. Nothing currently does, indeed. > Besides why whine hopelessly about something I'm sure you're never > going to do? Think about all the other things that shared libs > provide, like a reduction in disk and memory usage. As I mentioned, I'm using libXaw3d instead of libXaw on all of my machines. I also like NOT having to rebuild my little programs when I install new TCL libraries. I'm glad I do not have to recompile tcsh (and lots of other things) when I upgrade FreeBSD. Reduction in disk and memory usage is indeed _another_ promise shared libraries deliver... But it is NOT the one I was talking about. > Exhale once in a while. It helps. Yeah, right, will you shave your back then? I asked you privately to change your tone and attitude, and to apologise. You refused. This would be my last response to you on this subject (probably on other subjects too). -mi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
-soname and shared libs (was Re: /sys/boot, egcs vs. gcc, -Os)
Alex Zepeda once wrote: > > I'd like to voice my opposition to this. While it maybe an ^ > > acceptable way to work around poor (or non-existant) release > > engineering of SOME software, making this a rule may defeat one of > > the major purposes of shared libraries: drop-in replacement. Think > > of libXaw3d, for example. What's wrong with different filenames for > > different libs? > Do you think that the Gnome libs are going to stand still long enough > for someone (you) to write a drop in replacement? See the the underlined part for reflection of my view on dealing with SOME software (Gnome). > Besides, most of the functionality that libXaw3d provides over libXaw > is provided by Gtk+ themes. This is a good knews. Does this mean, I can drop-in some GTk library and make libXaw.so a symlink to it? This would only support my point... But in any case, the drop-in replacement is one of the promises shared libraries pledge to deliver and do indeed deliver quite often. Using smth like -soname _may_ break this, if the run-time linker will refuse to use a different version of a library even if I want it to. -mi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
Jeremy Lea once wrote: > 3. GNOME problems. > a. GNOME has no release engineering. The libraries break APIs for > every pico number bump just about. Or they fix bugs and remove > workarounds at higher levels. Also ESR's $%^*@ advice of release > early and release often means that they often manage three > releases in a 48 hour period. [...] > 1. Use -soname for binaries. Add this to $LDFLAGS or something, to get > a version number installed into a binary then create extra magic or > a script to test this in the DEPENDS. I don't know if this is > possible, but there must be some field available which can be got > with either file(1) or objdump(1). Same idea for scripts. I'd like to voice my opposition to this. While it maybe an acceptable way to work around poor (or non-existant) release engineering of SOME software, making this a rule may defeat one of the major purposes of shared libraries: drop-in replacement. Think of libXaw3d, for example. What's wrong with different filenames for different libs? -mi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
DoS from local users
Hi! Try it: cat > qqq echo $$ echo ~/qqq|~/qqq|~/qqq|~/qqq|~/qqq Ctrl-D ./qqq Is there Any way to fix it? Dmitry. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
> I always thought the criteria for inclusion of things into the base
> system was:
>
> 1. Needed for 'make world';
> 2. Needed to get a basic functioning server up and running;
> 3. Something usefull only within FreeBSD (like the kernel ;), or
> 4. Can't be effectively built outside of /usr/src.
>
> If {g77|f77} can be built as a port, using the system EGCS, then to
> port's it goes. Otherwise why don't we include the Top 20 ports, or
> maybe the Top 25, or...
The criteria for adding something to the base system is different
than the criteria for removing something from it. In both cases,
it requires compelling reasons to change the status quo.
Replacing an existing component is somewhat easier, particularly
if backwards compatability is retained. I may be mistaken, but I
believe the current discussion is whether or not to replace f77
with g77.
-Pat
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
990409 make world fail & more
After cvsupping a couple of times make world still fails at : ===> c++filt rm -f .depend /usr/obj/usr/src/gnu/usr.bin/cc/c++filt/GPATH /usr/obj/usr/src/gnu/usr.bin/cc/c++filt/GRTAGS /usr/obj/usr/src/gnu/usr.bin/cc/c++filt/GSYMS /usr/obj/usr/src/gnu/usr.bin/cc/c++filt/GTAGS ===> cc_tools cc -O -pipe -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/objc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/config -DFREEBSD_NATIVE -DDEFAULT_TARGET_VERSION=\"egcs-2.91.66\" -DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c:22 : hconfig.h: No such file or directory In file included from /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c:23: /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/system.h:235: conflicting types for `sys_errlist' /usr/obj/usr/src/tmp/usr/include/stdio.h:225: previous declaration of `sys_errlist' In file included from /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c:30: /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/rtl.h:931: warning: `enum reg_class' declared inside parameter list /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/rtl.h:931: warning: its scope is only this definition or declaration, /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/rtl.h:931: warning: which is probably not what you want. /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/rtl.h:931: warning: parameter has incomplete type /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/rtl.h:1369: warning: parameter has incomplete type /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/rtl.h:1443: warning: parameter has incomplete type /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/rtl.h:1443: warning: parameter has incomplete type /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/rtl.h:1444: warning: parameter has incomplete type /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/rtl.h:1444: warning: parameter has incomplete type /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c: In function `type_from_format': /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c:87 : `FATAL_EXIT_CODE' undeclared (first use in this function) /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c:87 : (Each undeclared identifier is reported only once /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c:87 : for each function it appears in.) /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c: In function `accessor_from_format': /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c:11 3: `FATAL_EXIT_CODE' undeclared (first use in this function) *** Error code 1 Stop. *** Error code 1 It's a 4.0-current box... Thanks for attention... P.s. The "more" part is : Is there a good soul that can confirm that "ftp" (client) works on his box ? Mine (two boxes) fail at the first "ls" Thanks again... Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.giovannelli.it/~gmarco http://www2.masternet.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: emacs* broken in -current (was Re: Vtable thunks with egcs)
> I've found where this problem is coming from. It's in > emacs20.3/src/s/freebsd.h. It sets a macro called BSD_SYSTEM based upon the > version number contained in __FreeBSD__, checking for 1, 2 and 3. Of > course, -current uses 4. I have found that you can check for __FreeBSD__ >= > 3, and it will work, but this feels a bit like a hack. I've never updated a > port, so I can either get some instruction from someone to put in a patch, > or let someone else do it. I'll make the patch if a committer can get it in. -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
> Right or wrong, you forgot: > > 5. BSD tradition. > > Case 5 justifies Fortran. By that logic, you'd also have to add a Pascal compiler to the base system. Neither makes much sense when they can both be ports (or packages) easily addable at install or compile time by the small % of the FreeBSD population that will actually use them. John "BSD & me: together since 1983" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Confused about egcs and c++
OK. I've done two make worlds. One on April 2 or 3 and One on April 8th. I'm still getting the C++ error for simple C++ programs. Do I need to do yet another one to fix the problem? I'm doing one anyway, but am confused because I thought this had been fixed (or would be fixed by two build worlds). Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: emacs* broken in -current (was Re: Vtable thunks with egcs)
I've found where this problem is coming from. It's in emacs20.3/src/s/freebsd.h. It sets a macro called BSD_SYSTEM based upon the version number contained in __FreeBSD__, checking for 1, 2 and 3. Of course, -current uses 4. I have found that you can check for __FreeBSD__ >= 3, and it will work, but this feels a bit like a hack. I've never updated a port, so I can either get some instruction from someone to put in a patch, or let someone else do it. David Deatherage -Original Message- From: Joel Ray Holveck [mailto:jo...@gnu.org] Sent: Thursday, April 08, 1999 9:18 PM To: Steve Price Cc: Peter Jeremy; curr...@freebsd.org; po...@freebsd.org Subject: Re: emacs* broken in -current (was Re: Vtable thunks with egcs) > You are absolutely right. I just tried the new version of emacs > that I built on my pre-egcs box and it doesn't work on that box > either. This definitely doesn't appear to be anything caused by > changing to egcs. Not that it matters much but for grins I just > built/installed the xemacs port and it _does_ appear to work. I've been having no problems with an Emacs 20.3 and X11R6 built in October on a -current system from April 6. (The Emacs is ELF, and built from my own sources instead of the port.) I'd like to track this down; could people give me more info privately? rms is looking at releasing a mostly bugfix Emacs, possibly tommorow, but it may be another month (he's about to leave town). I haven't been watching the changes; there may be some X-related fixes in there. Cheers, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
>But what's wrong with having a specific -= operator? It would make code more >readable, which is a plus. It would be obvious for people to look for such >before resorting to substition rules. Creeping featurism. Obscure semantics (would it do nothing if the rvalue is not in the lvalue? What about if the rvalue is added later?). Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Panic: Invalid longjmp with vinum configured by novice
On 9 April 1999 at 11:31, Michael Reifenberger wrote: [snip] > > But vinum(8) doesn't offer > > you much in the way of editing facilities either. > A command history and commandline editing :-) Use ile in ports/misc/lile [sic], e.g. ``ile vinum'' Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
On Sat, 10 Apr 1999, Bruce Evans wrote: > >But what's wrong with having a specific -= operator? It would make code more > >readable, which is a plus. It would be obvious for people to look for such > >before resorting to substition rules. > > Creeping featurism. Obscure semantics (would it do nothing if the rvalue > is not in the lvalue? What about if the rvalue is added later?). You say "creeping features", I say "something that would have made sense since the beginning". The semantics would be "yes" and "yes", respectively > > Bruce > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
On Fri, 9 Apr 1999, Bruce Evans wrote:
> >> "CC+=-Os" in individual Makefiles works about as well as "CFLAGS+=-Os" for
> >> adding flags. That's not very well. Removing unwanted additions is hard.
>
> >Why don't we have a -= operator in make(1)?
>
> Substitution can replace -= in may cases, e.g.:
>
> CC:= ${CC:S/-Os//}
>
> This is "hard" because it has to be coded in the makefile, while additions
> can be passed to make.
But what's wrong with having a specific -= operator? It would make code more
readable, which is a plus. It would be obvious for people to look for such
before resorting to substition rules.
>
> Bruce
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
>
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \__ \ |) |
http://www.freebsd.org _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
Hi, On Thu, Apr 08, 1999 at 12:31:24PM -0400, Chuck Robey wrote: > [much whining snipped :)] Your confusing a bunch of different issues here: 1. Poor porting. a. Ports should not leave behind old files, other than site configuration files (like samba.conf). If a port leaves any files behind after a pkg_delete then it is broken and must be fixed. b. Shared library numbers should be bumped when the interface changes. I've made a number of mistakes with this on the GNOME ports, I'll admit. 2. FreeBSD Ports infrastructure problems. a. Depending on binaries without being able to get a version number. b. Not being able to upgrade a port in place. Jacques pointed to one solution to this: using one directory in /var/db/pkg per port. 3. GNOME problems. a. GNOME has no release engineering. The libraries break APIs for every pico number bump just about. Or they fix bugs and remove workarounds at higher levels. Also ESR's $%^*@ advice of release early and release often means that they often manage three releases in a 48 hour period. b. The GNOME ports must be seen as a unity. In fact I'm currently considering installing tests to stop the base packages being built from anything other than x11/gnome. The general rule for these packages is to pkg_delete gnomelibs-x.x.x and *everything* which depends on it, and then build x11/gnome. I'm going to add messages to the ports which announce this at uninstall time. I've been thinking a lot about this and other porting problems presented by GNOME and am trying to come up with solutions. At the moment I'm more concerned with actually getting the ports compiled right. But some thoughts: 1. Use -soname for binaries. Add this to $LDFLAGS or something, to get a version number installed into a binary then create extra magic or a script to test this in the DEPENDS. I don't know if this is possible, but there must be some field available which can be got with either file(1) or objdump(1). Same idea for scripts. 2. Add a version history in files. Each time a port is upgraded, add the new PKGNAME to files/history. Recreate these from the CVS history using a very clever script. Then use this to deinstall all old versions, or for upgrading. Upgrading requires much more dynamic PLISTs. Maybe a port should check for all files in PLIST before installing and refuse to install unless they are cleaned out first. 3. Change the DEPENDS mechanism in ports to use a Makefile.depends in each subdir. The port's makefile includes this, which in term includes all those from the ports it requires. Each port can then setup the environment for ports which depend on it, and check if it is correctly installed (using the appropriate magic in bsd.port.mk). There are a lot of other things need in a perfect ports/package system... Regards, -Jeremy -- | "I could be anything I wanted to, but one things true --+-- Never gonna be as big as Jesus, never gonna hold the world in my hand |Never gonna be as big as Jesus, never gonna build a promised land |But that's, that's all right, OK with me..." -Audio Adrenaline To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: CAM changes causing prob?
In article <199904090127.jaa07...@ariadne.tensor.pgs.com> you wrote: > After the last lot of CAM changes, I occasionally get processes hanging > attempting to access my QIC-525 tape drive. They can't be killed, so doing > backups can be a mite troublesome. Sometimes it works, sometimes it doesn't. > There seems to be some relation to how recently the last lot of tape activity > was (althought this is rather tenuous). It would be usefull to see the "ps -l" output for the hung process so we know what resource it is blocking on. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
On Fri, 9 Apr 1999, The Hermit Hacker wrote: > [g77 in the source tree] >I have to agree here...I personally know noone that actually uses >Fortran...having it as an option to turn off would be nice...one less >thing to compile on a buildworld... I know *lots* of people that use FORTRAN. That aside, I think I'd be satisfied with a port. Brian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
[cc trimmed to avoid cross-posting] Jeremy Lea wrote: > > I always thought the criteria for inclusion of things into the base > system was: > > 1. Needed for 'make world'; > 2. Needed to get a basic functioning server up and running; > 3. Something usefull only within FreeBSD (like the kernel ;), or > 4. Can't be effectively built outside of /usr/src. Right or wrong, you forgot: 5. BSD tradition. Case 5 justifies Fortran. Me, I'd rather have Fortran as a port. I'd even grudgingly accept fortune as a port, as a matter of fact. Our base system is bloated. While a lot of widely used programs are only available through ports, a lot of obscure and obsolete stuff remains on our tree. They are there because of 5. As long as 5 exists, Fortran belongs in the tree. If we ever get rid of 5, then it's time to get the knife to our tree... Or the axe, if the vikings decide to have the first cut. :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "nothing better than the ability to perform cunning linguistics" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
[Fwd: building world]
Dana Huggard wrote: > > Chris Costello wrote: > > > > On Fri, Apr 9, 1999, Dana Huggard wrote: > > > I see there has been some discussions around building world. I may have > > > missed or forgotten something, or even not read the right README. Also > > > seen some captured text of builds and where they fail. In > > > gnu/usr.bin/cc mine fails as well, but complains of a missing > > > `hconfig.h`, which in turn causes a screenfull of errrors. Two days ago > > > I cvsup'ed the complete /src. After a few attempts it's been building > > > fine at least once a day till this missing header. > > > >Let me guess. You ran 'make -j4 buildworld' (or make > > -janything buildworld)? :) > > > > no. I always just use 'make buildworld'. In the last case I just used > 'make' from within '/usr/src/gnu/usr.bin/cc'. > > I've used 'find' a couple of times and this 'hconfig.h' file does not > exist. > > Cheers, > Dana_H To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
Marc G. Fournier wrote: > On Thu, 8 Apr 1999, Brian Handy wrote: > > > On 9 Apr 1999, Dag-Erling Smorgrav wrote: > > > > >> [4 people said "YES! Add g77!"] > > > > >I beg your pardon? You're adding g77 to the system because you know of > > >four people who would find it useful? Where's the logic in that? > > > > Well, statistically speaking, that's a bunch of "ayes" and no "noes". > > Lots of things happen via implicit acceptance. (I was one of the people > > who spoke up in favor of this after David mentioned this.) > > > > >If you do add it to the base system, make it optional. I don't care if > > >it defaults to on, as long as I have the option to turn it off. > > > > This doesn't seem unreasonable. (I also really like Chuck's idea of > > adding gcj in the same light.) > > Geez, and I used to think it was only the commercial OSs that had a > problem with bloat and creeping featurisms ... :( Chuck's idea makes more > sense...how many programs does the average system run that needs a fortran > compiler? *raised eyebrow* Personally, I'm not sure g77 is needed, but let me play devil's advocate here and turn your question around: "How many programs does the average system not run because the system doesn't have a FORTRAN compiler?" That seems to be a more pertinent question... and - a good bit more difficult to answer. - Dave Rivers - (My personal preference is to put it in there, with an option to disable it in "make world". ) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
Hi,
On Fri, Apr 09, 1999 at 10:37:55AM -0300, The Hermit Hacker wrote:
> Geez, and I used to think it was only the commercial OSs that had a
> problem with bloat and creeping featurisms ... :( Chuck's idea makes more
> sense...how many programs does the average system run that needs a fortran
> compiler? *raised eyebrow*
I always thought the criteria for inclusion of things into the base
system was:
1. Needed for 'make world';
2. Needed to get a basic functioning server up and running;
3. Something usefull only within FreeBSD (like the kernel ;), or
4. Can't be effectively built outside of /usr/src.
If {g77|f77} can be built as a port, using the system EGCS, then to
port's it goes. Otherwise why don't we include the Top 20 ports, or
maybe the Top 25, or...
Regards,
-Jeremy
--
| "I could be anything I wanted to, but one things true
--+-- Never gonna be as big as Jesus, never gonna hold the world in my hand
|Never gonna be as big as Jesus, never gonna build a promised land
|But that's, that's all right, OK with me..." -Audio Adrenaline
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: building world
On Fri, Apr 9, 1999, Dana Huggard wrote: > I see there has been some discussions around building world. I may have > missed or forgotten something, or even not read the right README. Also > seen some captured text of builds and where they fail. In > gnu/usr.bin/cc mine fails as well, but complains of a missing > `hconfig.h`, which in turn causes a screenfull of errrors. Two days ago > I cvsup'ed the complete /src. After a few attempts it's been building > fine at least once a day till this missing header. Let me guess. You ran 'make -j4 buildworld' (or make -janything buildworld)? :) > > Cheers, > Dana_H > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > -- = * "This process can check if this value is * * zero, and if it is, it does something* * child-like." -Forbes Burkowski, CS 454 * = To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
On Thu, 8 Apr 1999, Brian Handy wrote:
> On 9 Apr 1999, Dag-Erling Smorgrav wrote:
>
> >> [4 people said "YES! Add g77!"]
>
> >I beg your pardon? You're adding g77 to the system because you know of
> >four people who would find it useful? Where's the logic in that?
>
> Well, statistically speaking, that's a bunch of "ayes" and no "noes".
> Lots of things happen via implicit acceptance. (I was one of the people
> who spoke up in favor of this after David mentioned this.)
>
> >If you do add it to the base system, make it optional. I don't care if
> >it defaults to on, as long as I have the option to turn it off.
>
> This doesn't seem unreasonable. (I also really like Chuck's idea of
> adding gcj in the same light.)
Geez, and I used to think it was only the commercial OSs that had a
problem with bloat and creeping featurisms ... :( Chuck's idea makes more
sense...how many programs does the average system run that needs a fortran
compiler? *raised eyebrow*
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
On Fri, 9 Apr 1999, Joe Abley wrote:
> On Fri, Apr 09, 1999 at 03:16:41AM +0200, Dag-Erling Smorgrav wrote:
> > "David O'Brien" writes:
> > > I've only heard back from 4 folks about adding EGCS's g77 to the base
> > > system -- all 4 said "yes". Unless I get more feedback, I will add g77
> > > to the base system this weekend.
> >
> > I beg your pardon? You're adding g77 to the system because you know of
> > four people who would find it useful? Where's the logic in that?
> >
> > If you do add it to the base system, make it optional. I don't care if
> > it defaults to on, as long as I have the option to turn it off.
>
> Oh good lord, not again.
I have to agree here...I personally know noone that actually uses
Fortran...having it as an option to turn off would be nice...one less
thing to compile on a buildworld...
I personally liked the whole ports concept...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
building world
I see there has been some discussions around building world. I may have missed or forgotten something, or even not read the right README. Also seen some captured text of builds and where they fail. In gnu/usr.bin/cc mine fails as well, but complains of a missing `hconfig.h`, which in turn causes a screenfull of errrors. Two days ago I cvsup'ed the complete /src. After a few attempts it's been building fine at least once a day till this missing header. Cheers, Dana_H To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
panic: integer divide fault with vinum
Hi,
next try.
Please forgive if gets too stupid :-)
# cat x
drive d1 device /dev/da1d
drive d2 device /dev/da2d
volume raid
plex org stripe 256k
sd length 50m drive d1
sd length 50m drive d2
(please note again the misspelling of striped)
# vinum create x
1: drive d1 device /dev/da1d
** 1 Can't initialize drive d1: Device not configured
2: drive d2 device /dev/da2d
** 2 Can't initialize drive d2: Device not configured
4: plex org stripe 256k
** 4 Invalid plex organization: Invalid argument
5: sd length 50m drive d1
** 5 Unnamed sd is not associated with a plex: Invalid argument
6: sd length 50m drive d2
** 6 Unnamed sd is not associated with a plex: Invalid argument
Configuration summary
Drives: 0 (4 configured)
Volumes:1 (4 configured)
Plexes: 0 (8 configured)
Subdisks: 0 (16 configured)
V raid State: down Plexes: 0 Size: 0 B
(juppie no panic!)
(Ok, after repairing 'striped' in x)
# vinum create x
Configuration summary
Drives: 0 (4 configured)
Volumes:2 (4 configured)
Plexes: 1 (8 configured)
Subdisks: 2 (16 configured)
V raid State: down Plexes: 1 Size:100 MB
P raid.p0 S State: down Subdisks: 2 Size:100 MB
S raid.p0.s0State: stalePO:0 B Size: 50 MB
S raid.p0.s1State: stalePO: 256 kB Size: 50 MB
(Hmm, stale sigh. The vinum(8) GOTCHAS 2. is not explicit about my situation.
this time, no `vinum resetconfig`, so:)
# vinum detach raid.p0
# vinum detach raid.p0.s0
# vinum detach raid.p0.s1
(Maybe this was too stupid and I get a deserved:)
..panic..
IdlePTD 3686400
initial pcb at 2f747c
panicstr: integer divide fault
panic messages:
---
Fatal trap 18: integer divide fault while in kernel mode
instruction pointer = 0x8:0xc0283b27
stack pointer = 0x10:0xc377cc64
frame pointer = 0x10:0xc377ccd8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 330 (vinum)
interrupt mask =
trap number = 18
panic: integer divide fault
syncing disks... 3 3 done
running gdb post mortem:
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xc016e6f5 in panic (fmt=0xc02c9ea9 "integer divide fault")
at ../../kern/kern_shutdown.c:448
#2 0xc025a8ce in trap_fatal (frame=0xc377cc28, eva=0)
at ../../i386/i386/trap.c:943
#3 0xc025a32c in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = 102400, tf_ebp = -1015558952, tf_isp = -1015559088, tf_ebx = 0,
tf_edx = 0, tf_ecx = 102400, tf_eax = 1, tf_trapno = 18, tf_err = 0,
tf_eip = -1071105241, tf_cs = 8, tf_eflags = 66118, tf_esp = 0,
tf_ss = -1065135960}) at ../../i386/i386/trap.c:586
#4 0xc0283b27 in __qdivrem (uq=102400, vq=0, arq=0xc377ccf4)
at ../../libkern/qdivrem.c:100
#5 0xc028496f in __umoddi3 (a=102400, b=0) at ../../libkern/umoddi3.c:51
#6 0xc0842fe6 in ?? ()
#7 0xc0848dc4 in ?? ()
#8 0xc0848528 in ?? ()
#9 0xc01a0567 in spec_ioctl (ap=0xc377ce0c)
at ../../miscfs/specfs/spec_vnops.c:440
#10 0xc019fe79 in spec_vnoperate (ap=0xc377ce0c)
at ../../miscfs/specfs/spec_vnops.c:129
#11 0xc02309a9 in ufs_vnoperatespec (ap=0xc377ce0c)
at ../../ufs/ufs/ufs_vnops.c:2327
#12 0xc019aae5 in vn_ioctl (fp=0xc0811040, com=3223602776,
data=0xc377ced0 "\001", p=0xc352b780) at vnode_if.h:395
#13 0xc017a114 in ioctl (p=0xc352b780, uap=0xc377cf84)
at ../../kern/sys_generic.c:564
#14 0xc025ab17 in syscall (frame={tf_es = 47, tf_ds = 47,
tf_edi = -1077945576, tf_esi = 1, tf_ebp = -1077945696,
tf_isp = -1015558188, tf_ebx = -1077945732, tf_edx = 0,
tf_ecx = 134781696, tf_eax = 54, tf_trapno = 12, tf_err = 2,
tf_eip = 134619728, tf_cs = 31, tf_eflags = 663, tf_esp = -1077945760,
tf_ss = 47}) at ../../i386/i386/trap.c:1101
#15 0xc024f20c in Xint0x80_syscall ()
#16 0x80483d1 in ?? ()
#17 0x8048295 in ?? ()
#18 0x80480ec in ?? ()
Anything else I can do or inspect?
Bye!
Michael Reifenberger
Plaut Software GmbH, R/3 Basis
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: ATTENTION PLEASE: g77 in base system.
> Yeah, I'm serious, I would really like gcj+libgcj, to get java stuff > compiled (non portably) into binaries on FreeBSD. 1. I agree in principle. 2. I'd sort of like to see a second release of this, at least, before we start talking seriously of bringing it into -current. I predict a rapidly changing Doppler on this target. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Panic: Invalid longjmp with vinum configured by novice
Hi, On Fri, 9 Apr 1999, Greg Lehey wrote: ... > > # vinum start > > You don't need to do this unless you already have objects defined from > an earlier run of vinum. Ah, ok. > > > # vinum resetconfig > > You never need to do this after a start. To quote vinum(8): I was aware of the fact that this command ist not for the normal use. I just wanted to set a clean startingpoint for this example. > Not much. It's trivial to implement, but just another way of shooting > yourself in the foot. I find the configfile appropriate for initial confiurations. But what is the best method if one disk faults and gets replaced. Then I shouldn't need the overall confguration. Unfortunately the documentation is not that specific about this point, one should need only to recreate the subdisks which laid on the faulty disk after creating a vinum slice on the fresh disk, right? Or does vinum replicates itself after the failure onto the fresh disk? > > > I suspect one will not have a r/w filesystem in worst case scenarios > > for creating vinum createfiles (And even if, `ed` is not my friend.) > > Hmm. I suppose that might be an argument. But vinum(8) doesn't offer > you much in the way of editing facilities either. A command history and commandline editing :-) And many thanks for helping anyway! Bye! Michael Reifenberger Plaut Software GmbH, R/3 Basis To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Make world is broken for days now... :(
Hello, For the past week, I've been trying to build world, in order to get then new egcs up and running. Everytime I try to make world, I get the following: ===> cc_tools cc -O -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/objc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/config -DFREEBSD_NATIVE -DDEFAULT_TARGET_VERSION=\"egcs-2.91.66\" -DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c In file included from /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/config/i386/xm-i386.h:43, from /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/hconfig.h:2, from /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/gengenrtl.c:22: /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/tm.h:3: linux.h: No such file or directory /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/egcs/gcc/tm.h:4: i386/freebsd-elf.h: No such file or directory *** Error code 1 Stop. *** Error code 1 Stop. This has been happening to me ever since monday. CVSupped several times a day ever since, And I cant seem to get past it. I must have done something wrnog, Im sure of it, but I cant seem to track it down. Last cvsup on Friday morning. -- Gilad. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: -jN make world
Hi, At 4:44 pm -0700 8/4/99, David O'Brien wrote: > >Please try rev 1.24 of src/gnu/usr.bin/cc/cc_tools/Makefile. That one works -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: msdosfs problems?
On Thu, 8 Apr 1999, Jake wrote: > I usually use x11amp, but haven't had any problems with mpg123 either, > same version you're using. > > I'm running -current as of yesterday; I load msdosfs as a KLD. > If yours is statically compiled in, maybe try the module? Yes, it's statically linked in, and it truely seems to be some problem with fbsd. I booted into 98 and used Winamp and it played fine. I'm reasonably afraid to touch the zip drive... - alex To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
>> "CC+=-Os" in individual Makefiles works about as well as "CFLAGS+=-Os" for
>> adding flags. That's not very well. Removing unwanted additions is hard.
>Why don't we have a -= operator in make(1)?
Substitution can replace -= in may cases, e.g.:
CC:=${CC:S/-Os//}
This is "hard" because it has to be coded in the makefile, while additions
can be passed to make.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: EGCS troubles
> > Compile Jade with "-g" and see where in the coredump the signal 11 is > > occuring.? What does ``ldd jade'' show?? You might be mixing shared libs, > > that doesn't work for C++.? Could also be an exceptions problem.? Try > > compiling with -fnoexpcetions. > > [asmo...@daemon] (163) $ ldd /usr/local/bin/jade > /usr/local/bin/jade: > ??? libstyle.so.1 => /usr/local/lib/libstyle.so.1 (0x280b6000) > ??? libspgrove.so.1 => /usr/local/lib/libspgrove.so.1 (0x282ac000) > ??? libgrove.so.1 => /usr/local/lib/libgrove.so.1 (0x282ef000) > ??? libsp.so.1 => /usr/local/lib/libsp.so.1 (0x282f7000) > ??? libintl.so.1 => /usr/local/lib/libintl.so.1 (0x284ce000) > ??? libstdc++.so.3 => /usr/lib/libstdc++.so.3 (0x284d2000) > ??? libm.so.2 => /usr/lib/libm.so.2 (0x2850d000) > ??? libc.so.3 => /usr/lib/libc.so.3 (0x28527000) > > I know for certain that libintl is gcc. > > Will go and do recompilations of all stuff this weekend *sigh*? ;) > ? In my case (it seems all libs compiled under egcs - exactly when jade compiled): /usr/local/bin/jade: ??? libstyle.so.1 => /usr/local/lib/libstyle.so.1 (0x280b9000) ??? libspgrove.so.1 => /usr/local/lib/libspgrove.so.1 (0x282b6000) ??? libgrove.so.1 => /usr/local/lib/libgrove.so.1 (0x282f9000) ??? libsp.so.1 => /usr/local/lib/libsp.so.1 (0x28301000) ??? libstdc++.so.3 => /usr/lib/libstdc++.so.3 (0x284e4000) ??? libm.so.2 => /usr/lib/libm.so.2 (0x28521000) ??? libc.so.3 => /usr/lib/libc.so.3 (0x2853c000) ? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
