Re: AMD System Management driver and Newbus
Gasp! This is part of my fault. I shouldn't have left this old style driver in the tree :( You should have contacted me, I would have adviced you. Takanori is right, you should look at intpm to get info about how to cleanly newbusify your driver. This is what I'm currently doing for alpm ;) By the way, is someone working on the VIA SMBus support? Or do I start it? -- [EMAIL PROTECTED] Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Thread DIES [Re: ssh - are you nuts?!? ]
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Thursday, December 28, 2000 1:05 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Thread DIES [Re: ssh - are you nuts?!? ] On 26 Dec, Mike Smith wrote: If it is FUD as you claim, then the call should be made by the SO. This would seem to be prudent policy. Jesse, Kris *is* the Security Officer. Now, please let this thread die. Mike, You and I don't often agree, but this time is worth noting. I agree. Messages, flames and counter-claims have now reached a point of dis-information/noise. If you have emailed me, and I have not responded - I will privately. The only exception are Wes Peters, who claims I have mis-quoted him If I have I must make a public appoligy. Bill Fumerola, who states that security policy information is un-available. However, I might refer his comment to the Security Officer instead, if Bill feels this appropriate. Any further comments about this thread should be emailed to me directly. If you post I will respond, but privately. Lastly, I formally request any further continuation about this subject on this thread stop. Jessem. At last 8). Thank you, thank you, thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
A couple of Junior Hacker tasks...
I have added a couple of tasks over at http://phantom.cris.net/freebsd/projects/projects.php which are good candidates for people looking for a good and simple task to do for FreeBSD. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A couple of Junior Hacker tasks...
On 28 Dec 2000, at 9:36, Poul-Henning Kamp wrote: which are good candidates for people looking for a good and simple task to do for FreeBSD. How do we know which are the "good and simple" ones? -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A couple of Junior Hacker tasks...
On Thu Dec 28 21:58:12 2000 Dan Langille wrote: On 28 Dec 2000, at 9:36, Poul-Henning Kamp wrote: which are good candidates for people looking for a good and simple task to do for FreeBSD. How do we know which are the "good and simple" ones? I could always do the CVSROOT/ stuff. --jm -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On Thu, Dec 28, 2000 at 12:23:12PM +1300, Dan Langille wrote: On 27 Dec 2000, at 19:56, Peter Pentchev wrote: On Wed, Dec 27, 2000 at 09:16:34AM -0800, Alfred Perlstein wrote: * Dan Langille [EMAIL PROTECTED] [001226 23:50] wrote: My idea is to have a daemon, or something resembling one, sitting on the box watching the directory. When a new file appears, it starts a perl script. This perl script is beyound the scope of my question, but it processes all the files in the directory. When finished, it looks for any more files and repeats as necessary. If no more files, it exits. This isn't an answer to your main question (i see it's already been discussed), but you may be able to use setup a kevent on the directory which should inform you if any files are added to it. Unfortunately, I gather that Dan intends to write most of the FreshPorts code in Perl, and AFAIK, Perl has no kqueue/kevent interface :( Unfortunately? *grin* FWIW, Most of the existing and new code will be PHP based. Perl is used primarly for importing data from cvs-all. And for various mailings out to users. The 'unfortunately' part was not to say that I don't like Perl, or that I don't think it should be written in Perl; rather, that at the moment, Perl has no easy way of using the kqueue/kevent interface. If there were such an iface for Perl, it would all be done with one little filter invoked from procmail to write the message, and one sleepy Perl thing, idling in an kevent() call most of the time, and only waking up when there are changes to the dir. Hmm. On second thoughts, I wonder if the sleep/opendir method might not work better under temporarily high load - even better than the cron-based one. If a bunch of mails arrive at the same time.. hmm I should play around with kevent to see how it could handle this - notifying me for each and every message could be suboptimal. The sleep/opendir way would process as many new messages as there have arrived; ditto for the cron-based one, *except* that if there are too many messages, there could be two or three Perl interpreter invocations, which find an old script still running, and die quietly, having used up some CPU resources in the meantime. Thus, to make use of kevent (which I certainly agree would be a better FreeBSD-specific solution), he'd have to either 1. have a C program which spawns Perl and his script on every change, or 2. have a C program which spawns Perl once and signals it on every change. The first way would be downright stupid IMHO.. The second one may very well be more efficient than the readdir, sleep solution which I proposed in other postings, seeing that Dan wants to process the cvs-all mailings, which certainly do not arrive every few seconds :) I like the 2nd concept. It appeals to me. I haven't done any C in about 7 years and all of that was in Windows. Never in a Unix environment. This solution is more complex than the "cron job every minute" which I discussed with Mark, but it fits with my goal of having processed the cvs-all messages as quickly as I can. I could play around with kevent in a couple of days to see how it behaves when multiple messages arrive. When a file or multiple files arrive, the sleeper would have to go through the opendir/readdir dance, and either only process the first file it finds, or process them all. In the second case, if multiple files should arrive, those would be all processed in response to one event, and the next events would trigger lots of opendir/readdir/closedir calls with no files found. Hmm.. as a side note.. I'm not quite sure how kqueues operate on vnodes. If I should request an EVFILT_VNODE filter with NOTE_WRITE, receive an event, find a new file, then unlink() it (which involves writing to the vnode I'm monitoring), will *my* write generate another event I'd have to process? G'luck, Peter -- You have, of course, just begun reading the sentence that you have just finished reading. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A couple of Junior Hacker tasks...
In message [EMAIL PROTECTED], "Dan Langille" writes: On 28 Dec 2000, at 9:36, Poul-Henning Kamp wrote: which are good candidates for people looking for a good and simple task to do for FreeBSD. How do we know which are the "good and simple" ones? How would I know ? :-) The fsck and the "read all disk blocks" tasks are pretty simple. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On 28 Dec 2000, at 10:50, Peter Pentchev wrote: Hmm. On second thoughts, I wonder if the sleep/opendir method might not work better under temporarily high load - even better than the cron-based one. If a bunch of mails arrive at the same time.. hmm I should play around with kevent to see how it could handle this - notifying me for each and every message could be suboptimal. I would appreciate that very much. I could play around with kevent in a couple of days to see how it behaves when multiple messages arrive. When a file or multiple files arrive, the sleeper would have to go through the opendir/readdir dance, and either only process the first file it finds, or process them all. In the second case, if multiple files should arrive, those would be all processed in response to one event, and the next events would trigger lots of opendir/readdir/closedir calls with no files found. I'll include my thoughts in case they help: What about a daemon signalling a waiting perl script? The script would wake up, take the first file, process it, repeat until no more files, then go back to sleep. Is it an issue if the daemon signals the perl script when it's already processing? Could a signal be missed? thank you. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
Am 28. Dec 2000 um 10:33 MET schrieb Dan Langille:
What about a daemon signalling a waiting perl script?
Is it an issue if the daemon signals the perl script when it's already
processing? Could a signal be missed?
How about using a FIFO (maybe in /tmp) and let the daemon printf,echo,cat,...
control-msgs into the FIFO and have a perl script sitting on the other end?
Signals suck. Another advantage would be that the perl script could choose
it´s own pace and let things queue up in the FIFO. However, a FIFO only
has limited capacity. If I´d be using Haskell (http://www.haskell.org), I´d
throw in a forkIO() and would get a neatly multi-threaded solution where one
thread reads the FIFO and queues up requests while the other thread queries
him for more work -- I don´t know about threaded perl, though.
--
\usepackage[latin1]{inputenc}!
Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
Volker Stolz wrote: Am 28. Dec 2000 um 10:33 MET schrieb Dan Langille: What about a daemon signalling a waiting perl script? Is it an issue if the daemon signals the perl script when it's already processing? Could a signal be missed? How about using a FIFO (maybe in /tmp) and let the daemon printf,echo,cat,... control-msgs into the FIFO and have a perl script sitting on the other end? Signals suck. Another advantage would be that the perl script could choose it´s own pace and let things queue up in the FIFO. However, a FIFO only has limited capacity. If I´d be using Haskell (http://www.haskell.org), I´d throw in a forkIO() and would get a neatly multi-threaded solution where one thread reads the FIFO and queues up requests while the other thread queries him for more work -- I don´t know about threaded perl, though. This sort of thing is why we added poll(2) and later kqueue(2) support for getting notifications on directory changes.. eg: you can get an event to tell you that a new file "appeared" in your directory. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On 28 Dec 2000, at 11:29, Volker Stolz wrote: Am 28. Dec 2000 um 10:33 MET schrieb Dan Langille: What about a daemon signalling a waiting perl script? Is it an issue if the daemon signals the perl script when it's already processing? Could a signal be missed? How about using a FIFO (maybe in /tmp) and let the daemon printf,echo,cat,... control-msgs into the FIFO and have a perl script sitting on the other end? That sounds good to me. It meets the criteria. Signals suck. Another advantage would be that the perl script could choose it´s own pace and let things queue up in the FIFO. However, a FIFO only has limited capacity. Given that we are processing incoming messages from cvs-all, I don't think we'll meet that capacity (not that I know what the capacity is). If I´d be using Haskell (http://www.haskell.org), I´d throw in a forkIO() and would get a neatly multi-threaded solution where one thread reads the FIFO and queues up requests while the other thread queries him for more work -- I don´t know about threaded perl, though. That sounds great. But without knowing more, I think it's too much for the task at hand. I would like to keep things simple and free from complicity. Writing a multi-threaded solution, unless someone else wants to do it, may be too big of a task for me. Volunteeers? ;) thank you. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
Thus spake Renaud Waldura ([EMAIL PROTECTED]): I've got that FreeBSD gateway in a corner at my house, it works fine dandy but the constant noise (whirring fans, hard drives) gets on my nerves. What solutions have people explored to quiet down a computer system? (actual experience will be preferred over wild speculations). I'm already aware of PicoBSD, but I need more storage than just a floppy. Has anybody experimented with RAM cards? How about noise-proof enclosures? A friend of mine has a Dual PII 400 box in the cellar which is his workstation. Then he has bought a K6-2 500 and is using it at 200 MHz, so it doesn't need a fan. The power supply fan is silent enough. Since this K6-2 box netboots and mounts his root via Full-Duplex Fast-Ethernet from the Workstation, where all processes are started as well, he has a silent, but fast workstation. And, btw, he is watching TV via fxtv over the network w/o any problems (AND can work in the meanwhile) Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
Mr Kamps comments are also "Well documented". I would think that EVERYONE on this list would be offended by his insinuation that anyone that uses FreeBSD and doesnt contribute source to FreeBSD is stealing. Where is that outcry on that ridiculous idea? If you are offended by people using your code then you should get out of the free source business. (haha, " business ", now thats a metaphor!) Not really, it is *open* source. Not free source :-) Free software, (to use), but not free source. There are other ways to contribute than to contribute source. Sure. You can work on docs, website, packaging etc. How many advertising dollars has Mr Kamp spent promoting the use of FreeBSD? Afaik, anybody can spend any amount of advertising dollars he wants. Thousands of users use FreeBSD enhanced with our "contributions". We spend tens of thousands of dollars advertising them, indirectly advertising FreeBSD in the process. Sure. And without FreeBSD, your "contributions" are worthless, so you already got your share. People buy products because they think that they are worth the price. The fact that so many people are willing to pay for the enhancements we provide is prima facia evidence of our contribution. Sure, but at the moment it enters the system, we are supposed to support, test and let it evoluate with the system. How to do that without source? Im sorry so few of you understand. You are being much to simplistic. It is easy to put it in the ports-tree, but after that the QA (which you think so high of) of FreeBSD as whole decreases. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: int foowrite( dev_t dev, struct uio *uio, int flag) { ... } documentation ??
We are implementing our OS modem on FreeBSD,
We use this definition in our driver :
static d_write_t tswrite;
We implemented this function:
static int tswrite( dev_t dev, struct uio *uio, int flag) { ... }
to receive characters from the tty.
This doesn't actually receive characters from the tty; it receives
characters from userland applications, which then have to be forwarded to
the tty subsystem.
Is it possible to have documentation about this function, what value we
must return ?, what is it flag ?.
You should look at /sys/isa/sio.c for reference here. The function
essentially just calls the tty lineswitch function for the current line
discipline for the tty.
Is it possible to slow down the call of this function by the kernel ?
No, and it should not be necessary to do so; the lineswitch function will
sleep or return accordingly.
I'm sorry that I've taken so long to reply to this. Please start by
reading the sio driver (source referenced above), which should make the
details clearer. For any tty-style driver, the basic gist of things is
as follows:
- probe/attach as per a normal driver
- on first open, create a tty device (ttymalloc, etc.)
- on write/write, pass to line discipline current for the tty
- on input/output interrupt, interface with current line discipline
The driver structure may seem a little complicated; it's something like
this:
-- --
| userspace | IP stack |
- --
| ioctl* | read/write* | kernel PPP/ SLIP |
--- - --
| | line disciplines|
-
| driver hardware I/O* |
-
The only bits you actually have to provide are the (*) bits.
Please let us know if you have any more questions.
Regards,
Mike
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: mtrr and stepping=2 K7's
Are there any known issues with MTRR on early K7's? I'm not aware of any, no. A cursory read of the current Linux MTRR code doesn't suggest that they treat them specially either. Using XFree86 4.0.x on an early 550 Mhz K7 (equipped with 256Megs of sdram) causes this machine to lock up, unless I comment out the K7 mtrr enabling stuff in i686_mem.c. This happens with any VGA card that I drop in the box, (PCI bus voodoo4, a Rage IIc ATI card, and the Matrox G400). Ack, that's not very good. 8( Is there a cleaner way of disabling it for X? If not, we'll need to add a tweak to turn it off (or detect the CPU and do it automatically). If you can come up with more definite information and/or patches to DTRT here, that'd be greatly appreciated. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On Thu, Dec 28, 2000 at 11:36:50PM +1300, Dan Langille wrote: On 28 Dec 2000, at 11:29, Volker Stolz wrote: Am 28. Dec 2000 um 10:33 MET schrieb Dan Langille: What about a daemon signalling a waiting perl script? Is it an issue if the daemon signals the perl script when it's already processing? Could a signal be missed? How about using a FIFO (maybe in /tmp) and let the daemon printf,echo,cat,... control-msgs into the FIFO and have a perl script sitting on the other end? That sounds good to me. It meets the criteria. Actually, there's no need for the FIFO. What I've been thinking about is a little C program that spawns a Perl script, then sits, watching the spool directory through the kevent interface. When a new file appears, the parent lets the child know - this need not be signal-based, I'm thinking more along the lines of writing to a previously-opened pipe. This has the added benefit that the parent can monitor the child's status, and respawn it if it dies; with separate processes and a FIFO, if the reader dies, the writer either blocks or goes haywire, judging from my (admittedly limited) experience. Handling SIGCHLD and respawning seems easy :) Also, the Perl child can find out the parent has died (the pipe shall close or something), and die gracefully, to be reborn as the parent is respawned. Respawning the parent could be done as either a /etc/inittab-respawned process, or a service running under svscan from DJB's daemontools package. The latter case also has a almost-built-in logging with support for log rotation through multilog. G'luck, Peter -- If you think this sentence is confusing, then change one pig. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On Thu, Dec 28, 2000 at 02:35:19AM -0800, Peter Wemm wrote: This sort of thing is why we added poll(2) and later kqueue(2) support for getting notifications on directory changes.. eg: you can get an event to tell you that a new file "appeared" in your directory. See how the l0pht-watch port does exactly this. In fact you could probably use that program as-is - I think it has the capability to execute another process on file creation.. Kris PGP signature
Re: waiting for new files in a directory
What are you guys smoking? Use cron to run a spool scanning job every minute or so, and use a lock file to make sure one doesn't start until the previous one is done. Note that reliable locking is non-trivial in Perl; a quick workaround is to use a lock directory instead (mkdir() will fail if the directory exists; make sure to differentiate between "somebody already holds the lock" and "the lock can't be created due to permission errors or some other problem" by examining $!) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On Thu, Dec 28, 2000 at 01:35:08PM +0100, Dag-Erling Smorgrav wrote:
What are you guys smoking?
*shrug* Can you spell "event-driven"? There are ways to do things much
more elegantly today (see all the references to kevent()).
--
\usepackage[latin1]{inputenc}!
Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On Thu, Dec 28, 2000 at 01:35:08PM +0100, Dag-Erling Smorgrav wrote: What are you guys smoking? Use cron to run a spool scanning job every minute or so, and use a lock file to make sure one doesn't start until the previous one is done. Note that reliable locking is non-trivial in Perl; a quick workaround is to use a lock directory instead (mkdir() will fail if the directory exists; make sure to differentiate between "somebody already holds the lock" and "the lock can't be created due to permission errors or some other problem" by examining $!) I've tried this; and I still believe that a process continuously watching the directory is better than a cronjob for several reasons, which I have outlined in a previous mail. First, there is *no* need for locking if a single process is there all the time; this eliminates all sorts of locking problems. Second, there is no overhead in starting Perl (yeah, yeah, so it's cached after the first few times, but still..) each and every minute just to find nothing and die quietly - as somebody else said, that's exactly why poll(2) and later kqueue/kevent work on directory vnodes. Third, if a process uses poll(2) or kqueue, it shall react on new mails the moment they arrive, not up to a minute later. G'luck, Peter -- because I didn't think of a good beginning of it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
Volker Stolz [EMAIL PROTECTED] writes: On Thu, Dec 28, 2000 at 01:35:08PM +0100, Dag-Erling Smorgrav wrote: What are you guys smoking? *shrug* Can you spell "event-driven"? There are ways to do things much more elegantly today (see all the references to kevent()). I choose simple and working over elegant. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
On Thu, Dec 28, 2000 at 01:44:34PM +0100, Dag-Erling Smorgrav wrote: Volker Stolz [EMAIL PROTECTED] writes: On Thu, Dec 28, 2000 at 01:35:08PM +0100, Dag-Erling Smorgrav wrote: What are you guys smoking? *shrug* Can you spell "event-driven"? There are ways to do things much more elegantly today (see all the references to kevent()). I choose simple and working over elegant. I think opendir-readdir-closedir-sleep is a bit simpler than the locking you yourself admit is non-trivial :) G'luck, Peter -- When you are not looking at it, this sentence is in Spanish. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: waiting for new files in a directory
Peter Pentchev [EMAIL PROTECTED] writes: On Thu, Dec 28, 2000 at 01:44:34PM +0100, Dag-Erling Smorgrav wrote: Volker Stolz [EMAIL PROTECTED] writes: On Thu, Dec 28, 2000 at 01:35:08PM +0100, Dag-Erling Smorgrav wrote: What are you guys smoking? *shrug* Can you spell "event-driven"? There are ways to do things much more elegantly today (see all the references to kevent()). I choose simple and working over elegant. I think opendir-readdir-closedir-sleep is a bit simpler than the locking you yourself admit is non-trivial :) Locking in Perl is a known problem with a known solution which takes me five or ten minutes to implement off the top of my head, and I don't trust insert your favorite startup script here not to start multiple copies of the spool scanner. You can of course write the scanner in such a way that multiple instances can run in paralell without harm even without locking; this is left as an exercise for the reader. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: -STABLE+vinum+smp+softupdates+CVSup(local CVS repo)==corruption?
On Tue, Dec 26, 2000 at 05:30:09PM -0500, David E. Cross wrote: I have run across a problem since updating to -STABLE a week or so ago... my CVS vinum partition would go corrupt after a few updates. I have been running with no softupdates on my system for a day now and no problems. Has anyone else seen this? Is that with vinum raid 5? If so there are know problems with raid 5 and you should either help Greg to fix them or avoid raid 5 like the plague lest your data corrupts itself. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Boot process robustness
Hi all, I was wondering how to increase the robustness of the booting process, so that a box would be able to keep itself on its feet without intervention of the console. I think this would be of great value to the many people who administer colocated boxes. I'm not much of a coder so all I can do is mailing this (at the risk of wasting your time with total useless crap ofcourse, in which case I apologize.) 1. Old kernel recovery When 'make install'ing a new kernel, a flag is raised (say, 'revert_on_fail') which is only cleared after a successful system initialisation. When the new kernel boots, a panic in this state or an unexpected reboot (reset after a system hang) would cause /kernel.old to be loaded on the next boot instead (maybe the same could work for /etc/rc.conf.old) 2. Automatic file system checks In case of a powercycle or crash, it could be that a filesystem needs fixing. Now I don't know much about fs internals, but I guess that in most cases just answering 'Y' to fsck's questions will fix things. I would appreciate an option where an inconsistency would start up fsck in an "automatic" repair mode, with all actions logged and "undo" data being saved (in case manual review is needed). There! (Merry etc etc, by the way!) walter -- Walter W. Hop [EMAIL PROTECTED] | +31 6 24290808 | PGP key: 0xD4DD8DEB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot process robustness
In message [EMAIL PROTECTED], "Walter W. Ho p" writes: Hi all, I was wondering how to increase the robustness of the booting process, so that a box would be able to keep itself on its feet without intervention of the console. I think this would be of great value to the many people who administer colocated boxes. I'm not much of a coder so all I can do is mailing this (at the risk of wasting your time with total useless crap ofcourse, in which case I apologize.) 1. Old kernel recovery When 'make install'ing a new kernel, a flag is raised (say, 'revert_on_fail') which is only cleared after a successful system initialisation. When the new kernel boots, a panic in this state or an unexpected reboot (reset after a system hang) would cause /kernel.old to be loaded on the next boot instead (maybe the same could work for /etc/rc.conf.old) This is actually more a question of where to store the flag than anything else. Julian made a rather hackish thing for Whistle, but I think we lost that with the advent of the new bootblocks. 2. Automatic file system checks In case of a powercycle or crash, it could be that a filesystem needs fixing. Now I don't know much about fs internals, but I guess that in most cases just answering 'Y' to fsck's questions will fix things. I would appreciate an option where an inconsistency would start up fsck in an "automatic" repair mode, with all actions logged and "undo" data being saved (in case manual review is needed). Alternatively it might be worth considering adding a "remote-single-user" capability: If an fsck fails, ifconfig the interfaces and start an sshd so people can get in remotely and fsck... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot process robustness
On Thu, Dec 28, 2000 at 03:31:55PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], "Walter W. Ho p" writes: [snip] 2. Automatic file system checks In case of a powercycle or crash, it could be that a filesystem needs fixing. Now I don't know much about fs internals, but I guess that in most cases just answering 'Y' to fsck's questions will fix things. I would appreciate an option where an inconsistency would start up fsck in an "automatic" repair mode, with all actions logged and "undo" data being saved (in case manual review is needed). Alternatively it might be worth considering adding a "remote-single-user" capability: If an fsck fails, ifconfig the interfaces and start an sshd so people can get in remotely and fsck... What if an fsck on /usr fails? Other than that, I love the idea! G'luck, Peter -- I am not the subject of this sentence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot process robustness
In the last episode (Dec 28), Peter Pentchev said: On Thu, Dec 28, 2000 at 03:31:55PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], "Walter W. Hop" writes: 2. Automatic file system checks In case of a powercycle or crash, it could be that a filesystem needs fixing. Now I don't know much about fs internals, but I guess that in most cases just answering 'Y' to fsck's questions will fix things. I would appreciate an option where an inconsistency would start up fsck in an "automatic" repair mode, with all actions logged and "undo" data being saved (in case manual review is needed). Alternatively it might be worth considering adding a "remote-single-user" capability: If an fsck fails, ifconfig the interfaces and start an sshd so people can get in remotely and fsck... What if an fsck on /usr fails? Other than that, I love the idea! Force-mount it read-only if necessary, or simply copy a static sshd into /sbin. Runnning fsck -y is the wrong solution, since if fsck can't fix an error automatically, something pretty bad has happened (physical media error, someone dd'ing onto the raw disk, etc).. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
In message [EMAIL PROTECTED], Dennis writes: Again, you miss the point. Spending dollars advertising is arguably a more valuable contribution than altering a few line of code or submitting a driver for some obscure card. It depends a lot on the goals of the project. FreeBSD has pretty good name recognition already, in the markets it's after. Sure. And without FreeBSD, your "contributions" are worthless, so you already got your share. That makes no sense. How can you "contribute" to something that doesnt exist? But FreeBSD *does* exist. The existence of FreeBSD is a necessary condition to make a contribution to it. Yup. But everything you sell that uses FreeBSD, you couldn't have sold without it. That's your fair share. Sure, but at the moment it enters the system, we are supposed to support, test and let it evoluate with the system. How to do that without source? Wrong again. WE support it. Once it enters the system, people will send questions to mailing lists about it, and that turns into work for all the maintainers. Windows has the driver for the intel ethernet card on their CD, but they dont support it. Yes, but they also come with a 32-bit protected memory system, and they don't support that either - just try to get a response to a bug report. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: -STABLE+vinum+smp+softupdates+CVSup(local CVS repo)==corruption?
No, I am just using vinum stripes. The problem seems to have fixed itself when I got a ufs_readwrite.c update from Matt after it was committed. This is an interesting problem, since I am not entirely sure what fixed it, if it is really fixed, etc... Sigh, oh well. -- David Cross | email: [EMAIL PROTECTED] Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: FreeBSD vs. Linux, Solaris, and NT
At 12:44 26/12/00 +0100, Marco van de Voort wrote: I ran into people at NASA who use Python because (beside being a good language) it isn't GPL. Pure paranoia. You don't have to share the code that is written IN Python. Only modifications TO python (if it were GPL) what if you read before you naswer? the guy said python isn't gpl'd, what seas are you swimming in? For legal and security reason they cannot share changes to code they make, so anything GPL is unusable. So are programs that run on Linux required to be open source? I need to know. You may only shared link to GPL'ed packages, and the rest is up to you. h'mmm' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Collecting waiting statistics (simulation question)
I hope you're patient to wait until 2019 to get an answer. or you'll probably correct your clock At 09:55 27/11/19 -0700, Jeff Rhyason wrote: Can anybody help me with a project I am working on? I am trying to simulate different memory allocation policies for a discrete event simulation course. Being the guy I am, I decided to collect some real statistics from a real system. The difficulty I've encountered is that I can't find how to make them accessible! Is there a way that I can log a large amount of statistics regarding kernel memory allocator activity and make that accessible to a user process? (Something like Solaris' crash(1m) and kmalog) Thanks in advance for any comments! -Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
Renaud Waldura wrote: I've got that FreeBSD gateway in a corner at my house, it works fine dandy but the constant noise (whirring fans, hard drives) gets on my nerves. What solutions have people explored to quiet down a computer system? (actual experience will be preferred over wild speculations). I'm already aware of PicoBSD, but I need more storage than just a floppy. Has anybody experimented with RAM cards? How about noise-proof enclosures? Let's review. The noise comes from the fans and the hard drive. The heat sources that require fans are the hard drive and the CPU. The fastest way to quieten your system is to remove the hard drive and all but one fan. As Warner mentioned, CF cards are a great way to go if you want to try this. He recently pointed out a CF-to-IDE adapter from TAPR, you can read more about this at http://www.tapr.org/tapr/html/Fcfa.html We have several NIC's around here (the New Internet Computer, see http://www.thinknic.com/ for details) and will be adding a couple of these so we can boot FreeBSD or NetBSD on them in the next little while. A NIC running FreeBSD on a silent CF disk strikes me as an ideal bedroom computer; you can leave it on all the time and just let the screen sleep when you're not using it. Another strategy that will help is to turn your computer case vertical. Provide plent of slots along the top of the case and near the bottom; the heat of the CPU will create a chimney effect providing cooling airflow over the CPU. Lastly, search for quiet fans from a large supplier. Most components don't use them because they cost as much as a dollar more than the noisy variety, but you can easily replace your noisy fans with higher quality replacements that run quieter. A good supplier will list the average sound level produced by each fan as well as the size, power requirements, and airflow provided. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Thinkpad Partition Problem Solved?
If memory serves me right, Joshua Goodall wrote: I came up with a very similar solution independently (although I chose a "reserved" partition number). You may also wish to (I did) patch boot0 for the cosmetic fix. Thanks. I was thinking about a patch for boot0, but decided I had to fight other fires. It is possible to rescue a 165'd [ATX] series thinkpad by booting an install floppy without an installed HD and hot-inserting the HD before the kernel loads - allowing you to change the partition number (have a fixit.flp or live CD handy). This is probably not very good for the HD, but it works. Been there, done that with my bricked T20. I'm not recommending that anyone do this, mostly because I don't want to take responsibility for frying someone's hard disk if something goes wrong. That's why I didn't add this to the text that Nik turned into the FAQ entry. There's not reason why sysinstall can't come with a tool to change the recognised partition number, is there? Apart from being pig-ugly nasty and implying another line in make.conf and patches to anything using disklabel.h or hardcoding values. Architecturally revolting. /usr/src/sys/boot/thinkpad/, anyone? :) I haven't had my caffeine yet this morning, so I'm not really thinking clearly, but my first reaction is that this is going to cause more problems than it solves. boot1 and boot2 as written will look only for certain partition types (normally just 0xa5), and unless we go around patching binaries from within sysinstall, it's going to be real hard to change these on a first-time CD-ROM (or network) install. Bruce. PGP signature
Re: Silent FreeBSD
In message [EMAIL PROTECTED] Wes Peters writes: : We have several NIC's around here (the New Internet Computer, see : http://www.thinknic.com/ for details) and will be adding a couple of these : so we can boot FreeBSD or NetBSD on them in the next little while. A NIC : running FreeBSD on a silent CF disk strikes me as an ideal bedroom computer; : you can leave it on all the time and just let the screen sleep when you're : not using it. The ideal bedroom computer wouldn't have a monitor either because that makes a lot of noise. The I-Opener looks very promising here, but only if you have one of the cheap units. I'd hate to buy one now at full price given how hard they are to hack. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
just wanna jump in while it's hot... I work for a commercial company, and I did what I could to convince people that *BSD is the way, and we're happily using FreeBSD. now, we modiy the kernel sources, and this is a problem since this changes the way people build the kernel. what we did is provide procedures to modify the kernel config file (GENERIC for example), conf/files and so, in order to build the kernel. While this is ok, it doesn't sound perfect to me. I'd love it if thrid party modifications were intended in the kernel sources. I'm ready to do the work. mainly, I'd propose some patches to config so that thrid party additions/modifications are made easier [the real problem is that when many companies modify the kernel. If they all do it as we do, then it's impossible. but if it's provided by the system, then it's easier]. regards, mouss At 21:45 27/12/00 +0200, Taavi Talvik wrote: On Wed, 27 Dec 2000, someone on freebsd-hackers wrote: They dont want your stinking binary contributions. Get used to it. Not suprisingly you're both wrong. Many binary-only ports exist in the FreeBSD ports tree. World is not black and white. There are binary ports (for example netscape). But there are no well defined procedures for including binary device drivers with FreeBSD. Even building modules outside /usr/src/sys/modules is not easy task. What about asking for additional driver modules on fresh install? Lack of well defined procedures for inclusion of binary only drivers is definitely our shortcoming. We are moving to right direction (kernel modules etc.), but we are not there yet. There are reasons for binary only drivers. For example - ADSL, it is coming more common, but supply chain is just too long. Card manufacturers are helpful, they provide programming information, but they are not free, they just can't ignore chipset suppliers (who are not ready for releasing some firmware yet). best regards, taavi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Editors/Reviewers? (was Re: Collecting waiting statistics (simulation question))
I hope you're patient to wait until 2019 to get an answer. or you'll probably correct your clock My apologies to everybody on the list who had this screwing up their mailboxes. ;) Incidentally, to anyone who was following this thread in August, my report is finished and I will be putting it out soon! If anyone could lend some time editing and reviewing before I put it up, please let me know - I would be all to happy!! -Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch oflicence Jihad crap
On Wed, 27 Dec 2000, Jeremiah Gowdy wrote: The amount of free Windows software is much less than what is available for Unix. I almost choked to death on my Submarina Sandwich when I read this. I think you need to take a step back and think a bit on this one. Do you really think the 4000-5000 ports in the ports tree and the other misc free applications on the net outnumber the hundreds of thousands of free Windows applications ? Even if you don't count Shareware, which you really should, the number of free Windows applications outnumbers the number of free Unix applications 10 to 1. Now, the power, importance, usefulness, etc of the Unix apps may be superior, but the "amount" or number of free Windows applications is certainly not "much less" than what is available for Unix. It's much much more. Giving Windows a :( for Free Applications is absolutely unbelievable. Oh, and if you're going to include all of the Linux binary compatible applications as "free software for FreeBSD", then you would have to include in Windows 2000's count all of the DOS binaries it is compatible with, which far far outnumbers any amount of software written for any operating system ever. The amount of freeware produced between MSDOS 3 and MSDOS 6 is uncountable, and much of it is compatible with Windows 2000. Uuuuh, I'm gonna have to agree with Murray that there is a complete dearth of free software for Windows. Go search shareware.com, or Tucows, or any of the other Windows-centric software sites, and just TRY to find most of the same tools or applications you take for granted on your Unix box. I do all the time, and wished to hell I was managing thousands of BSD boxes instead of Windows. The free software either doesn't exist, is of very poor quality, or you have to pay for it. While "free as in beer" software for Windows is fairly prevalent, GOOD free software is quite rare, and open-sourced software for Windows is very rare indeed. The Windows-programmer mindset that is still very prevalent, even in this "open-source" day and age, is "I'll make this proprietary piece of software, of which there are forty different other pieces of software almost like it, not release any code, and you're gonna pay me for it one way or another if you want to use it". -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64 and PowerPC under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch oflicence Jihad crap
On Wed, 27 Dec 2000, Jeremiah Gowdy wrote: If you slant your judgement so far against the other products, it makes you sound like you don't know what you're talking about (no offense). You need to point out the pros and cons of ALL three systems. Not just the pros of FreeBSD and the cons of Linux/Windows. Indeed. Not doing this makes the FreeBSD crowd look like a bunch of kids who shouldn't be taken seriously. Not only does this weaken FreeBSD (hey, not my problem), but it also weakens the opinion people have of the free unix systems in general ... which DOES create a problem for me (Linux is my fulltime job). regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Collecting waiting statistics (simulation question)
At 09:55 27/11/19 -0700, Jeff Rhyason wrote: Is there a way that I can log a large amount of statistics regarding kernel memory allocator activity and make that accessible to a user process? (Something like Solaris' crash(1m) and kmalog) The quick solution is to config -g your kernel, and extract statistics via gdb gdb -x extract-reset-script -k -wcore unstripped-kernel /dev/mem where extract-reset-script prints the current values, resets, and then exits. Otherwise, write a character device driver and matching user land facility to extract the information you want. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
testing..please ignore
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
testing ..again..escuse-me
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AMD System Management driver and Newbus
Nicolas Souchu writes: Gasp! This is part of my fault. I shouldn't have left this old style driver in the tree :( You should have contacted me, I would have adviced you. Takanori is right, you should look at intpm to get info about how to cleanly newbusify your driver. This is what I'm currently doing for alpm ;) By the way, is someone working on the VIA SMBus support? Or do I start it? FWIW, I've just newbus'ified the alpm driver. See http://people.freebsd.org/~gallatin/alpm.diff Somebody with an x86 AMD should probably test it.This seems to "sorta" work on my API UP1000 (which is an alpha). Eg: FreeBSD 5.0-CURRENT #23: Thu Dec 28 11:24:33 EST 2000 [EMAIL PROTECTED]:/.amd_mnt/muffin/export/ari_scratch2/gallatin/c urrent/sys/compile/UP1000 UP1000 API UP1000 598 MHz, 598MHz 8192 byte page size, 1 processor. CPU: major=11 minor=8 extensions=0x307BWX,FIX,CIX,MVI,PRECISE OSF PAL rev: 0x100010002013e ... alpm0: AcerLabs M15x3 Power Management Unit port 0x1040-0x105f,0x1000-0x103f at device 17.0 on pci0 smbus0: System Management Bus on alsmb0 smb0: SMBus general purpose I/O on smbus0 ... # ./smb_detect 58 found. 74 found. 78 found. 90 found. a0 found. a8 found. If I beat on lm.c from http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/lm.c enough and use 0x90 as cmd.slave, I can get the CPU temp of 41 C. This is the same as firmware gives me, which is encouraging. As you can probably tell, I don't know enough about smb to fight my way out of a wet paper bag. Is there an SMB savy person out there who can take me by the hand and help me figure out where the fan speed and voltage is lurking and how to read it? Cheers, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mtrr and stepping=2 K7's
On Thu, Dec 28, 2000 at 03:54:52AM -0800, Mike Smith wrote: Are there any known issues with MTRR on early K7's? What do you mean with 'early'? CPU: AMD Athlon(tm) Processor (756.41-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x621 Stepping = 1 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc040AMIE,DSP,3DNow! real memory = 134152192 (131008K bytes) avail memory = 126918656 (123944K bytes) Preloaded elf kernel "kernel" at 0xc0397000. Pentium Pro MTRR support enabled works great for me on 4-stable and a G200. XFree 4.x I'm not aware of any, no. A cursory read of the current Linux MTRR code doesn't suggest that they treat them specially either. Using XFree86 4.0.x on an early 550 Mhz K7 (equipped with 256Megs of sdram) causes this machine to lock up, unless I comment out the K7 mtrr enabling stuff in i686_mem.c. This happens with any VGA card that I drop in the box, (PCI bus voodoo4, a Rage IIc ATI card, and the Matrox G400). -- Wilko Bulte Arnhem, the Netherlands [EMAIL PROTECTED] http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch of licence Jihad crap
At 17:07 28/12/00 -0200, Rik van Riel wrote: On Wed, 27 Dec 2000, Jeremiah Gowdy wrote: If you slant your judgement so far against the other products, it makes you sound like you don't know what you're talking about (no offense). You need to point out the pros and cons of ALL three systems. Not just the pros of FreeBSD and the cons of Linux/Windows. Indeed. Not doing this makes the FreeBSD crowd look like a bunch of kids who shouldn't be taken seriously. Not only does this weaken FreeBSD (hey, not my problem), but it also weakens the opinion people have of the free unix systems in general ... which DOES create a problem for me (Linux is my fulltime job). OS comparison is hard and requires much resources and is after all a loss of time and energy. things get outdated very soon. now, one can still write a paper such as the one discussed here, without being asked to prepare a phd on which OS does what. I've seen more "fucking" stuff in the linux circles than in *BSD ones, and I've never found that this did any bad to anything. just check all those "doing this with linux" books. one of my favourites is "Linux application development" where the authors seem to acknowledge that everything has been invented in linux (so many "linux does a well a job at this", when it's an old unix functionality). But I'm not gonna sue'em. after all, win* books also keep claiming some of the super-modern-ntfs-andwhat-you-want things, and those guys at other companies do the same. so, that's likely to be a game, no? yes, if we all make efforts to make this world better, it'll be good. but we first have to agree, and that is the hard step cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mtrr and stepping=2 K7's
By "early" I meant the cpu and mainboard were bought as soon as K7's showed up in the OEM channel. I'm beginning to suspect it my be a mainboard problem, though I'm not sure how that would tie in with mtrr. Have to see if I can scrounge up a different motherboard, or see if there is a bios upgrade I can flash... Thanks, On Thu, 28 Dec 2000, Wilko Bulte wrote: On Thu, Dec 28, 2000 at 03:54:52AM -0800, Mike Smith wrote: Are there any known issues with MTRR on early K7's? What do you mean with 'early'? CPU: AMD Athlon(tm) Processor (756.41-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x621 Stepping = 1 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc040AMIE,DSP,3DNow! real memory = 134152192 (131008K bytes) avail memory = 126918656 (123944K bytes) Preloaded elf kernel "kernel" at 0xc0397000. Pentium Pro MTRR support enabled works great for me on 4-stable and a G200. XFree 4.x I'm not aware of any, no. A cursory read of the current Linux MTRR code doesn't suggest that they treat them specially either. Using XFree86 4.0.x on an early 550 Mhz K7 (equipped with 256Megs of sdram) causes this machine to lock up, unless I comment out the K7 mtrr enabling stuff in i686_mem.c. This happens with any VGA card that I drop in the box, (PCI bus voodoo4, a Rage IIc ATI card, and the Matrox G400). -- Wilko Bulte Arnhem, the Netherlands [EMAIL PROTECTED] http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
Afaik, anybody can spend any amount of advertising dollars he wants. Again, you miss the point. Spending dollars advertising is arguably a more valuable contribution than altering a few line of code or submitting a driver for some obscure card. Well, I don't think so. Good quality and many drivers are very important for an OS. (think about e.g. win95 vs NT) Where money is, there are 3rd party vendors. Wave a networking budget, and ten jump in your neck. Thousands of users use FreeBSD enhanced with our "contributions". We spend tens of thousands of dollars advertising them, indirectly advertising FreeBSD in the process. Sure. And without FreeBSD, your "contributions" are worthless, so you already got your share. That makes no sense. How can you "contribute" to something that doesnt exist? You mean it is a Schrodingers cat problem? :-) It is a simple dependancy thought experiment: A depends on B. There is only 50% chance that B exists, and you can't determine if B exists exactly. What is the status of A ... The existence of FreeBSD is a necessary condition to make a contribution to it. Yes, but without it existance this would be academical. People buy products because they think that they are worth the price. The fact that so many people are willing to pay for the enhancements we provide is prima facia evidence of our contribution. Sure, but at the moment it enters the system, we are supposed to support, test and let it evoluate with the system. How to do that without source? Wrong again. WE support it. Then YOU distribute it. Windows has the driver for the intel ethernet card on their CD, but they dont support it. At least TRY to grasp some concepts here, you might learn something. That is why you have to click sixteen licenses to install something. Not worth the hassle IMHO. Im trying to give analogies that even you can understand, but its very difficult :-) Stop being so childish. Yes, you can do it perfect, but than you have a reviewing board that does QA for packages, and allow some to be distributed and some not. FreeBSD can't afford that, and it would be undemocratic, unclear anyway So that is why the policy is no binary distribution parts, probably. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
On Thu, Dec 28, 2000 at 07:33:03PM +0100, mouss wrote: I work for a commercial company, and I did what I could to convince people that *BSD is the way, and we're happily using FreeBSD. now, we modiy the kernel sources, and this is a problem since this changes the way people build the kernel. what we did is provide procedures to modify the kernel config file (GENERIC for example), conf/files and so, in order to build the kernel. While this is ok, it doesn't sound perfect to me. I'd love it if thrid party modifications were intended in the kernel sources. I'm ready to do the work. mainly, I'd propose some patches to config so that thrid party additions/modifications are made easier [the real problem is that when many companies modify the kernel. If they all do it as we do, then it's impossible. but if it's provided by the system, then it's easier]. If your company's infrastrucutre changes are made in a way that if the project adopted them it would help binary support, I'm sure that would be accepted. ie. if we just made function foo() more generic and then you could simply provide a KLD, that would make everyones life easier. Sometimes these things aren't that simple, though. :- -- Bill Fumerola - security yahoo / Yahoo! inc. - [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
At 10:12 28/12/00 -0700, you wrote: Lastly, search for quiet fans from a large supplier. http://www.quietpc.com/ I haven't bought any stuff from them, yet, so I can't vouch other than for their existence. Dave :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: -STABLE+vinum+smp+softupdates+CVSup(local CVS repo)==corruption?
On Thursday, 28 December 2000 at 14:03:31 +, Josef Karthauser wrote: On Tue, Dec 26, 2000 at 05:30:09PM -0500, David E. Cross wrote: I have run across a problem since updating to -STABLE a week or so ago... my CVS vinum partition would go corrupt after a few updates. I have been running with no softupdates on my system for a day now and no problems. Has anyone else seen this? Is that with vinum raid 5? If so there are know problems with raid 5 and you should either help Greg to fix them or avoid raid 5 like the plague lest your data corrupts itself. I can't recall any data corruption. The problems you were seeing were panics where buffer headers got corrupted, and they happened to a very small number of people (not including myself, which makes it difficult to catch them). I think I might have a solution there. It's currently being tested in -CURRENT, but before that I'd like to find somebody who can reproduce the original problem. I certainly don't think it's a reason to avoid RAID-5, like the plague or otherwise. You'll notice that David's problem has nothing to do with that, nor with Vinum at all, it would seem: On Thursday, 28 December 2000 at 11:52:03 -0500, David E. Cross wrote: No, I am just using vinum stripes. The problem seems to have fixed itself when I got a ufs_readwrite.c update from Matt after it was committed. This is an interesting problem, since I am not entirely sure what fixed it, if it is really fixed, etc... Indeed. Was this just the CVS repo? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
On Thu, 28 Dec 2000, Bill Fumerola wrote: If your company's infrastrucutre changes are made in a way that if the project adopted them it would help binary support, I'm sure that would be accepted. ie. if we just made function foo() more generic and then you could simply provide a KLD, that would make everyones life easier. Still, I personally believe, that "core" or general "freebsd community" should explicitly state, that support for binary drivers and support for easier inclusion of binary driver or just third party driver is eagerly encouraged. And as much as possible, easy inclusion of binary drivers sould be kept in mind whether makeing changes to /usr/src/Makefile or kernel interfaces or even discussions on the freebsd lists. This is quite similiar to issue of freebsd native binaries or linux emulated binaries. When linux vs. freebsd question arises in press we (or Jordan mostly :) ) says, that it does'nt matter - it just works. Why we do not take similiar position on binary drivers - they just work, and freebsd community just encourages this? best regards, taavi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch of licence Jihad crap
Uuuuh, I'm gonna have to agree with Murray that there is a complete dearth of free software for Windows. Go search shareware.com, or Tucows, or any of the other Windows-centric software sites, and just TRY to find most of the same tools or applications you take for granted on your Unix box. I do all the time, and wished to hell I was managing thousands of BSD boxes instead of Windows. The free software either doesn't exist, is of very poor quality, or you have to pay for it. While "free as in beer" software for Windows is fairly prevalent, GOOD free software is quite rare, and open-sourced software for Windows is very rare indeed. He said, the "amount of free software". He didn't say the amount of free GOOD software, the amount of useful applications, etc. He said AMOUNT of FREE software. He didn't say the AMOUNT of OPEN SOURCE software. Saying that there is more _free software_ for FreeBSD than there is for Windows is insane. If you're talking about how useful it is, or whether it's open source, you need to specify those things. But anyone worth their salt would choke on the general statement, "there is more free software for FreeBSD than there is for Windows". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Thread DIES [Re: ssh - are you nuts?!? ]
On Wed, Dec 27, 2000 at 04:04:36PM -0800, [EMAIL PROTECTED] wrote: Bill Fumerola, who states that security policy information is un-available. However, I might refer his comment to the Security Officer instead, if Bill feels this appropriate. for the public record: Its unavailable in a "I don't know of any place that it is currently stored publicly, so I have no idea how JmJr was making references to it"-way as opposed to a "It's super-secret-elite and you can't have it"-way. -- Bill Fumerola - security yahoo / Yahoo! inc. - [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Thread DIES [Re: ssh - are you nuts?!? ]
On 28 Dec, Bill Fumerola wrote: On Wed, Dec 27, 2000 at 04:04:36PM -0800, [EMAIL PROTECTED] wrote: Bill Fumerola, who states that security policy information is un-available. However, I might refer his comment to the Security Officer instead, if Bill feels this appropriate. for the public record: Its unavailable in a "I don't know of any place that it is currently stored publicly, so I have no idea how JmJr was making references to it"-way as opposed to a "It's super-secret-elite and you can't have it"-way. My assumption was the former. Thank you for your response. I will follow up with the SO now. Thanks Again, Jessem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A couple of Junior Hacker tasks...
Dan Langille wrote: On 28 Dec 2000, at 9:36, Poul-Henning Kamp wrote: which are good candidates for people looking for a good and simple task to do for FreeBSD. How do we know which are the "good and simple" ones? Rely on an expert to tell you they are so. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
In message [EMAIL PROTECTED] Taavi Talvik writes: : On Thu, 28 Dec 2000, Bill Fumerola wrote: : : If your company's infrastrucutre changes are made in a way that if : the project adopted them it would help binary support, I'm sure that would : be accepted. : : ie. if we just made function foo() more generic and then you could : simply provide a KLD, that would make everyones life easier. : : Still, I personally believe, that "core" or general "freebsd community" : should explicitly state, that support for binary drivers and support for : easier inclusion of binary driver or just third party driver is eagerly : encouraged. And as much as possible, easy inclusion of binary drivers : sould be kept in mind whether makeing changes to /usr/src/Makefile or : kernel interfaces or even discussions on the freebsd lists. Core has stated in the past a strong desire for developers not to break kernel interfaces within minor releases. : Why we do not take similiar position on binary drivers - they just : work, and freebsd community just encourages this? That certainly is the goal. Sometimes we achieve the goal, other times we fall short. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
Again, you miss the point. Spending dollars advertising is arguably a more valuable contribution than altering a few line of code or submitting a driver for some obscure card. Key word here: "arguably", meaning "can be argued indefinitely", and loosely translates to "drop this argument - it's pointless." All I can say here is that I've suggested to my clients that they do NOT use the "WAN card in a FBSD box from certain companies" solution, due to my experience on these lists... Keep in mind that a lot of the "few lines of altered code" here and there are what keep your clients' networks safe. I couldn't care less about your advertising budget if some script kiddie got in and tap-danced all over my database server due to an un-fixed bug in telnetd. Spending dollars is good, but not pissing off potential clients by insulting people is better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
