Re: ACPI project progress report
Mike Smith wrote: On Mon, Jun 19, 2000 at 05:01:46PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] "Andrew Reilly" writes: : That sounds way too hard. Why not restrict suspend activity to : user-level processes and bring the kernel/drivers back up through : a regular boot process? At least that way the hardware and drivers : will know what they are all up to, even if some of it has changed : in the mean time. Takes too long... That's shutdown, not S4. Yes. But what is the difference, really? As far as the hardware is concerned, it's being booted. If that process can be sped up by using the "S4" mechanisms, why can't they be applied to a regular boot process too? [I'm thinking about a kernel equivelant of the "clean shutdown" flag on file systems.] Fundamentally, is there no way to get the kernel and drivers to go through a full boot phase in a small fraction of the time that it takes to repopulate 64M of RAM from disk? (*) The real issue here is persistent system state across the S4 suspend; ie. leaving applications open, etc. IMO this isn't really something worth a lot of effort to us, and it has a lot of additional complications for a "server-class" operating system in that you have to worry about network connections from other systems, not just _to_ other systems. Why then brand commercial vendors have such capability in their "server-class" operating system for a long time? Particularly HP's PA-RISC servers does have it, at least I remember such feature in the old 30MHz systems which I managed several years ago (the systems was shipped with small internal battery, which in the case of power failure was used to dump system to the disk). -Maxim. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI Plug 'n' Pray and old BIOSes
Olaf Hoyer wrote: Hi! The card normally should act and behave at least as a normal NE2000 clone (ed0) But as stated before, you might have to jumper it into the mobo. Yes, that was the problem. I managed to find the manual and discovered it had been jumpered as non-PnP (not by me; I inherited this machine a couple of years back to use as a PPP dialer and had an ISA NIC in it until now). Also the PCI latency is IMHO too high. Try setting it at around 40. That will affect the throughput of the NIC, or its reliability? Or both? I'm not too concerned if its just throughput, because (horror!) it has only ancient 16450 UARTs (one byte FIFO) on the multi-I/O card which are driving a 56k modem. I think its a very positive reflection on FreeBSD that despite this antique UART, which is being driven at 115200 baud, the PPP connection works very reliably and with pretty good throughput (there are the odd silo overflow log messages, but they don't seem to be a real problem). In fact this ancient 486 with 16Mb RAM is doing a fine job as a web cache, print and mail server. -- 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NFS client locks.
Hi, I have a Linux box as an NFS server and a FreeBSD box which acts as an NFS client. If I explicitly shutdown the NFS services in the Linux box, actions like 'df', 'ls /mnt' (/mnt is the mount point of the remote directory), or even 'umount /mnt', in the FreeBSD box, seem to lock forever. I waited for about 20-25 mins, I got a 'server not responding' message, but the processes were still locked and I could not even kill them. I started again the NFS services in the Linux box and I got a 'server alive' message in the FreeBSD box, after about 10 mins. Is that the correct behaviour? I had a look over /sys/nfs/nfs.h and the configuration constants seem perfectly resonable. I would like to help solving the problem, if it is an actual one. Otherwise, my apologies for taking your time. FreeBSD box: FreeBSD gluon.particles.org 5.0-2406-CURRENT FreeBSD 5.0-2406-CURRENT #0: Thu Apr 6 13:52:15 GMT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC i386 Regards, Elias -- Elias Athanasopoulos | I bet the human brain is | H.E.P Apps. Lab. http://www.uoa.gr/~eatha | a kludge. -Marvin Minsky | University Of Athens To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 05:40:30PM -0700, Mike Smith wrote: The real issue here is persistent system state across the S4 suspend; ie. leaving applications open, etc. IMO this isn't really something worth a lot of effort to us, and it has a lot of additional complications for a "server-class" operating system in that you have to worry about network connections from other systems, not just _to_ other systems. That said TCP/IP is very resilient :). I tried suspending to disk my laptop, unplugging the batteries and ether card, taking it to another part of the building and the firing it up. Pccardd saw the ethernet card, Dhclient saw the dhcp server and got my ip address back, and my pre-existing remote terminal sessions continued functioning :) Excellent. IMO if the machine is a server and you want to suspend it, who cares about the clients at the other end? If you did you wouldn't suspend it in the first place :) Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
On Tue, 20 Jun 2000 10:27:08 +0300 Maxim Sobolev wrote: +-- | Mike Smith wrote: | | The real issue here is persistent system state across the S4 suspend; ie. | leaving applications open, etc. IMO this isn't really something worth a | lot of effort to us, and it has a lot of additional complications for a | "server-class" operating system in that you have to worry about network | connections from other systems, not just _to_ other systems. | | Why then brand commercial vendors have such capability in their | "server-class" operating system for a long time? Particularly HP's PA-RISC | servers does have it, at least I remember such feature in the old 30MHz | systems which I managed several years ago (the systems was shipped with | small internal battery, which in the case of power | failure was used to dump system to the disk). | | -Maxim. +-- On very old systems with ferrite core memory the whole "core" simply retained whatever was running at the time of a power out. When power was restored the program just started ticking from where it left off with no loss of state. Later attempts at preserving "core" state over power out involved batteries for memory, processor registers and for peripheral buffers. As buffer sizes in controllers grew and processor memory became more volatile it became harder and harder to simply recover that way. The system always came up from bootstrap and never attempted to automatically recover to a previously running system state. These days we tend to think of a "core dump" as a diagnostic tool and not as a state image to be recovered as a part of powering up the computer. But does it have to be that way? Perhaps I am nieve but it seems to me that many "server class" systems could make great use of a hibernation mode which would allow the system to be suspended to wait for some critical event to pass and then to start running exactly as they were at the time of the suspend signal. At worst this could only minimize the recovery time experienced by the server. -- Chris Fedde 303 773 9134 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
High Availability Freebsd?
Given the recent (and ongoing) discussion about the so-called "FreeBSD BIOS", which has obvious HA implications, I'm wondering if there are enough people working on or interested in HA aspects of FreeBSD to begin a project. This would presumably include such things as: - Fairness-based scheduling - Warm (or hot) standby. - Warm (or progressive) restart. - Process replication or virtual synchrony. - Reduced boot time or rommable FreeBSD. - etc. as would take advantage of other ongoing things like the RAID stuff, LFS or journaled file-systems, etc. Not that I want to or would be competant to lead such a project, but I am working in that area, so I wanted to ping potential collaborators. -- Robert Withrow -- (+1 978 288 8256) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS client locks.
On Wed, 21 Jun 2000, Elias Athanasopoulos wrote: :Hi, : :I have a Linux box as an NFS server and a FreeBSD box which acts as an :NFS client. If I explicitly shutdown the NFS services in the Linux box, :actions like 'df', 'ls /mnt' (/mnt is the mount point of the remote :directory), or even 'umount /mnt', in the FreeBSD box, seem to lock forever. :I waited for about 20-25 mins, I got a 'server not responding' message, but :the processes were still locked and I could not even kill them. : :I started again the NFS services in the Linux box and I got a 'server alive' :message in the FreeBSD box, after about 10 mins. : :Is that the correct behaviour? I had a look over /sys/nfs/nfs.h and the Yep. That's the expected behavior. If this is a problem, you can use the intr to make processes blocked on I/O to the missing filesystems interruptible. David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS client locks.
On Tue, 20 Jun 2000, David Scheidt wrote: Yep. That's the expected behavior. If this is a problem, you can use the intr to make processes blocked on I/O to the missing filesystems Thanx for all your answers. I should have first checked the NFS related papers. Regards, Elias -- Elias Athanasopoulos | I bet the human brain is | H.E.P Apps. Lab. http://www.uoa.gr/~eatha | a kludge. -Marvin Minsky | University Of Athens To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI Plug 'n' Pray and old BIOSes
On 2000-06-20 10:41 +0200, Graham Wheeler [EMAIL PROTECTED] wrote: Also the PCI latency is IMHO too high. Try setting it at around 40. That will affect the throughput of the NIC, or its reliability? Or both? It won't do anything, in your particular case. The latency timer is the maximum number of PCI bus-master cycles that this card will be granted, if some higher priority PCI device is requesting the bus. Your Ethernet card doesn't support bus-master transfers ... The latency timer has to be set to a value that prevents buffer under- / overflows in PCI devices with limited FIFO sizes. (For example a bus-master 10baseT Ethernet chip with just 16 bytes of buffer has a maximum latency of 16 microseconds or roughly 500 PCI clocks. If there are 5 possible bus-masters and priorities are round-robin, then each bus-master may occupy the bus for no longer than 100 clocks.) There are "minimum grant" and "maximum latency" registers in each PCI device, which hold constant values denoting the number of bus clocks the device requires for efficient operation and the maximum latency between requesting the bus and getting it granted the device can tolerate. Reagrds, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
TZ implementation: question or proposition
I found out that implementation of time zone (local time, date, etc.)
has one problem. May be I missed something but I think that following
will be interesting.
If some process calls one of functions which operates with local time,
then all other calls of such functions will use time zone got in first
call.
Example. There is some program with following code:
time_tcurr_time;
struct tm curr_tm;
...
for (;;) {
curr_time = time((time_t *)0);
localtime_r(curr_time, curr_tm);
/* do something which takes some minutes */
}
Let current time zone is EST. Program calls localtime_r() and gets local
time adjusted to this time zone. Some time latter time zone is changed
(for example by tzsetup program). New time zone makes new adjustment for
local time. But it will take effect only for programs run after time
zone changes.
Our example program will still use local time adjustment for time zone
EST.
This isn't problem for most of programs, but for programs which
sensitive for local time it makes some kind of problems.
I looked at implementation of localtime_r() (and some other functions
like this one) and found out that they call functions tzset() and
tzsetwall(). But tzsetwall() remembers that it has been called and
doesn't allow to ``call'' itself two times (lcl_is_set variable). May be
it is possible to play with environment variable TZ, but I didn't find
good solution.
If I didn't find function which allows to ``restart'' tzset() and
tzsetwall() please tell me. If I'm right then I think that functions
tzreset() and tzresetwall() will be useful. Implementations of these
functions are quite simple: they should set some variables to initial
values and call tzset() and tzsetwall() respectively.
What do you think about all this?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: error in usr.bin/ftp/main.c ?
On 2000-05-24 10:56 +0200, Thomas Ludwig [EMAIL PROTECTED] wrote:
in usr.bin/ftp/main.c at line 407; instead of
if (line[--num] == '\n') {
it should probably be
if (buf[--num] == '\n') {
looks like a copy-paste error to me.
Sieht auch für mich so aus ;-)
Ist in Rev 1.27 von main.c behoben.
Vielen Dank für den Hinweis!
Gruss, STefan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Porting Linux Archive FS
Hi Hackers, Now I'm looking into possibility to port Linux Archive FS module (UFS module that allows to mount archive files http://raiden.goice.co.jp/member/mo/release/mi-arcfs/). This thing should be extremely useful for keeping ports/src tree on machines with limited HDD space. As I'm not very experienced with UFS hacking I would like to ask somebody with similar knowledge (ext2fs, smbfs etc.) to provide some help on that (i.e. hints and tips, plan of attack etc.). If someone would like to help please contact me at my e-mail, because I do not subscribed on this list. Thanks! -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why is this architecture dependent?
James Howard wrote: We know I ask dumb questions a lot, but this one may not be so dumb. A friend of mine was joking about having a device called /dev/foo which would be like /dev/zero, except it would spit out the word "foo" over and over again. Well, we laughed about it, but today, I implemented it. (This was cool since this was the first time I've ever hacked the kernel and it worked right...) [...] You are right and work is under way to break out this functionality in a MI driver. Search the mailing list archives for details. A first attempt can be found at: http://jeroen.vangelderen.org/FreeBSD/misc_device/ MarkM will soon import a variant of this with his excellent Yarrow work. Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: netgraph support for channelized LMC 1504 PCI card?
Len Conrad wrote: There was some talk about this back in March or so, leaving me rembering someone said that it wouldn't be too hard or long to do it. Has there been any progress? Len phk is working on this now I believe. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 )_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: netgraph support for channelized LMC 1504 PCI card?
I have a card here, and I am making good progress, I have the framers up and running and am working on the HDLC controller. I expect to pass the first HDLC frames today or tomorrow. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: Why is this architecture dependent?
In message [EMAIL PROTECTED], "Jeroen C. van Gelderen" write s: You are right and work is under way to break out this functionality in a MI driver. Search the mailing list archives for details. A first attempt can be found at: http://jeroen.vangelderen.org/FreeBSD/misc_device/ MarkM will soon import a variant of this with his excellent Yarrow work. Ahh, excellent. I was hoping to see something like this. Will random and urandom also end up therE? Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 09:34:01PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Mike Smith writes: : Can we guarantee that we can find this area? On eg. the Dell i7500 that : I've been playing most with, it's a file on a FAT filesystem, and the : BIOS will only "find" it if the filesystem is in the 'active' partition : at boot time. Generally we cannot guarnatee that. IIRC, there's lots of variation. Usually it is just a partition, but sometimes it is the last N cylenders of the disk, and sometimes it is a file like you say. It would at the very least need to be configured... On my vaio it's a separate partition on the disk of type 160 (which partition magic calls "save to disk"). Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mbuf re-write(s), v 0.1
In an attempt to eliminate or significantly reduce the hogging of physical memory by unused mbufs, I have begun re-writing some of the mbuf subsystem. I've re-written the allocator and designed an actual free routine, and have also considerably re-written the MGET, MGETHDR, and MFREE macros. I still have some work to do with this, notably optimisation, but I have not been able to do any profiling whatsoever as profiling, I repeat, seems presently broken on -CURRENT. This is particularily useful for machines which see "peak" mbuf usage periods, where many mbufs are allocated, only to be freed a little while later, but which will unfortunately remain on the free list, holding on to physical memory (for a graphical example, see the THIRD graph at http://www.technokratis.com/stats/mbuf.html). Previously, we used to use the kernel malloc() to do mbuf allocations, coupled with the free() routine to do the freeing. However, the new allocator does not have to worry about chosing the right algorithm, and notably, variable sized objects. Of course, I still have some performance tuning to do, but need the profiling to work for that. Of course, there is an min_on_avail variable added to the code, which is yet to be made sysctl-tunable, and which represents the minimum amount of mbufs that must reside on the free lists, so that the system will not explicitly free pages on every occasion it gets. The reason I named this "v 0.1" has to do with the work that is left to be done here. I've, for the moment, removed the m_reclaim() and wait code for mbufs, but this will all have to be re-placed appropriately (not much voodoo involved here). However, I've moved the mclusters to their own map, mcl_map, which is the correct thing to do here, in order to avoid having to worry about fragmentation in the allocation routines (we want most efficiency possible). I'll go ahead and change the mcluster stuff soon, too, and hopefully fix up some of the mclrefcnt usage for clusters. I'll discuss more of this in time to come, and post the URL here. Also, I'm planning to write an optional "mbuf daemon" that can periodically walk the mbuf system's AVAIL_LST, and EMPTY_LST, and re-organize order of elements on, particularily, the AVAIL_LST, in order to minimize fragmentation during allocations, and augment % utilization for the allocator(s). It should also optionally do some other neat tasks, but I haven't exactly decided on which ones, although I'd like to avoid having it raise to splimp() for too long, though. Unlike what some of you may be thinking right now, this is not theoretical work, I have some diffs right here: http://www.technokratis.com/code/mbuf/ (you'll have to excuse my big tabs) The diffs provided for now are context diffs, and they do several things, among the which (not to go too much into details): 1* Implement new mbuf allocator, implement free routine, re-write mbuf allocation and free macros. Add necessary lists / structures for the new system. 2* Change to OID_AUTO for all sysctls in uipc_mbuf.c 3* Make /sys/sys/mbuf.h look nicer, more consistent comments, etc. 4* Have mbuf clusters remain the same for now, but move them over to mcl_map 5* Remove (temporarily) mbuf wait/reclaim stuff. The diffs are in working condition on -CURRENT (as of a couple of days ago, at least), and I'm running them with no apparent problems as we speak. % utilization is great, for now, and I hope that the daemon-to-come will bring it up even higher. I can also tune it with the min_on_avail variable. Of course, from the above 5 points, you'll quickly note that I still have to go around and rebuild userland stuff, but that will wait until the end of all mbuf system modifications. Comments welcome. Special thanks to Mike Silbersack for already discussing such issues with me. Regards, Bosko -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 [EMAIL PROTECTED] * http://www.technokratis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why is this architecture dependent?
James Howard wrote: In message [EMAIL PROTECTED], "Jeroen C. van Gelderen" write s: You are right and work is under way to break out this functionality in a MI driver. Search the mailing list archives for details. A first attempt can be found at: http://jeroen.vangelderen.org/FreeBSD/misc_device/ MarkM will soon import a variant of this with his excellent Yarrow work. Ahh, excellent. I was hoping to see something like this. Will random and urandom also end up therE? Broken out into their own device, yes. As a bonus we'll provide a better PRNG construct named Yarrow. Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
In message [EMAIL PROTECTED] Josef Karthauser writes: : On Mon, Jun 19, 2000 at 09:34:01PM -0600, Warner Losh wrote: : In message [EMAIL PROTECTED] Mike Smith writes: : : Can we guarantee that we can find this area? On eg. the Dell i7500 that : : I've been playing most with, it's a file on a FAT filesystem, and the : : BIOS will only "find" it if the filesystem is in the 'active' partition : : at boot time. : : Generally we cannot guarnatee that. IIRC, there's lots of variation. : Usually it is just a partition, but sometimes it is the last N : cylenders of the disk, and sometimes it is a file like you say. It : would at the very least need to be configured... : : On my vaio it's a separate partition on the disk of type 160 (which : partition magic calls "save to disk"). Right. My vaio has that partition as well. My Libretto just splatted to the last 64MB of the disk (not using LBA, so if you get a disk 8G, you wind up with a hole that the save to disk uses:-). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Patch concerning linux extended fs
Hi Kelly,
I find it hard to believe that a 3 line patch would
be enought to enumerate the partitions inside extended partitions, must less
with arbitrary depth. But I've been amazed before :)
It's probably not really what you expect (or hope? for), and not that much of
a deal (less than a mouse driver ;) ). I was just wondering where to post
these kind of things. The only thing the patch does is make the linux extended
partition type known and use it when available.
I would like to submit a (three line) patch to enable the use of linux
extended filesystem.
I mean using as in mounting, not running from.
The linux extended partition is just a dos extended partition with a
different identifier (0x85 instead of 0x05). You can use it as an extra
extended partition, without dos being upset about seeing another extended
partition. I actually use it on a multi os machine which bios doesn't
understand the 20G hd. (Dos, dos extended containing ia linux /boot, ufs
44bsd, linux extended.)
Here comes the patch (for 4.0R):
/sys/kern/subr_diskmbr.c
Insert after line 51:
#define DOSPTYP_LINUXEXTENDED 133
Insert at line 347 (original offset), before the closing bracket:
|| sp-ds_type == DOSPTYP_LINUXEXTENDED
Insert at line 437, before closing bracket:
|| dp-dp_type == DOSPTYP_LINUXEXTENDED
That's all there is to it. I'm not sure the existing code handles dos
extended LBA partitions, or needs modification for this, so I didn't include
it. You could try to add a DOSPTYP_EXTENDED_LBA (0x0F). Haven't tried. Might
go seriously wrong.
To make things comeplete you could also modify fdisk.
/usr/src/sbin/i386/fdisk/fdisk.c
Insert after line 166:
,{0x85, "Extended Linux"}
Using two extended partitions you might want to increase MAXPARTITIONS in
/sys/i386/boot/dosboot/disklabe.h, /sys/sys/diskslice.h and
/sys/sys/disklabel.h.
Haven't really tested this thoroughly, but it seems to run fine.
Ciao,
Leonard.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
de driver problems
I have a DLink DE-660 10Mbit PCMCIA card in my laptop. If it is connected to my DLink DSS-8+ 10/100 switch negoation is not always successful and the link doesn't always come up. If I attach it to a hub plugged into the switch everything is fine. I have every reason to believe the two work to gether nicely, but I could be wrong. I noticed about 1 week ago there was a fix to the wx driver for a similar problem. I know were the source files are and such, but how do I go about trying to fix this or assist someone fixing this? Jim -- Artificial intelligence is no match for natural stupidity. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: High Availability Freebsd?
On Tue, 20 Jun 2000, Robert Withrow wrote: - Warm (or hot) standby. Put me on the 'interested' list for this, particularly for the network end. I have 'VRRPd for FreeBSD' on my very-long-range-todo but I doubt I have the skills right now to implement it decently. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Korn shell STDOUT
I am trying to learn how the (Korn) shell is organized, so I put some printf statements in many places. They give a lot of output on STDOUT , so in order to be able to read it, I pipe it to a tee command which stores the output. I have found that the output pauses when the file has 16384 (or thereabouts) bytes in it, sometimes it goes to 32768 (or thereabouts) bytes in it, and a couple of times it has even gone up to 65536 (or thereabouts) bytes. This behavior makes me think of buffered output, but (with some checking via long files) neither pipe nor tee have buffered output, and so I have been told by a Bell Labber. Anybody know how I can easily change the STDOUT to be unbuffered? Please respond directly to me as I have several hundred unread letters in my Bulk Mail folder. Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Korn shell STDOUT
On Tuesday, June 20, 2000, gerald stoller wrote: Anybody know how I can easily change the STDOUT to be unbuffered? Using setbuf(3). (``man setbuf'') -- |Chris Costello [EMAIL PROTECTED] |You had mail, but the super-user read it, and deleted it! `- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IP checksum offloading with intel 82559 fast ethernet.
Apparently (http://developer.intel.com/design/network/82559.htm) the i82559 can offload TCP and UDP checksums. A quick peruse of /usr/src/sys/pci/if_fxp.c shows we are not currently using this - which is fair enough since the driver also has to work with 82557 and 82558. It strikes me that due to the driver architecture (i.e. the IP packet is formed way before it gets to ip_fxp) that we couldn't use this facility - even if it does have some potentially excellent throughput implications. Maybe there's a possibility for treating it as an IP accelerating 'co-processor' (much as the early power vr 3d accelerators did). Any comments? Anyone working on this? Maybe I had better learn to write drivers ;) Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
signals and traps
I would like to play with the signals and traps of the Korn shell ; could someone please direct me quickly to the relevant areas? I expect that they are trap.c , sigact.[ch] , main.c , and siglist.* . I found runtraps (in the shell function of main.c ) and it calls runtrap from within a for-loop . This seems to be how the traps are processed. How does the signal get to the shell? Is the kernel involved in any of this? How is it determined which process should field a signal? Is there a description of the various fields of the structures involved and how they are used somewhere in a book or on the internet? Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: IP checksum offloading with intel 82559 fast ethernet.
Don't some of the Gigabit FreeBSD drivers actually utilize the on-board checksum processing??? H, can't see anything specific Looking at if_wx.c we have a function wx_start(ifp) where ifp is an ifnet pointer. ifnet has a member if_snd, of type ifqueue (according to the man page). And ifqueue is a safe looking memory buffer, but no actual statement as to whether we are expected to put raw packets on the queue or what. Presumably entire ethernet frames are put on the queue so we can spoof ethernet mac addresses occasionally - but no real way of indicating to the card that we have put an IP packet on with no checksum (and could you calculate it for me please). As an aside, if checksum calculations were offloadable via a call across PCI (i.e. send raw packet, get packet back with tcp calculated, queue packet for delivery), then it's a bit touch and go as to whether this is actually a good idea - given that we'll start to load up PCI quite badly doing this. Nice to see someone keeping our drivers fresh :-) Oh, no. I wish. I'm well off the end of my abilities here, but clearly into what I 'owe' the community in general. Hopefully I'll get there at some time. -marc Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
A.Out Kernel?
Hi. I recently posted a message to this list something like running FBSDBOOT.EXE. One of you answered me? It's no possible to run FBSDBOOT.EXE, cause FBSDBOOT requires the Kernel be compiled in a.out format. So, what I done, I tried to reach a way to compile the kernel with a.out format. Well, I discovered at my Makefile at /sys/compile/MYKERNEL/ a line like this. KERNFORMAT?=elf I modified this line to: KERNFORMAT?=a.out And, as resultant of this, I cannot compile the kernel, because a message like this appeared. loading kernel swapcontrol.o: not found. But before this message have appeared. The swapcontrol.c was compiled at format of a.out, because I saw the its compilation with the -aout flag. Anybody should answer to me? -- Gustavo Pamplona - [EMAIL PROTECTED] Linux User: 137471 - FreeBSD User: FBSD042237 Slackware 7.0 | Debian 2.1 | FreeBSD 3.2-R | NetBSD 1.3.2 (i386) -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: IP checksum offloading with intel 82559 fast ethernet.
(I'm the wx author)... I want to do checksum offloading too at some point. There's been some work done on this by Andrew Gallatin and Ken Merry amongst others insofar as I recall, but I don't believe it's been checked in. Let me see if I can dig up the mail.. Everyone's at Usenix this week next, so don't expect too much of a response. -matt On Wed, 21 Jun 2000, Dave Preece wrote: Don't some of the Gigabit FreeBSD drivers actually utilize the on-board checksum processing??? H, can't see anything specific Looking at if_wx.c we have a function wx_start(ifp) where ifp is an ifnet pointer. ifnet has a member if_snd, of type ifqueue (according to the man page). And ifqueue is a safe looking memory buffer, but no actual statement as to whether we are expected to put raw packets on the queue or what. Presumably entire ethernet frames are put on the queue so we can spoof ethernet mac addresses occasionally - but no real way of indicating to the card that we have put an IP packet on with no checksum (and could you calculate it for me please). As an aside, if checksum calculations were offloadable via a call across PCI (i.e. send raw packet, get packet back with tcp calculated, queue packet for delivery), then it's a bit touch and go as to whether this is actually a good idea - given that we'll start to load up PCI quite badly doing this. Nice to see someone keeping our drivers fresh :-) Oh, no. I wish. I'm well off the end of my abilities here, but clearly into what I 'owe' the community in general. Hopefully I'll get there at some time. -marc Dave 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: IP checksum offloading with intel 82559 fast ethernet.
It was mail from Andrew Gallatin ([EMAIL PROTECTED]), but it was private so I can't just redistribute it. Andrew- want to comment? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Korn shell STDOUT
On 20-Jun-00 gerald stoller wrote: I am trying to learn how the (Korn) shell is organized, so I put some printf statements in many places. They give a lot of output on STDOUT , so in order to be able to read it, I pipe it to a tee command which stores the output. I have found that the output pauses when the file has 16384 (or thereabouts) bytes in it, sometimes it goes to 32768 (or thereabouts) bytes in it, and a couple of times it has even gone up to 65536 (or thereabouts) bytes. This behavior makes me think of buffered output, but (with some checking via long files) neither pipe nor tee have buffered output, and so I have been told by a Bell Labber. Anybody know how I can easily change the STDOUT to be unbuffered? You might want to write to stderr which, if memory serves correct, is un-buffered. -- E-Mail: Kenneth P. Stox [EMAIL PROTECTED] Date: 20-Jun-00 Time: 18:54:17 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP checksum offloading with intel 82559 fast ethernet.
The checksome off loading for the Intel gigabit card is broken. All you get is the checksum of the frame, so it really isn't all that useful. paul Matthew Jacob ([EMAIL PROTECTED]) wrote: (I'm the wx author)... I want to do checksum offloading too at some point. There's been some work done on this by Andrew Gallatin and Ken Merry amongst others insofar as I recall, but I don't believe it's been checked in. Let me see if I can dig up the mail.. Everyone's at Usenix this week next, so don't expect too much of a response. -matt On Wed, 21 Jun 2000, Dave Preece wrote: Don't some of the Gigabit FreeBSD drivers actually utilize the on-board checksum processing??? H, can't see anything specific Looking at if_wx.c we have a function wx_start(ifp) where ifp is an ifnet pointer. ifnet has a member if_snd, of type ifqueue (according to the man page). And ifqueue is a safe looking memory buffer, but no actual statement as to whether we are expected to put raw packets on the queue or what. Presumably entire ethernet frames are put on the queue so we can spoof ethernet mac addresses occasionally - but no real way of indicating to the card that we have put an IP packet on with no checksum (and could you calculate it for me please). As an aside, if checksum calculations were offloadable via a call across PCI (i.e. send raw packet, get packet back with tcp calculated, queue packet for delivery), then it's a bit touch and go as to whether this is actually a good idea - given that we'll start to load up PCI quite badly doing this. Nice to see someone keeping our drivers fresh :-) Oh, no. I wish. I'm well off the end of my abilities here, but clearly into what I 'owe' the community in general. Hopefully I'll get there at some time. -marc Dave 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 -- Paul Saab Technical Yahoo [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: IP checksum offloading with intel 82559 fast ethernet. (fwd)
-- Forwarded message -- Date: Tue, 20 Jun 2000 19:57:04 -0400 (EDT) From: Andrew Gallatin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: IP checksum offloading with intel 82559 fast ethernet. Matthew Jacob writes: Sorry- they're talking about IP checksum offloading. You sent some mail last December talking about checking support for this in, but I didn't want to just forward that mail because I can't recall whether you checked it in (I don't believe that we have). We support hardware checksum offloading in both -current -stable both sending receiving. Jonathan Lemon's code is what got checked in -- its considerably better than my private hacks. I think the if_ti.c driver is the only drive to make use of it. You might want to peek at it if you're feeling like making the if_wx driver offload checksums. You can feel free to forward that ;) Drew BTW -- how is the if_wx.c driver? Has it gotten any better (you were talking about how poorly it performed were going to see where the bottleneck was the last I heard). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP checksum offloading with intel 82559 fast ethernet.
The checksome off loading for the Intel gigabit card is broken. All you get is the checksum of the frame, so it really isn't all that useful. Yeah, well, there's a couple of things that supposedly can be done about that. For transmit, there's a start/offset you can do which could allow to insert a checksum that didn't start at the frame header. Layering violation, but probably would be helpful. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A.Out Kernel?
Hi, To compile a.out kernel you can try to use the next procedure: cd /sys/compile/YOURSKERNEL/ make clean env KERNFORMAT=aout make make install It was compiled at least on 4.0-Stable. -- With best regards, Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
In message [EMAIL PROTECTED] Mike Smith writes: : The real issue here is persistent system state across the S4 suspend; ie. : leaving applications open, etc. IMO this isn't really something worth a : lot of effort to us, and it has a lot of additional complications for a : "server-class" operating system in that you have to worry about network : connections from other systems, not just _to_ other systems. They why bother supporting laptops at all? FreeBSD is now more than just a server OS. And the network connection issue is a non issue. If the connections are present when we go to sleep, either the connection will time out or it won't. It is no different than yanking out the ethernet cable. Those that time out will get a connection reset when the application comes back when the system wakes from the S4 state. Those that don't won't care since they will just continue working. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
On Tue, Jun 20, 2000 at 12:47:38PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Bjoern Fischer writes: : Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt), : turning power off, maybe adding some hardware or moving the machine : to another location, then switching on again, restoring the system context, : and the machine will proceed as if nothing had happened, do you? The S4 sleep state of ACPI doesn't support changing the hardware configuration while you are in that state. That would probably explain why W'98 gets confused when you _do_ change the hardware configuration while in suspend state. Pretty silly state to get into, then, if hardware like floppy drives are easy to add or remove, and the box looks as though it's off... Any good theories about how to avoid this problem? Avoid S4 and go all the way to shutdown, with a flag set on the boot disk? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
In message [EMAIL PROTECTED] Bjoern Fischer writes: : Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt), : turning power off, maybe adding some hardware or moving the machine : to another location, then switching on again, restoring the system context, : and the machine will proceed as if nothing had happened, do you? The S4 sleep state of ACPI doesn't support changing the hardware configuration while you are in that state. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
On Tue, 20 Jun 2000, Josef Karthauser wrote: On Mon, Jun 19, 2000 at 05:40:30PM -0700, Mike Smith wrote: The real issue here is persistent system state across the S4 suspend; ie. leaving applications open, etc. IMO this isn't really something worth a lot of effort to us, and it has a lot of additional complications for a "server-class" operating system in that you have to worry about network connections from other systems, not just _to_ other systems. That said TCP/IP is very resilient :). I tried suspending to disk my laptop, unplugging the batteries and ether card, taking it to another part of the building and the firing it up. Pccardd saw the ethernet card, Dhclient saw the dhcp server and got my ip address back, and my pre-existing remote terminal sessions continued functioning :) Excellent. IMO if the machine is a server and you want to suspend it, who cares about the clients at the other end? If you did you wouldn't suspend it in the first place :) You obviously haven't considered the ability to be able to near hot-swap motherboard and cpu - or even RAM - in this way. Joe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : Mitsuru IWASAKI wrote: : : - support S2, S3, S4 (hibernation) sleeping transition. S4 sleep : require some hack in boot loader needs help. : : I thought hibernation was entirely controlled by kernel? What do you : need? You have to use the BIOS to put the machine into the state, but when the machine comes out of that state, it goes through the reset vector, at least for S4 (I think S2 and S3 as well, I don't have my copy of the standard handy). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
Warner Losh wrote: In message [EMAIL PROTECTED] Mitsuru IWASAKI writes: : Hi, here is the latest report on our ACPI project's progress. As I told you on the Train in Tokyo: Cool! Way Cool! ACPI should enable us to properly put the chipsets in laptops to sleep and then wake them up again. Right now pccard insert/removal can be missed when you put a laptop to sleep... BTW, have you decided between NetBSD and BSD/OS cardbus code yet? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Windows works, for sufficently small values of "works". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
