RE: Kernel Panic
I think I see what caused the kernel to crash. What happened was this, I believe, is that since I didn't specify the regular pine binary, the script just loaded itself, thus throwing it into a loop. It's really a sad situation. -- Jonathan __ Jonathan M. Slivko [EMAIL PROTECTED] Technical Support, Black Lotus Communications http://www.blacklotus.net -- check us out! -- -- Original Message -- From: Ted Mittelstaedt [EMAIL PROTECTED] Date: Thu, 21 Jun 2001 23:34:02 -0700 That absolutely will not crash a FreeBSD system that's not got other problems. However, what I think is going on here is that the system that you ran this on has buggy disk hardware. It's probably some IDE disk, right? I've got a system here that I've tried 5 different IDE paddle cards in, and on every one I've tried installing FreeBSD and doing different operations and within about 20 minutes I had crashed it and screweged the filesystem. I finally got so annoyed I dug up an old AHA1520 SCSI card and slapped a 1GB SCSI disk on it (the system isn't intended to be doing anything fancy) and it's been solid as a rock ever since. The best conclusion I have is that the ISA bus in the system has some clock speed error that doesen't affect the SCSI disk system. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan Slivko Sent: Thursday, June 21, 2001 4:59 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Kernel Panic Hello, I just wrote a little shell script that, on the machine I tested it on, crashed the box and forced a reboot. The contents of the script was: #!/bin/sh pine -i rm -rf $HOME/dead.letter Thats the whole script. I don't see how something like that could cause a kernel to crash. Would anyone mind trying to replicate this on a test box. If it's a security issue, i'll forward it to security when I get more information. -- Jonathan __ Jonathan M. Slivko [EMAIL PROTECTED] Technical Support, Black Lotus Communications http://www.blacklotus.net -- check us out! -- _ __ ___ Sent via the Pace University Mail system at stmail.pace.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message ___ ___ Sent via the Pace University Mail system at stmail.pace.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: AC97 sound codecs
Is the AC97 sound system supported on on -stable. yes. 1. i815E/Celeron motherboard, AD1885 codec 2. SiS 730S/Duron Motherboard, ALC200 codec I found that in sys/dev/sound/pcm/ac97.c has a list of AC97 codecs and should print a messge for the codec. I just get a unknown card message from boot -v The BIOS listed same ID numbers as Multmedia Device There were no ac97 related messages in the boot -v listing. The sound driver file for -current shows both these codecs (and others) you misunderstand the purpose of ac97. ac97 provides a standard interface between a digital audio controller and the analogue world. it does not provide any direct interface to the rest of the computer. therefore, while the audio controller-codec interface can be supported with generalised code, it is reliant on having a driver for the audio controller. an i810/i815 driver will be committed once my i815 motherboard arrives. no driver is currently planned for sis630/730 or ali motherboards due to lack of hardware and lack of funds. the audio controller on these boards is very similar to the trident 4dwave. no driver is planned for the via8233 for the same reason. i will accept driver submissions for any controller not currently supported, or donations of any sound related hardware including motherboards with onboard sound, soundcards, internal/external midi units, etc. i'm especially interested in hardware that we don't currently support although working hardware is always useful for regression testing. however, if you have hardware which is not supported but information exists to allow its support, and you are not prepared to contribute a driver or donate equivalent hardware so that i can write a driver without having to purchase it at my own personal expense then please a) check list archives of freebsd-multimedia to ensure that i know said hardware exists, and b) be patient and hope that someone else is more generous than you or that i find the money to invest in it myself. this is not just directed at you, mr hall. it applies to everyone that i have observed asking about the same hardware time and time again. and lest some of you think otherwise, digital audio support has had exactly one person behind it for almost two years- me. i now have orion and greid assisting me, but we still have very limited resources. we're not getting paid for this, and we do have other things to do so our time is far from limitless. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Staying *really stable* in FreeBSD
Ok, last try. I'm not trying to push responsibility off on anyone. There will be in infinitesmal amount of work involved. The tag points to the RELENG_X_Y tag with the highest X primarily and the highest Y secondarily. That's it. No more. If someone has decided to create a new RELENG_X_Y then no one makes a decision to move the magic tag. There is an algorithm. That's why it is too simple to waste time on. I've seen a lot of traffic from people who don't like the instability of STABLE. Then someone mentioned tracking RELENG_4_3 then moving to RELENG_4_4_RELEASE, then to RELENG_4_4. I thought this sounded like nice compromise of features vs stability. Then I thought, wouldn't it be nice if it was automatic? If a computer can do it, I don't want to waste my time on it. Hence the email. It is just another way for people to track sources in some way they are comfortable with. The delta of changes is not the issue, it is their *stability*. If people don't want to track this tag, then they don't have to. I don't track - -CURRENT, but I don't think it shouldn't be allowed to exist. I thought that if two people wanted something like this, then more might, and it might prevent some tracking problems. No version change confusion: I'm tracking MAGIC_VERSION and uname -a shows that. No - -RC/BETA/etc confusion. And, hey, it compiles. And works. No need to send mail to find out how to fix it. The fact that most people talk about -STABLE unqualified with a version number and that the name of this list is freebsd-stable, again unqualified with a version number, seems to imply that people think in terms of a single stable stream of changes to FreeBSD. I think it would be nice to tag that stream of stable changes with a single tag. Again, people would be free to ignore it and track any RELENG_X_Y they choose, or any other tag they choose. The only issue I see is when a RELENG_X_Y appears after an RELENG_X+1_Z has begun. My choice is highest X wins. Since the RELENG_X_Y branches are considered most stable, then RELENG_X_Y must be as *stable* as RELENG_X+1_Z, and the tie breaker for me is more features and so a move the the X+1 version. A personal preference, I admit. Like I said before, I would be more than happy to do it myself, if I had programmatic access to all tags. Here's an AI program to make the decision: #!/usr/bin/env perl @sv = sort(@ARGV); print @sv[$#sv], \n; exit(0) Once again, this is why it is too trivial to type so much about. This may be a bad and stupid idea, but if so, please attack it from a position of understanding what it is, not something else. And regardless, this is a stream *I* would track, so it is not 100% wrong. regards, davep (random, but appropriate, sig:) - -- Howe's Law: Everyone has a scheme that will not work. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Compiling old fxp driver?
How would I go about compiling an old version of the fxp driver?? I'm getting timeout errors every day on one of my machines, and would like to try an older version of the driver... Thanks for any help, Eric Parusel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Compiling old fxp driver?
Comment out the dev/fxp entry and uncomment the pci/if_fxp.c entry How recent a STABLE are you running ? There was a new rev the 14th of June backup# diff -u /usr/src/sys/conf/files.orig /usr/src/sys/conf/files --- files.orig Fri May 18 14:07:27 2001 +++ files Fri May 18 14:07:40 2001 @@ -161,7 +161,7 @@ dev/ex/if_ex_pccard.c optional ex card dev/fe/if_fe.c optional fe dev/fe/if_fe_pccard.c optional fe card -dev/fxp/if_fxp.c optional fxp +#dev/fxp/if_fxp.c optional fxp dev/hea/eni.c optional hea dev/hea/eni_buffer.c optional hea dev/hea/eni_globals.c optional hea @@ -950,7 +950,7 @@ pci/if_dc.coptional dc pci/if_de.coptional de pci/if_en_pci.coptional en pci -#pci/if_fxp.c optional fxp +pci/if_fxp.c optional fxp pci/if_lnc_p.c optional lnc pci pci/if_pcn.c optional pcn pci/if_mn.coptional mn At 09:28 AM 6/22/01 -0700, Eric Parusel wrote: How would I go about compiling an old version of the fxp driver?? I'm getting timeout errors every day on one of my machines, and would like to try an older version of the driver... Thanks for any help, Eric Parusel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Staying *really stable* in FreeBSD
Dmitry Karasik [EMAIL PROTECTED] types: On 21 Jun 01 at 16:45, Jason (Jason Watkins) wrote: Jason Don't camoflage one problem by providing a solution to Jason another. What you're really worried about is how stable -stable Jason is. Address that, and things will be better than managing: Jason -its_not_stable_but_we_pretend -stable -yet_more_stable Jason -so_stable_its_more_stale_than_the_cheesewiz_in_my_house Well, instead of criticizing the only decent proposition in the thread you all people could invent something that works. But no one wants to, that's the point. If it were a decent proposition, it wouldn't be drawing criticism. What we have is a system that works, in the form of CURRENT, STABLE and RELEASE. We also have a new facility in the form of a branch that inludes only security fixes from STABLE - something I'm going to call RELENG. RELENG was introduced with the previous release, and we now have a proposition designed to work around the problem of having to edit the supfile to change to a new branch after a release. This is exactly the way things have worked with STABLE, and I've never seen anyone claim that that was a problem. Since this case has never happened, any problems are hypothetical. The relevant experience with FreeBSD is that: 1) Editing the supfile is trivial, and seldom causes problems. 2) Tracking STABLE at reasonable intervals is straightforward, and seldom causes problems. 3) Jumps of a release are slightly more complicated, sometimes cause problems, and should be handled with care. 4) Jumps across versions are a major PITA, and almost always have to be given special treatment. RELENG is an attempt to make life easier for people who don't want to upgrade their system, but do want to get security fixes. Given that goal and the relevant experience, RELENG seems to be a good solution. It may not be, but we really need some evidence before making such a decision. So we have a proposition that moves the work from people who want to track stable in a manner resembling the punctuated equilibrium theory of evolution to the release engineer - who is a volunteer - to solve a problem that has never been observed in the wild. Before doing any work to fix this problem, it would be nice to have some evidence that this problem exists, and to have more experience with the process of taking a system from one RELENG branch to the next one. If the problem is instead that STABLE isn't STABLE enough and RELENG doesn't move fast enough - though evidence for the latter would also seem to be in short supply - then one of those two problems should be attacked, rather than trying to automate something that experience shows doesn't automate well. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: SMP/fxp problem...
I've got one SMP system, with two Intel NIC's, as shown at the bottom of this message in my dmesg.boot ... My SMP system gets a fxp0: device timeoutor a fxp1: device timeout error about once every two days, and my I was getting this same problem on a dual processer system built on an Intel N440BX Nightshade motherboard. I solved it by changing a BIOS setting that limited the number of IRQ assignments from a legacy mode. Once I did that, the timeouts went away. Boot messages now show: fxp0: Intel Pro 10/100B/100+ Ethernet port 0x1060-0x107f mem 0xf800-0xf80f,0xf8104000-0xf8104fff irq 20 at device 15.0 on pci0 It's been working great (doing multiple buildworlds all the time) since I changed this in December. The system still runs 4.1.1, IIRK. John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: /var/mail permissions: 0755 or 01777 ?
Karsten W. Rohrbach wrote: Nuno Teixeira([EMAIL PROTECTED])@2001.06.21 21:51:34 +: Hello to all, The FreeBSD default permissions for /var/mail are 0755. Why is that PINE says that the /var/mail directory is vulnerable and it says to change it to 01777 1777 makes it possible for users to create files in /var/mail. The good news is that they can make lock files, which make simultaneous delivery and reading more reliable. The bad news is that they can make files named like other people's mailfiles. This can either be an attack on their reader of choice or a denial of service, depending on how smart the client and MDA are. As such, /var/mail is A Bad Thing. Putting mail into a file in the user's home directory is much safer. But the spec is too old to change by this point. So the best idea is to dispense with Unix formatted mail files alltogether. Thus this advice: use Maildir faster, simpler, secure -- simply put: better ;-) cyrus is better still, so long as you don't mind _only_ being able to use IMAP to play with your mail. Cyrus is particularly good for companies, as lmtp deliveries result in multiple ccs being hard links rather than separate copies. Great for when Marketing sends 20 copies of a 50M powerpoint presentation. :-) As for MUAs, nothing I've tried has beaten Netscape 4.x yet, although I have switched over to Mozilla and it is close. For non-GUI, I prefer pine despite its tarnished security reputation. Surprisingly enough, a close second place behind Mozilla for me is SquirrelMail in a web browser. It really is good, believe it or not. I would make a port for it, but it's sort of pointless as it's just a bunch of php scripts you unpack into your www data direectory (www.squirrelmail.org if you are curious). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: SMP/fxp problem...
Let me emphasize that I'm still using the old pci/if_fxp.c that was present up to 4.3-RELEASE, not the new miibus'ified dev/fxp/if_fxp.c that was MFC'd 6 weeks ago. John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: /var/mail permissions: 0755 or 01777 ?
Nick Sayer([EMAIL PROTECTED])@2001.06.22 09:45:47 +: Karsten W. Rohrbach wrote: Nuno Teixeira([EMAIL PROTECTED])@2001.06.21 21:51:34 +: Hello to all, The FreeBSD default permissions for /var/mail are 0755. Why is that PINE says that the /var/mail directory is vulnerable and it says to change it to 01777 1777 makes it possible for users to create files in /var/mail. The good news is that they can make lock files, which make simultaneous delivery and reading more reliable. The bad news is that they can make files named like other people's mailfiles. This can either be an attack on their reader of choice or a denial of service, depending on how smart the client and MDA are. that is, why i consequently killed /var/mail delivery on all of the systems i administer (administrate? whatever)... As such, /var/mail is A Bad Thing. Putting mail into a file in the user's home directory is much safer. But the spec is too old to change by this point. So the best idea is to dispense with Unix formatted mail files alltogether. Thus this advice: use Maildir faster, simpler, secure -- simply put: better ;-) cyrus is better still, so long as you don't mind _only_ being able to use IMAP to play with your mail. Cyrus is particularly good for companies, as lmtp deliveries result in multiple ccs being hard links rather than separate copies. Great for when Marketing sends 20 copies of a 50M powerpoint presentation. :-) indeed, but as you said, imap only. i switched to multiple boxes with qmtp transport and big mail volumes, in other words: i hit the problem with iron ;-) As for MUAs, nothing I've tried has beaten Netscape 4.x yet, although I netscape mangles headers. thus, netscape is bad, IMVHO. have switched over to Mozilla and it is close. For non-GUI, I prefer pine despite its tarnished security reputation. Surprisingly enough, a over the past years i started to hate pine with all the security flaws and other operational problem that arise (mainly lack of support for maildir). for my fellow *bsd shell people, mutt does the best job and even newbies to unix and the like take a preconfigured muttrc and there they go. my personal mutt config is linked from my homepage and from the mutt faq, so you might give it a spin (configured vs. unconfigured)... close second place behind Mozilla for me is SquirrelMail in a web browser. It really is good, believe it or not. I would make a port for it, but it's sort of pointless as it's just a bunch of php scripts you unpack into your www data direectory (www.squirrelmail.org if you are curious). heard about that, gonna try it out on some intranet server next week. /k -- If it ain't broke, overclock it! KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karstenrohrbach.de -- alphangenn.net -- alphascene.org -- [EMAIL PROTECTED] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 Please do not remove my address from To: and Cc: fields in mailing lists. 10x PGP signature
Re: SMP/fxp problem...
At 12:56 PM 6/22/01 -0400, John R. LoVerso wrote: Let me emphasize that I'm still using the old pci/if_fxp.c that was present up to 4.3-RELEASE, not the new miibus'ified dev/fxp/if_fxp.c that was MFC'd 6 weeks ago. Does the new driver not work for you ? ---Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: NFS
In message [EMAIL PROTECTED], Karol Makowski writes: On Fri, 2001-06-22 at 14:16:56, Marko Cuk wrote: [cut] Marko and I'd like to make another computer to access that /data on previosl y Marko mounted box, not from original BOX source. Sure it's possiblem export it via NFS :- Most NFS implementations do not allow re-export of mounted NFS filesystems. The reason for this is that the owners of the NFS exported filesystems may not intend for those you wish to re-export filesystems to, to have access to the data. On the other hand the Linux implementation of NFS does allow re-export of filesystems. The Linux version of NFS, which runs (ran) purely in userspace, at least at the time I tested it 4-5 years ago, did work under FreeBSD under the condition that FreeBSD's NFS client and server code were disabled in the kernel, e.g removed from your kernel config and kernel rebuilt. Regards, Phone: (250)387-8437 Cy SchubertFax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: [EMAIL PROTECTED] Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
lp0 device
Hallo, I just installed FreeBSD 4.3-Release. I noticed a new entry in the output of ifconfig, a device named lp0. Where can I find more information about it? Thank you Nicolas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: lp0 device
man 4 lp -pete ++ 22/06/01 19:34 +0200 - Nicolas Rachinsky: | Hallo, | | I just installed FreeBSD 4.3-Release. I noticed a new | entry in the output of ifconfig, a device named lp0. | Where can I find more information about it? | | Thank you | Nicolas | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with unsubscribe freebsd-stable in the body of the message -- Pete Fritchman [EMAIL PROTECTED] Databits Network Services, Inc. http://databits.net finger [EMAIL PROTECTED] for PGP key To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
