Re: What about rc.shutdown.local?
Jan Grant writes: > > Better still would be /usr/local/etc/rc.d/*.sh called automatically > > with parameter stop. To do so, insert > > This is all nice (BTDT) although I find the *.sh pattern quite annoying, > due to the alphabetisation issue. When I make these mods I tend to use > the SysV-style S* and K* patterns - that means you get to control the > order of startup _and_ shutdown (which might need a different sequence). This seems trivial. I name the scripts with two-digit prefixes and an underscore so that I can have meaningful names and an easy way to control the sequence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: "iowait" CPU state
> Thank you! This gets the me disk %busy, which is one of the things I > was looking for. Now, can anyone tell me how to tell what percentage of > processor time is being spent waiting for disk I/O to complete? Uh, none? If there is disk I/O pending, the processor just runs a different process... am I missing your question? Are you maybe asking what percentage of time a given process spends waiting on disk I/O, thather than doing processing? A rough approximation of this would be (system time/(user time + system time))*100. Using the wall time would not take other processes use of the CPU into account, but you might consider using that anyway, depending on why you want the statistic. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aio_read() broken functionality.
> > * Dmitry Sychov <[EMAIL PROTECTED]> [001109 13:06] wrote: > > Greetings. > > > > According to manual the aio_offset field of the "aiocb" structure > > is ignored in the aio_read() call. So one can read the file only from > > beginning. Very bad for me. :-( > > > > Will this bug be fixed in FreeBSD 5.0? > > Hrm, parsing through the kernel code it looks like this is just a > bug in the manpage, basically aio_offset doesn't look like it's > ignored, can you try to use aio_offset and report if it works or > not. > > Please submit some test code if it doesn't. > > -- > -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] > "I have the heart of a child; I keep it in a jar on my desk." > > > 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: Repeatable STL core with -pthread
> > The program will core after about 10 seconds, every time.
> > It would appear that there is an issue with some low-level allocator in the
> > STL as shipped in 4.x.
>
> Dude. The STL implementation that ships with g++ isn't thread safe.
> In fact, if you read the STL portion of the C++ specification, you will
> notice that threads are not mentioned at all. The only guarantees made
> by the STL are that operations will complete within certain performance
> guidelines.
>
> As a safety tip, the string implementation in the g++ implementation
> isn't thread safe either. It uses a shared buffer scheme ("char*
> string->rep") to reduce memory consumption & improve performance. This
> is in opposition to "deep copy" style libraries, like the SGI STL, that
> work in threaded environments.
>
> Because of the way the C++ standard is written, commercial STL
> implementations, such as the Rogue Wave library that comes with the Sun
> C++ compiler, suffer from the same threading problems.
Use the STL that is used by the Cyrus ACAP server, which is the
one from the Moscow Center for Supercomputing Activities.
There is an issue in GNU C++ with an assumption by the ACAP
code about dynamic virtual base class construction order at
load time, but it can be handled by ensureing that the link
order ensures that classes are linked lowest level to highest
level, in reverse dependency order.
The Moscow STL also has a large number of bug fixes; Jeremy
Allison (of Samba) and myself spent a fair amount of time
adding in support for Draft 4 pthreads, and making it work
on FreeBSD at the time (which included patches to FreeBSD of
the time to bring it into compliance with Draft 4). Without
these, you will probably have a hard time making the STL code
work on both modern FreeBSD, and on, say, IRIX, which is still
Draft 4. But if this is not a portability issue for you, I
would suggest using that STL instead.
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: "iowait" CPU state
In article <[EMAIL PROTECTED]> you write: >> > not how busy the disks are. I want relative data, not absolute. >> >> systat -vmstat? > >Thank you! This gets the me disk %busy, which is one of the things I >was looking for. Now, can anyone tell me how to tell what percentage of That was something I was looking for some time ago as well, so I wrote and submitted the patch for %busy :-). It's not 100% accurate, see the systat source for the details. This patch will add an extra row 'queue' displaying the amount of commands queued for the disk: Index: vmstat.c === RCS file: /home/freebsd/CVS/src/usr.bin/systat/vmstat.c,v retrieving revision 1.38.2.2 diff -u -r1.38.2.2 vmstat.c --- vmstat.c2000/07/02 10:03:17 1.38.2.2 +++ vmstat.c2000/07/06 22:07:57 @@ -335,6 +335,7 @@ mvprintw(DISKROW + 2, DISKCOL, "tps"); mvprintw(DISKROW + 3, DISKCOL, "MB/s"); mvprintw(DISKROW + 4, DISKCOL, "%% busy"); + mvprintw(DISKROW + 5, DISKCOL, "queue"); /* * For now, we don't support a fourth disk statistic. So there's * no point in providing a label for it. If someone can think of a @@ -841,4 +842,5 @@ putlongdouble(transfers_per_second, DISKROW + 2, c, 5, 0, 0); putlongdouble(mb_per_second, DISKROW + 3, c, 5, 2, 0); putlongdouble(device_busy * 100 / elapsed_time, DISKROW + 4, c, 5, 0, 0); + putlongdouble(now->dinfo->devices[di].busy_count, DISKROW + 5, c, 5, 0, 0); } >processor time is being spent waiting for disk I/O to complete? Hmm, I thought the CPU never spends time waiting for disk I/O, it just schedules another process? How should iowait% be calculated then? Is the percentage of time the CPU was idle and one or more processes were blocked on disk I/O? Arjan -- Arjan de Vet, Eindhoven, The Netherlands <[EMAIL PROTECTED]> URL: http://www.iae.nl/users/devet/ for PGP key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Legacy ethernet cards in FreeBSD
On Fri, 10 Nov 2000, Nate Williams wrote: > > : 3Com 3c503ISA > > > > I think so. The ed driver supports this > > I'm pretty sure the ed driver doesn't support the 503. I think we > dropped support for the 503 a *REALLY* long time ago (2.1 days...) How difficult is it to check the source? The 3c503 is supported. You're thinking of the 3c501 and the 3c505. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Legacy ethernet cards in FreeBSD
> > > : 3Com 3c503ISA > > > > > > I think so. The ed driver supports this > > > > I'm pretty sure the ed driver doesn't support the 503. I think we > > dropped support for the 503 a *REALLY* long time ago (2.1 days...) > > You are probably confusing it with the 501 or 505. The 503 is basically > an NE1000 (with a better probe routine). You're indeed correct. It was the 501 that we dropped support for, sorry for the false information. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Legacy ethernet cards in FreeBSD
> > : 3Com 3c503ISA > > > > I think so. The ed driver supports this > > I'm pretty sure the ed driver doesn't support the 503. I think we > dropped support for the 503 a *REALLY* long time ago (2.1 days...) You are probably confusing it with the 501 or 505. The 503 is basically an NE1000 (with a better probe routine). -- ... 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: Legacy ethernet cards in FreeBSD
> : 3Com 3c503ISA > > I think so. The ed driver supports this I'm pretty sure the ed driver doesn't support the 503. I think we dropped support for the 503 a *REALLY* long time ago (2.1 days...) > : DEC EtherworksISA > : DEC DE205 ISA > > don't know about these. lnc driver supports them maybe ? Use to be the le driver supported them, but apparently it's broken now. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Legacy ethernet cards in FreeBSD
[Charset iso-8859-1 unsupported, filtering to ASCII...] > Dear All, > > Last night I cvsupped my trusty old Compaq Deskpro XL 6200 from 4.0-release > to 4.2-beta. As part of that process, I seem to have lost support for the > on-board NIC (lnc0: PCNet/PCI Ethernet Adapter, PC-net-32 VL-Bus). Ok, "seem to have lost support" is about the vaguest thing you could have said. I've killed people for less. Please explain in detail how you arrived at the conclusion that the card was no longer supported. Show us the dmesg output from your machine. Explain what you tried to do and what results you observed. Don't just say "it doesn't work." You've not going to help anyone that way. FreeBSD 4.2 has a new driver for AMD PCnet/PCI devices, in particular the 10/100 cards, because the lnc driver runs these cards in 16-bit LANCE compatibility mode which really impairs their performance. Did you check to see if a pcn0 device was detected? Did you attempt to use it? If not, why not? If so, what happened? > What is the newest version of FreeBSD that will propely support that card? You're soaking in it. > If there are people who are cleaning up the support for older network cards > in FreeBSD I'd like to help out by sending you my old NICs. It's not like > they're any good to me without OS support. > > Please contact me off-list for any of the following cards: > > 3Com 3c503ISA Should work with the ed driver, *provided* you get its I/O address set correctly so that the ed driver will detect it. I haven't used one of these since FreeBSD 2.x though. > DEC EtherworksISA > DEC DE205 ISA Don't know about these. > SMC EtherEZ ISA Should also work with the ed driver, though you may have to turn off plug and play mode using the SMC EZSetup utility. > RealTek "TP-Link" PCI If this is a 10mbps card, it should be an NE2000 clone, and will work with the ed driver. If it's a 100Mbps card, it should work with the rl driver. > I'll be happy to try out patches for the lnc driver to fix the problem of > the Deskpro, or to give remote access to it if you want to work on it. I'd be happier if you told me whether the pcn driver works or not. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Legacy ethernet cards in FreeBSD
In message <[EMAIL PROTECTED]> "Koster, K.J." writes: : 3Com 3c503ISA I think so. The ed driver supports this : DEC EtherworksISA : DEC DE205 ISA don't know about these. lnc driver supports them maybe ? : SMC EtherEZ ISA ed driver. : RealTek "TP-Link" PCI Don't know about this one. : As far as I've been able to determine, none of these work properly. In : particular, the RealTek card gets detected and pretends to work, but loses : the link after a bit (The link status LED goes out, and I need to reboot the : box.) Read Bill Paul's glowing reviews of the realtek hardware in the rl driver :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: printf()
In message <[EMAIL PROTECTED]> Zhenhai Duan writes: : Does the kernel function printf() flushes the output immediately, or it is : possible some data is buffered somewhere and gets lost without printing : to the console? like the corresponding funtion in the c library. Yes. It can be buffered, but that's a driver level thing. I've seen serial consoles where things crashed after a printf I put in and never saw. I've not seen anything similar on video consoles. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What about rc.shutdown.local?
> > > It would be nice to have a /etc/rc.shutdown.local called by > > > /etc/rc.shutdown, > > > to implement custom shutdown procedures. This is currently done by > > > editing rc.shutdown, but you have to remember about it when you run > > > mergemaster. > > > > Better still would be /usr/local/etc/rc.d/*.sh called automatically > > with parameter stop. To do so, insert > > This already happens... at least in rc.shutdown v1.15: > > # $FreeBSD: src/etc/rc.shutdown,v 1.15 2000/10/20 20:26:05 ache Exp $ I was looking for a similar thing yesterday, and had to roll my own. The problem with the /usr/local crap is that it assumes that anything I'm going to install will be put into the /usr/local. The basic problem with this assumption (and of the runtime linker not seeing shared libraries in directories that are not in ldconfig, but were used in the build process to link successfully, and have their paths therefore stored in the binary) is that it assumes that I will never have a conflict with the system. Unfortunately, the ports system likes to use /usr/local to dump ports in, so this makes for a certain amount of developement confusion. When I want to develop a program on a FreeBSD system to deploy on a FreeBSD system, I will install all sorts of ports on my developement machine, but I will install nothing but the code I wish to deploy on my deployment machine. This means that the deployment code may infact use some of the same libraries and other binaries and data and so on that result from the ports system installing packages and ports, BUT it can NOT depend on these libraries being present in the deployment environment. This means that my deployment code my target a different directory hierarchy. The "ldconfig" issue aside (it's a can of worms, including that I could end up linking system components against my developement components because of ldconfig, even though I will later move or delete the build product), this is a real problem. For the startup stuff, at least you can wedge it with a /etc/rc.local; I know that it's "preferred" that I put my code and the ports code into the same namespace, but it is not "preferred" by me, nor is it really practical to do an extreme audit of every bit of code to make sure that I'm not getting a header file or something "accidently" by way of /usr/local. Worse, what if my deployment system is not FreeBSD? I know, I can hear the cries of "Heresy!" from here. I need to ensure that I can build out my source tree without dependency on the host system at all, at least as far as things in addition to POSIX interfaces and the libraries that implement them, let alone crap that some port happens to import "behind my back" to satisfy some third or fourth order dependency. So for FreeBSD, it would be useful to have an rc.shutdown.local which corresponds to rc.local, and the "preference" of the style police be damned. It seems to me that FreeBSD is setting itself up to be a system on which all working software needs to be integrated into the ports system, and this won't work at all for commercial or role modularized code. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: printf()
> A simple question: > > Does the kernel function printf() flushes the output immediately, or it is > possible some data is buffered somewhere and gets lost without printing > to the console? like the corresponding funtion in the c library. There is no buffering comparable to that of the stdio package; in other words, there is no such thing as an fflush() or setbuf() call. There has been some discussion of bufering of console output, with the buffer list to be used as a synchronization point, so that SMP systems, kernel threads, and interrupt handlers can't stomp on each other when one is in the middle of console I/O; should that work be done and incorporated, the console I/O will definitely be buffered, in the stdio sense, and a "spin until queue drains, yielding to the console output routine" may find its way in, as an aid to debugging kernel problems, which could otherwise be hidden by the queueing: a kernel fflush(). As things currently sit, it's possible to take an interrupt in the middle of output, and truncate it, if the interrupt handler has a bug that forces it into a tight loop, or otherwise locks up the machine. Similarly, output in an interrupt handler might (rarely) stomp in the middle of output in progress from elsewhere; console output at interrupt level is discouraged. Depending on the console output you are talking about, if it's coming from user space, all bets are off: user space console I/O may be buffered by whatever program doing the output, and some programs which output to the console have very long latencies, which you might also see (e.g. syslogd). Console messages that are sent from the kernel are usually sent to the diagnostic log. This is the log reported by dmesg, and is implemented using a buffer in memory, which is expected to survive over a boot. Some BIOS RAM test methods used to prevent this; I am unsure of how this is stored over reboots in the current code, and whether it is reliable or not on particular hardware. This is the information that is reported by the "dmesg" command. Finally, if you are talking about the console log, those outputs are inddeed buffered, through syslog. In addition, the commits of this data to the log file are not entirely synchronous. This means that you can not really depend on the console log contents to be 100% accurate at any given instance. So if what you are trying to do is diagnose a system crash from the console log in /var/messages (for example), then you will be out of luck. If dmesg data survives reboots for you, then you will be much happier using that instead of the console log (default: /var/log/messages). I hope this was useful; there really is very little documentation that is accurate about this type of area of FreeBSD internals, so it was probably OK for you to post your question here rather than questions, even though you are probably asking about what you suspect is your problem, instead of asking your real question. Hope this helps, and hope anyone who has any corrections to this wil provide them, since this type of documentation needs to be collected somewhere, and the mailing list archives seem to be the most appropriate place. Maybe we can set up an arch-doc list, which we can cross-post these responses to via Bcc:, without incurring the wrath of the mailing list manager? An archive of such things (my contributions in this area are minor, trust me) would be a good thing; PHK posted a nice internals description the other day that I would not mind having archived for eternity, without it taking up space in my email archive. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
On Fri, 10 Nov 2000, Nick Hibma wrote: > This makes sense as the adapter is not a ful controller, just a > cheapo interface. > > You cannot select the SCSI id from the USB driver. Hmm.. Since I was looking for a "true" USB-SCSI controller, obviously this thing won't work. If it only works with devices set to ID 0, it will never work with a SCSI ZIP drive which only has settings for ID 5 or 6 (which is one thing I would use it with). Do the Shuttle-based USB-SCSI adapters have the same limitation? -- 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: Legacy ethernet cards in FreeBSD
"Koster, K.J." wrote: > > Dear All, > > Last night I cvsupped my trusty old Compaq Deskpro XL 6200 from 4.0-release > to 4.2-beta. As part of that process, I seem to have lost support for the > on-board NIC (lnc0: PCNet/PCI Ethernet Adapter, PC-net-32 VL-Bus). > > What is the newest version of FreeBSD that will propely support that card? > > If there are people who are cleaning up the support for older network cards > in FreeBSD I'd like to help out by sending you my old NICs. It's not like > they're any good to me without OS support. > > Please contact me off-list for any of the following cards: > > 3Com 3c503ISA should be ok with the ed driver, for correct values of irq and io range > DEC EtherworksISA > DEC DE205 ISA > SMC EtherEZ ISA ditto > RealTek "TP-Link" PCI > > As far as I've been able to determine, none of these work properly. In > particular, the RealTek card gets detected and pretends to work, but loses > the link after a bit (The link status LED goes out, and I need to reboot the > box.) > > I'll be happy to try out patches for the lnc driver to fix the problem of > the Deskpro, or to give remote access to it if you want to work on it. > > Kees Jan -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
This makes sense as the adapter is not a ful controller, just a cheapo interface. You cannot select the SCSI id from the USB driver. Nick On Fri, 10 Nov 2000, James FitzGibbon wrote: > * Nick Hibma ([EMAIL PROTECTED]) [001109 17:31]: > > > Hm, I missed the zip story. You seem to have all the bits that are > > necessary in your kernel. > > > > Could you compile your kernel/module with UMASS_DEBUG defined and send > > me the output after an attach? > > As it turns out, I got it working, but only when the device is on SCSI ID 0. > Any other SCSI id and the device is not found when I run 'camcontrol rescan > 0' > > The output is rather large, so I put it on a web server: > > http://people.targetnet.com/~james/dmesg.plugin > http://people.targetnet.com/~james/dmesg.rescan > > (plugin is the dmesg output when I plugged it into the USB port, and rescan > is the additional output when I ran camcontrol rescan 0). > > Thanks. > > -- > j. > > James FitzGibbon [EMAIL PROTECTED] > Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aio_read() broken functionality.
> According to manual the aio_offset field of the "aiocb" structure > is ignored in the aio_read() call. So one can read the file only from > beginning. Very bad for me. :-( > > Will this bug be fixed in FreeBSD 5.0? The bug was fixed a long time ago, but the man page was never updated. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI interrupt routing across PCI:PCI bridges
> Following is a patch to route interrupts for devices on the child side of > a PCI:PCI bridge. I don't have any easy way to test this, unfortunately. > > If anyone would care to eyeball it before I commit it, I'd greatly > appreciate that. FWIW, this matches my reading of my paper copy of the spec., but I can't test it either. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
* Nick Hibma ([EMAIL PROTECTED]) [001109 17:31]: > Hm, I missed the zip story. You seem to have all the bits that are > necessary in your kernel. > > Could you compile your kernel/module with UMASS_DEBUG defined and send > me the output after an attach? As it turns out, I got it working, but only when the device is on SCSI ID 0. Any other SCSI id and the device is not found when I run 'camcontrol rescan 0' The output is rather large, so I put it on a web server: http://people.targetnet.com/~james/dmesg.plugin http://people.targetnet.com/~james/dmesg.rescan (plugin is the dmesg output when I plugged it into the USB port, and rescan is the additional output when I ran camcontrol rescan 0). Thanks. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What about rc.shutdown.local?
On Thu, 9 Nov 2000, Christoph Sold wrote: > Better still would be /usr/local/etc/rc.d/*.sh called automatically > with parameter stop. To do so, insert This is all nice (BTDT) although I find the *.sh pattern quite annoying, due to the alphabetisation issue. When I make these mods I tend to use the SysV-style S* and K* patterns - that means you get to control the order of startup _and_ shutdown (which might need a different sequence). jan PS. Yeah, an all-singing, all-dancing subsystem mechanism would make all of this moot, but this method is cheap and simple, and already here. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287163 Fax +44 (0)117 9287112 RFC822 [EMAIL PROTECTED] Bolstered by my success with vi, I proceeded to learn C with 'learn c'. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: "iowait" CPU state
In the last episode (Nov 10), Dag-Erling Smorgrav said: > void <[EMAIL PROTECTED]> writes: > > Is there any reason top couldn't add these up and report a %iowait > > like Solaris'? > > Yes. It would conceal valuable information. Do the adding up in your > head. I can't see how it would conceal information, since it would simply change "90% idle" to "10% idle 80% iowait". -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: printf()
Thanks for all of your replies. The reason I asked this question is that I really saw some incomplete print out on FreeBSD 3.3. My intuition is that the printout is buffered some where, otherwise, I would expect either there is a complete printout, or no printout at all. --Zhenhai On Fri, 10 Nov 2000, Mike Smith wrote: > > On 10 Nov, Mike Smith wrote: > > >> > > >> Is there is way that I could perhaps demonstrate my reasoning, > > >> such that it might be satisfactory to you? > > > > > > No. > > > > > Then, should I take it you concede the point? > > No. > > -- > ... 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 > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: [OT] serial protocol analyzer
I had a need for something like this - I modified a serial cable such that it had four connectors: DB9#1 goes to device A DB9#2 goes to device B DB9#3 and DB9#4 goes to a "monitoring" system on COM1 and COM2 #1 TX is connected to #2 RX AND #3 RX #1 RX is connected to #2 TX #2 TX is connected to #1 RX AND #4 RX #2 RX is connected to #1 TX #3 RX is tapped to #1 TX #3 TX is not connected #4 RX is tapped to #2 TX #4 TX is not connected Connect signal ground on each to each and monitor using a terminal emulator - Most terminal emulators have the ability to display rather than interpret control characters and escape sequences. You can see what is passing in both directions on the serial cable without affecting it, while not affecting the data stream. What you do not get is timestamp data. Or you can buy serial line monitors that do all this and more. Hope this helps. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Leonard den Ottolander > Sent: Thursday, November 09, 2000 1:04 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [OT] serial protocol analyzer > > > Hello everybody, > > I was wondering if somebody could point me out a serial protocol > analyzer. > Maybe analyzer is too big a word for what I am looking for (I > could be the > analyzer:) ). What I am thinking of is a piece of software that > listens on > two serial devices, and mimics input from either to the other, in > the mean > time dumping and/or analyzing the traffic. To be concrete: I want > to put a box > with this piece of software between another box and its modem to > analyze the > traffic. > Thanks in advance, > > Ciao, > > Leonard. > > > > > > ___ > Redhat-list mailing list > [EMAIL PROTECTED] > https://listman.redhat.com/mailman/listinfo/redhat-list > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: printf()
> On 10 Nov, Mike Smith wrote: > >> > >> Is there is way that I could perhaps demonstrate my reasoning, > >> such that it might be satisfactory to you? > > > > No. > > > Then, should I take it you concede the point? No. -- ... 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: printf()
On 10 Nov, Mike Smith wrote: >> >> Is there is way that I could perhaps demonstrate my reasoning, >> such that it might be satisfactory to you? > > No. > Then, should I take it you concede the point? Jessem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Legacy ethernet cards in FreeBSD
Dear All, Last night I cvsupped my trusty old Compaq Deskpro XL 6200 from 4.0-release to 4.2-beta. As part of that process, I seem to have lost support for the on-board NIC (lnc0: PCNet/PCI Ethernet Adapter, PC-net-32 VL-Bus). What is the newest version of FreeBSD that will propely support that card? If there are people who are cleaning up the support for older network cards in FreeBSD I'd like to help out by sending you my old NICs. It's not like they're any good to me without OS support. Please contact me off-list for any of the following cards: 3Com 3c503ISA DEC EtherworksISA DEC DE205 ISA SMC EtherEZ ISA RealTek "TP-Link" PCI As far as I've been able to determine, none of these work properly. In particular, the RealTek card gets detected and pretends to work, but loses the link after a bit (The link status LED goes out, and I need to reboot the box.) I'll be happy to try out patches for the lnc driver to fix the problem of the Deskpro, or to give remote access to it if you want to work on it. Kees Jan You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
subscribe freebsd-hackers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: printf()
[EMAIL PROTECTED] writes: > [...] > Jessem. Amazing what people will do to evade killfiles. Plonk. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: printf()
> > Is there is way that I could perhaps demonstrate my reasoning, > such that it might be satisfactory to you? No. -- ... 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: printf()
On 10 Nov, Mike Smith wrote: >> >> Does the kernel function printf() flushes the output immediately, or it is >> >> possible some data is buffered somewhere and gets lost without printing >> >> to the console? like the corresponding funtion in the c library. >> > >> > It's not buffered afaik. >> > >> Actually my experince in writing drivers (for 386bsd) showed (me) >> that the kernel printf() was buffered. > > Considerable (ie. shitloads) of experience using the kernel printf with > FreeBSD (not to mention reading the code line by line as I ported it for > libstand) allows me to tell you that it isn't. > > And you're welcome to go read the code yourself, should you choose to > take issue with that. 8) > Sir, with regards to your experience and reading of the code, I should say that as you have read it, that would appear to be the situation. Better judgement - and testing to see how it might be buffered - would seem to be a challange. However, before we quest into what might be a futile battle on the definition of a word. Let's first agree that taken the code at face value you are correct. I will certainly not deny - code taken on face value to be code taken on value. Let us also agree that "buffering" might be defined in different ways. For instance, we could say, "buffering implies an actual level of intermediate storage that might (for some unknown reason) be delaying the output of a printf()" Show that be the case, then it would stem that our differences are minor, and could simply be a difference in interpetation or meaning of the word "buffered". As such, let me NOT blather on with meaningless dribble. Let us say, if we might, that there could be a delay in output two (2) seperate kernel printf() statements. Or said an other way, Is it possible for two (2) printf() statements NOT to be outputed in a linear fashinon? Ie. the first printf() statement get printed first, the second - second. If we differ on this point, then perhaps a example might be needed. As such, my example would only work under 386BSD, as I stated. Being your stated experience with FreeBSD, it is quite possible that I am incorrect. Should that be the case, then I stand correct. However, I see no evidence to such. Further my understanding or *BSD kernels, could be skewed, but past experience tells me otherwise. Is there is way that I could perhaps demonstrate my reasoning, such that it might be satisfactory to you? best regards, Jessem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: printf()
> >> Does the kernel function printf() flushes the output immediately, or it is > >> possible some data is buffered somewhere and gets lost without printing > >> to the console? like the corresponding funtion in the c library. > > > > It's not buffered afaik. > > > Actually my experince in writing drivers (for 386bsd) showed (me) > that the kernel printf() was buffered. Considerable (ie. shitloads) of experience using the kernel printf with FreeBSD (not to mention reading the code line by line as I ported it for libstand) allows me to tell you that it isn't. And you're welcome to go read the code yourself, should you choose to take issue with that. 8) -- ... 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: printf()
On 9 Nov, Alfred Perlstein wrote: > * Zhenhai Duan <[EMAIL PROTECTED]> [001109 21:09] wrote: >> A simple question: >> >> Does the kernel function printf() flushes the output immediately, or it is >> possible some data is buffered somewhere and gets lost without printing >> to the console? like the corresponding funtion in the c library. > > It's not buffered afaik. > Actually my experince in writing drivers (for 386bsd) showed (me) that the kernel printf() was buffered. Jessem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help writing a screen saver module
Dan Nelson wrote:
>
> In the last episode (Nov 07), Dag-Erling Smorgrav said:
> > Graham Wheeler <[EMAIL PROTECTED]> writes:
> > > I am trying to write a screen saver module that, when it kicks in,
> > > will switch to the first console, and then, if a key is pressed,
> > > will switch back to the one that was previously active. The idea is
> > > that the first console has something useful running on it,
> > > typically a tail -f of the logs.
> >
> You can make it look like you're switched to vty 0, by making your
> screen_saver() function simply copy the contents of vty 0 to screen
> memory on every update. Just make sure both vtys are the same size
> first...
Okay, got it working. I've attached my code if anyone is interested.
Thanks for all the help Dan.
I have another question now - it would be great if I could put a message
on the top or bottom line of /dev/ttyv0, in inverse video, and have the
output of the `tail -f' go to a scrolling region in the rest of the
screen. The idea here is, on /dev/ttyv0, to have a message "Press Alt-Fn
(n=1,2,..) for Login Consoles". The screen saver would replace this with
"Press any key to stop watching logs and return to login console", or
something like that.
It would be nice, but its not too important...
gram
--
Dr Graham WheelerE-mail: [EMAIL PROTECTED]
Director, Research and Development WWW:http://www.cequrux.com
CEQURUX Technologies Phone: +27(21)423-6065
Firewalls/VPN SpecialistsFax:+27(21)424-3656
#include
#include
#include
#include
#include
#include
#include
#include
#include
#ifndef SC_STAT
#define SC_STAT sc_get_scr_stat
#endif
#ifndef MAXCONS
#define MAXCONS 16
#endif
void CopyConsoleContents(video_adapter_t *adp, int from)
{
if (from>=0 && fromscr_buf && adp->va_window &&
fc->ysize == adp->va_info.vi_height &&
fc->xsize == adp->va_info.vi_width)
{
int len = fc->ysize * fc->xsize, pos;
for (pos = 0; pos < len; ++pos)
writew(adp->va_window+pos*2, fc->scr_buf[pos]);
}
splx(s);
}
}
static int
switch_saver(video_adapter_t *adp, int blank)
{
if (adp->va_info.vi_flags & V_INFO_GRAPHICS)
return EAGAIN;
if (blank)
CopyConsoleContents(adp, 0);
return 0;
}
static int
switch_init(video_adapter_t *adp)
{
(void)adp;
return 0;
}
static int
switch_term(video_adapter_t *adp)
{
(void)adp;
return 0;
}
static scrn_saver_t switch_module = {
"switch_saver", switch_init, switch_term, switch_saver, NULL,
};
SAVER_MODULE(switch_saver, switch_module);
Re: "iowait" CPU state
void <[EMAIL PROTECTED]> writes: > Is there any reason top couldn't add these up and report a %iowait > like Solaris'? Yes. It would conceal valuable information. Do the adding up in your head. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
