Re: rc.d startup scripts
Kris Kennaway wrote: On Sun, 7 May 2000, Doug Barton wrote: I'm going to reply to the system part of this too, replies to this thread should split off to -current. I have a design in mind for a new rc system that uses scripts with "start, stop, status" operators to both upgrade and downgrade services, where "services" are defined as groups of daemons/programs that work together. For example, "nfs" would be an example of a service, which would be subdivided into client and server, etc. Eivind Eklund made a prototype some time back which addressed this issue - you'd do well to take a look at that one first before reinventing the wheel :) Point well taken. If anyone has references to this work, or an easy introduction to netbsd's version I'd love to look at them. I've been hoping to carve out some time to work on this, but every time I talk about vacation, my boss just laughs Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
Kenneth Wayne Culver wrote: Just curious, but wouldn't this be FreeSVR4??? :-) I'm going to assume that the smiley means you're joking, but I hope that we can stick to discussing this plan on its merits, rather than rejecting it out of hand because it's like something that someone else is doing. Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Small MAKEDEV bug
On Tue, 09 May 2000 10:26:05 +0200, Sheldon Hearn wrote: I don't agree. I think this is an issue of avoiding changes that unnecessarily astonish existing users. If you can find ways to improve MAKEDEV that don't inconvenience those already familiar with it, great. If your improvements astonish these people, you need to put a bit more thought into what you're actually scoring. I'd like to follow up on myself with a comment that takes a slightly broader view on the problem. As FreeBSD's user base grows, we're going to see two different demands in increasing contention with each other. 1) The demand for an intuitive, consistent interface. 2) The demand for a constant interface. The former represents the need for POLA to be upheld throughout the system at a given moment in time. The latter represents the need for POLA to be upheld from one release to the next, in the arena of "backward compatibility". Both are valid issues that deserve careful thought. In many situations, we can fix inconsistencies "in the moment" without forcing folks to change the way they do things from on release to the next. In those situations where we have to make a decision one way or another, the decision is going to become more and more difficult as the project moves forward. I don't think that the only rule of thumb that can be applied where the two demands are in contention with one another, is that it's worth thinking carefully about what we gain for the change. But we can _certainly_ agree that it's always worth thinking carefully about ways to satisfy _both_ demands wherever possible. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAKEDEV warning with sysinstall ?
On Mon, 08 May 2000 15:41:55 EST, Erik de Zeeuw wrote: I ran MAKEDEV all, but the message still appear. The messages I found about this on the archives says to do a 'ls -l /dev | grep ^b', and to remake all devices listed, but there's no device listed when I'm doing the 'ls -l /dev | grep ^b'. I'm not sure what that'll score you. Try this: cd /dev for i in `ls`; do if test -b $i; then echo $i; fi; done Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
On Mon, 08 May 2000 23:53:16 MST, Doug Barton wrote: Eivind Eklund made a prototype some time back which addressed this issue - you'd do well to take a look at that one first before reinventing the wheel :) Point well taken. If anyone has references to this work, or an easy introduction to netbsd's version I'd love to look at them. http://people.FreeBSD.org/~eivind/newrc.html Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Abit BP6 - UDMA66 and non IBM disks
About two days ago, I tested a machine with four IDE drives each on its own cable as the master. All four drives were: ad0: 29311MB Maxtor 53073U6 [59554/16/63] at ata0-master using UDMA66 I used the motherboard controller to support two of the drives. It was a atapci0: Intel ICH ATA66 controller port 0xffa0-0xffaf at device 31.1 on pci0 and a Highpoint-based ATA66 controller for the other two drives. The Highpoint locked up with the "resetting devices" message as soon as the system was stressed. I replaced the Highpoint controller with a Promise ATA66 and didn't see any problems after that. (I've never seen any problems with the Maxtor's on the Intel ATA66 controller either.) In summary, same disks, three different controllers, problems only occur with the Highpoint controller. (I believe the Abit BP6 uses the Highpoint controller.) Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Small MAKEDEV bug
On Mon, 8 May 2000, Tim Vanderhoek wrote: On Mon, May 08, 2000 at 06:56:03PM -0400, Jeroen C. van Gelderen wrote: I don't buy it :-). This syntax is similar to a special case of the syntax of jot(1). It's better to use jot(1) directly, e.g.: MAKEDEV $(jot -w da 2 0)# make 2 acd devices beginning at acd0 b$ which jot /usr/bin/jot b$ The jot utility doesn't appear to be in /bin. You can just type all the device names or use a shell loop when /usr/bin is not mounted. b$ echo '$(jot -w da 2 0)' | wc 1 5 17 b$ echo $(jot -w da 2 0) | wc 1 2 8 b$ Heh. Yes, it is much faster to type all the device names than to even type the command to generate them when there are a small number of device names. /me mumbles something about the prototypical UNIX hacker... :-) I wouldn't use jot for MAKEDEV'ing disks in practice :-). Part of my point is the new syntax for MAKEDEV is just as hard to remember as the syntax for jot. You would use it once or twice per millenium after install more than about 8 drives at once. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LINT broken. (in_cksum changes)
Appart from that, ipf does not load as a kld anymore. And probably, not tried, the IPFILTER option in any kernel would break the build as well. Nick On Mon, 8 May 2000, Wes Morgan wrote: I sent a note to the committer on these last night. LINT must need some modification, because the error is also present in netinet6/ipsec.c. There are some ifdef's around it that point to LINT needing some extra options. On Sun, 7 May 2000, Nick Hibma wrote: Is it only me that ever compiles LINT? The checksum changes went in a few days ago. Please, people, when you move code around or change a function that is used in more than a fixed set of files, compile LINT. If unsure, compile LINT. It's an extra five minutes, but well worth it. linking kernel fil.o: In function `fr_tcpsum': fil.o(.text+0xf47): undefined reference to `in_cksum' ip_fil.o: In function `send_reset': ip_fil.o(.text+0xd7d): undefined reference to `in_cksum' ip_fil.o: In function `ipfr_fastroute': ip_fil.o(.text+0x10f1): undefined reference to `in_cksum' ip_fil.o(.text+0x1316): undefined reference to `in_cksum' ip_fil.o(.text+0x1380): undefined reference to `in_cksum' ip_mroute.o(.text+0x19d6): more undefined references to `in_cksum' follow I just couldn't be bothered to fix it. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
On Mon, 8 May 2000, Warner Losh wrote: Leaving aside the 'r' question for the moment... Should that be sa or ast? sa is the scsi device for any tape device (formerly st or mt), while ast is for ide/atapi based tape drives. It should be ssa and asa, of course :-). The wt and wst devices referenced in our man pages are just plain bogus. I think we've killed all ft references in the tree... No, wst is still used by pc98, and wt is the Wangtek tape driver. wst and ast are weird names. Doesn't the "s" in them stand for "SCSI" and not "streaming", so wst is the so-called-Winchester (non-SCSI) SCSI tape driver, etc? For completeness, we should have had nrrrwsst (the non-rewinding rewinding raw so-called-Winchester streaming SCSI tape driver) ;-). Seriously, why aren't there "n" and "e" forms of ast? Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/netinet tcp.h tcp_input.c tcp_output.c tcp_timer.ctcp_var.h
[Charset iso-8859-1 unsupported, filtering to ASCII...] Jonathan Lemon [EMAIL PROTECTED] _crivait (wrote) : jlemon 2000/05/05 20:31:10 PDT Modified files: sys/netinet tcp.h tcp_input.c tcp_output.c tcp_timer.c tcp_var.h Log: Implement TCP NewReno, as documented in RFC 2582. This allows better recovery for multiple packet losses in a single window. The algorithm can be toggled via the sysctl net.inet.tcp.newreno, which defaults to "on". Submitted by: Jayanth Vijayaraghavan [EMAIL PROTECTED] This seems to have serious side effects on some TCP connections. My ssh connection to a Linux server dies randomly wicth 'Connection reset by peer', remote log shows: May 7 16:31:13 hsc sshd[25825]: fatal: Local: Bad packet length 300903990. setting net.inet.tcp.newreno to 0 fix my problem. If this can help : i'm running -CURRENT from yesterday, i am using stock ssh-1.2.27 (not openssh) on both sides on 33.6kbps ppp connection. The same problem. Local is openssh (current), remote is ssh-1.2.22 (2.2.6), slip ~24kbps connection. Remote log: May 9 09:59:17 crocus sshd[21285]: fatal: Local: Corrupted check bytes on input. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAKEDEV warning with sysinstall ?
On Tue, 9 May 2000, Sheldon Hearn wrote: On Mon, 08 May 2000 15:41:55 EST, Erik de Zeeuw wrote: I ran MAKEDEV all, but the message still appear. The messages I found about this on the archives says to do a 'ls -l /dev | grep ^b', and to remake all devices listed, but there's no device listed when I'm doing the 'ls -l /dev | grep ^b'. I'm not sure what that'll score you. Try this: cd /dev for i in `ls`; do if test -b $i; then echo $i; fi; done Hmmm... find /dev -type b -print - Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
Errrmmm Really, did you check the archives for the issue? There used to be a real long thread on why/why not sysV style init scripts. It produced not one but several flamewars iirc 8-) In short - if we change from the present scheme, we want something better than just stop and restart entry points for the scripts. What happens if the restarting is not an atomic, independent act? On Sat, 6 May 2000, Will Andrews wrote: Hello, I've noticed an inconsistency among our ports. It seems that not every port that installs rc.d startup scripts includes methods to not only startup, but also shutdown and/or restart, where appropriate. (Sent to -ports for ports hackers' opinions.) Shouldn't this sort of thing be standardized? And maybe a similar method be integrated into /etc/rc for restarting base system daemons? (Sent to -current for src hackers' opinions.) Please continue specific discussion on either of these in their own list, or if reply is general Cc both. -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
On Tue, May 09, 2000 at 08:54:50PM +1000, Bruce Evans wrote: wst and ast are weird names. Doesn't the "s" in them stand for "SCSI" and not "streaming", so wst is the so-called-Winchester (non-SCSI) SCSI It does to me. But McKusick's mail I forwarded says "s" was for "streaming". -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a better idea for package dependencies
On Mon, May 08, 2000 at 06:30:17PM -0400, Kenneth Wayne Culver wrote: Actually, it has to do with the pkg_ commands, which I believe are built when you make world... yes. and aren't part of the ports, And are only used for Ports. Thus their behavior defines the behavior of the Ports Collection. Thus it is a Ports issue. IF the pkg_* utils were ports, how would you install them?? -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
Doug Barton [EMAIL PROTECTED] wrote: Point well taken. If anyone has references to this work, or an easy introduction to netbsd's version I'd love to look at them. There's useful stuff in the rc(8) and rcorder(8) manual pages, but I can't find any more convenient copies of them other than by extracting NetBSD tar files. The scripts themselves look fairly easy to understand from just browsing around http://cvsweb.netbsd.org/. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] 421 manifold mosaic of the mundane To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
On Mon, May 08, 2000 at 11:53:16PM -0700, Doug Barton wrote: Point well taken. If anyone has references to this work, or an easy introduction to netbsd's version I'd love to look at them. I've been hoping to carve out some time to work on this, but every time I talk about vacation, my boss just laughs That's to be expected of a company like Yahoo! -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
Just curious, but wouldn't this be FreeSVR4??? :-) I'm going to assume that the smiley means you're joking, but I hope that we can stick to discussing this plan on its merits, rather than rejecting it out of hand because it's like something that someone else is doing. Yeah, I was just joking, I kinda like some things about SVR4, but I still think it would be nice to keep the option of using some of the regular rc scripts that we have now. Imagine the confusion of the people that have ONLY used FreeBSD when they go in and see rc.d and all it's scripts. Personally I kinda like the rc.d stuff better myself, but I'm just thinking about the average user. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LINT broken. (in_cksum changes)
On Sun, 7 May 2000, Nick Hibma wrote: Is it only me that ever compiles LINT? The checksum changes went in a few days ago. Please, people, when you move code around or change a function that is used in more than a fixed set of files, compile LINT. If unsure, compile LINT. It's an extra five minutes, but well worth it. linking kernel fil.o: In function `fr_tcpsum': fil.o(.text+0xf47): undefined reference to `in_cksum' ip_fil.o: In function `send_reset': ip_fil.o(.text+0xd7d): undefined reference to `in_cksum' ip_fil.o: In function `ipfr_fastroute': ip_fil.o(.text+0x10f1): undefined reference to `in_cksum' ip_fil.o(.text+0x1316): undefined reference to `in_cksum' ip_fil.o(.text+0x1380): undefined reference to `in_cksum' ip_mroute.o(.text+0x19d6): more undefined references to `in_cksum' follow I had same problem with below options: optionsIPFILTER#ipfilter support optionsIPFILTER_LOG#ipfilter logging optionsIPSEC #IP security I think this problem related to jlemon-san's commit. jlemon 2000/05/06 11:18:33 PDT Modified files: sys/alpha/alpha in_cksum.c sys/alpha/includein_cksum.h sys/i386/i386in_cksum.c sys/i386/include in_cksum.h Log: Make in_cksum() a macro call to in_cksum_skip(), since it provides the same functionality. Sharing code should help cache issues. Remove in_cksum_partial, since its not being used, and we now have a way to compute partial checksums on mbuf chains. in_cksum function was removed and change into macro. --- in sys/i386/include/in_cksum.h #define in_cksum(m, len)in_cksum_skip(m, len, 0) --- It needs to some code to compile with those options... MIHIRA Yoshiro To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
Will Andrews wrote: On Mon, May 08, 2000 at 11:53:16PM -0700, Doug Barton wrote: Point well taken. If anyone has references to this work, or an easy introduction to netbsd's version I'd love to look at them. I've been hoping to carve out some time to work on this, but every time I talk about vacation, my boss just laughs That's to be expected of a company like Yahoo! Hey... easy there. :) They're actually pretty good about time off, but for better or worse I'm a central part of the current development cycle for the new products we're just about to release. I had some time off scheduled a while back, but I've had to slip it a couple times. I guess I should take it as a compliment that they won't let me leave... *chuckle* Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
Kenneth Wayne Culver wrote: Yeah, I was just joking, I kinda like some things about SVR4, but I still think it would be nice to keep the option of using some of the regular rc scripts that we have now. Imagine the confusion of the people that have ONLY used FreeBSD when they go in and see rc.d and all it's scripts. Personally I kinda like the rc.d stuff better myself, but I'm just thinking about the average user. What does the average user do with the rc scripts? (BTW, I'm not being combative here, just using your letter as an opportunity...) In my outline we would still have /etc/rc.conf[.local], which is what the average user interacts with now. It's what happens behind the scenes that I want to change. The way that the various services get started. Instead of the arcane, confusing system of rc* files we have now (most of which grew out of necessity, don't get me wrong) we would have a system that could be used at startup, and then also used while the system is running to upgrade and downgrade individual bits, or groups of bits. Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LINT broken. (in_cksum changes)
On Wed, May 10, 2000 at 01:49:51AM +0900, MIHIRA Yoshiro wrote: On Sun, 7 May 2000, Nick Hibma wrote: Is it only me that ever compiles LINT? The checksum changes went in a few days ago. Please, people, when you move code around or change a function that is used in more than a fixed set of files, compile LINT. If unsure, compile LINT. It's an extra five minutes, but well worth it. linking kernel fil.o: In function `fr_tcpsum': fil.o(.text+0xf47): undefined reference to `in_cksum' ip_fil.o: In function `send_reset': ip_fil.o(.text+0xd7d): undefined reference to `in_cksum' ip_fil.o: In function `ipfr_fastroute': ip_fil.o(.text+0x10f1): undefined reference to `in_cksum' ip_fil.o(.text+0x1316): undefined reference to `in_cksum' ip_fil.o(.text+0x1380): undefined reference to `in_cksum' ip_mroute.o(.text+0x19d6): more undefined references to `in_cksum' follow I had same problem with below options: optionsIPFILTER#ipfilter support optionsIPFILTER_LOG#ipfilter logging optionsIPSEC #IP security I think this problem related to jlemon-san's commit. Yes, my abject apologies. I just committed Nick's fix to the tree to resolve this. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a better idea for package dependencies
On Tue, 9 May 2000, David O'Brien wrote: On Mon, May 08, 2000 at 06:30:17PM -0400, Kenneth Wayne Culver wrote: Actually, it has to do with the pkg_ commands, which I believe are built when you make world... yes. and aren't part of the ports, And are only used for Ports. Thus their behavior defines the behavior of the Ports Collection. Thus it is a Ports issue. IF the pkg_* utils were ports, how would you install them?? -- David([EMAIL PROTECTED]) Am I missing something? I thought ports only need some .mk files and make? (Along with tools to get those there, including the port itself, at most fetch or ftp, and tar?) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a better idea for package dependencies
On Tue, May 09, 2000 at 01:23:09PM -0400, Adam wrote:
And are only used for Ports. Thus their behavior defines the behavior of
the Ports Collection. Thus it is a Ports issue. IF the pkg_* utils were
ports, how would you install them??
Am I missing something? I thought ports only need some .mk files and
make? (Along with tools to get those there, including the port itself, at
most fetch or ftp, and tar?)
Packages (ie, those things that pkg_{create,add,delete,info} operate on
are created with in /usr/ports. When one builds a port and installs it,
pkg_{create,add} is run on the backend behind your back. If you
``make package'' yourself, you will get a package tarball. These are the
files on the FTP site and CDROM disc in the package/ dir. You install
these by ``pkg_add foo''. You delete the package (ie, the thing built in
/usr/ports) with ``pkg_delete foo''.
Hopefully some day, parts of the /usr/src bits will be installed with the
pkg_* utils, but today only things in /usr/ports are used with the pkg_*
utils.
--
-- David([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
On Tue, May 09, 2000 at 12:12:44PM -0400, Kenneth Wayne Culver wrote: Yeah, I was just joking, I kinda like some things about SVR4, but I still think it would be nice to keep the option of using some of the regular rc scripts that we have now. What I am prosing aguments what we have today (in ports) and simply adds argment targets. No arguments to the RC script would give you the same behavior you see today. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a better idea for package dependencies
On Tue, 9 May 2000 10:29:12 -0700, "David O'Brien" [EMAIL PROTECTED] said:
Packages (ie, those things that pkg_{create,add,delete,info} operate on
are created with in /usr/ports.
Not necessarily, and certainly not in the very beginning. I remember
a number of times seeing a third-party software vendor who provided
their product in that form, just as many third-party vendors now ship
*.rpm files (and always shipped SCO and Solaris ``packages'').
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED] | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
tcp/ip broken?
Did a cvsup on saturday, make world etc and now TCP/IP networking seems to be broken. dmesg shows the devices, ifconfig configs everything without error, but cant ping, telnet, ssh etc off of the server. Even set up PPP with the same results. Downside to this is that I cannot cvsup to something more current to see if it fixes the problem. Any known issues with recent commits? -- -Jason J. Horton [EMAIL PROTECTED] Fat Man in a Little Coat Intercom Online Inc. 212.376.7440 | http://www.intercom.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a better idea for package dependencies
On Tue, May 09, 2000 at 01:36:03PM -0400, Garrett Wollman wrote: Not necessarily, and certainly not in the very beginning. I remember a number of times seeing a third-party software vendor who provided their product in that form, just as many third-party vendors now ship *.rpm files (and always shipped SCO and Solaris ``packages''). Yes. But with the Ports Collection being the biggest consumer of pkg_*, there is more pkg_* clue on [EMAIL PROTECTED] than [EMAIL PROTECTED] -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tcp/ip broken?
Update your source again. This has been fixed. paul Jason J. Horton ([EMAIL PROTECTED]) wrote: Did a cvsup on saturday, make world etc and now TCP/IP networking seems to be broken. dmesg shows the devices, ifconfig configs everything without error, but cant ping, telnet, ssh etc off of the server. Even set up PPP with the same results. Downside to this is that I cannot cvsup to something more current to see if it fixes the problem. Any known issues with recent commits? -- -Jason J. Horton [EMAIL PROTECTED] Fat Man in a Little Coat Intercom Online Inc. 212.376.7440 | http://www.intercom.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" 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-current" in the body of the message
Re: proposed pkg_delete change
On Mon, 8 May 2000, Mike Pritchard wrote: On Mon, May 08, 2000 at 02:10:28AM -0400, Kenneth Wayne Culver wrote: I have a suggestion for pkg_delete: Very often when I'm deleting a package (such as kde, after testing the port) I want to delete that package, and all it's dependancies; instead of going around looking for the dependancies, I think it would be a nice idea to add an option to pkg_delete to automatically delete all dependancies that aren't currently used by anything else. If nobody is interested in doing this, I can do it when I have some spare time (finals here at school). And then submit patches. That would have saved me a *lot* of time about a month ago when I went and weeded out all of my packages when my /usr filled up. I basically did what you are proposing by hand and it took forever. e.g. pkg_delete some_package - oops, it depends on pkg_xxx, delete that, oops, it depends on pkg_xxx2, and so on, when in reality that only reason any of those additional packages were installed were for the original package. I just go to /var/db/pkg and type 'pkg_delete kde*' a few times. After a while they all get deleted. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a better idea for package dependencies
On Tue, 9 May 2000, David O'Brien wrote:
On Tue, May 09, 2000 at 01:23:09PM -0400, Adam wrote:
And are only used for Ports. Thus their behavior defines the behavior of
the Ports Collection. Thus it is a Ports issue. IF the pkg_* utils were
ports, how would you install them??
Am I missing something? I thought ports only need some .mk files and
make? (Along with tools to get those there, including the port itself, at
most fetch or ftp, and tar?)
Packages (ie, those things that pkg_{create,add,delete,info} operate on
are created with in /usr/ports. When one builds a port and installs it,
pkg_{create,add} is run on the backend behind your back. If you
``make package'' yourself, you will get a package tarball. These are the
files on the FTP site and CDROM disc in the package/ dir. You install
these by ``pkg_add foo''. You delete the package (ie, the thing built in
/usr/ports) with ``pkg_delete foo''.
Hopefully some day, parts of the /usr/src bits will be installed with the
pkg_* utils, but today only things in /usr/ports are used with the pkg_*
utils.
Ahh I see now that I try renaming pkg_create and installing a port,
however the program is not needed until the very end when it registers (or
tries to make an actual package if you "make package"). I cant comment on
the complexity of registering a port as an installed package because I
havent read the code, but it doesnt look too complex according to whats in
/var/db/pkg... perhaps more makefile things could be done to register a
package. I am seeing +COMMENT+CONTENTS +DESC
in a simple port dir, and if it depends on other things,
+REQUIRED_BY... thinking optimistically that this stuff could be acheived
with simple commands like echo myport /var/db/foo/+REQUIRED_BY, and
maybe grep to help with removing things from REQ...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Abit BP6 - UDMA66 and non IBM disks
-On [2509 11:20], Alan Cox ([EMAIL PROTECTED]) wrote: In summary, same disks, three different controllers, problems only occur with the Highpoint controller. (I believe the Abit BP6 uses the Highpoint controller.) It does. It might be worthwhile to note that there are updates of the BP6 BIOS and the HPT366, but given the knowledge we don't use the BIOS of the HPT366 I don't know how much good that will do aside from a better system BIOS which you also get from the upgrade. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Light, a quark resolution of god... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a better idea for package dependencies
On Tue, May 09, 2000 at 03:24:25PM -0400, Adam wrote: I cant comment on the complexity of registering a port as an installed package because I havent read the code, but it doesnt look too complex according to whats in /var/db/pkg... perhaps more makefile things could be done to register a package. I am seeing +COMMENT+CONTENTS +DESC in a simple port dir, and if it depends on other things, +REQUIRED_BY... thinking optimistically that this stuff could be acheived with simple commands like echo myport /var/db/foo/+REQUIRED_BY, and maybe grep to help with removing things from REQ... PLEASE get a CLUE about pkg_* and ports BEFORE commenting further. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Abit BP6 - UDMA66 and non IBM disks
Greg Lehey wrote: On Monday, 8 May 2000 at 9:57:54 +0200, [EMAIL PROTECTED] wrote: Not all non IBM disks has problems, that was not the message back then, at least not from me. What I said, and still says, is that Maxtor and WDC has a bad reputation on making drives that can't work reliably with UDMA66, quantum has its share too but not so bad. There are some WDC disks that work nicely. This is from a BP6 board too: ad0: 26105MB WDC WD273BA [53040/16/63] at ata0-master using UDMA33 ad1: 26105MB WDC WD273BA [53040/16/63] at ata1-master using UDMA33 ad2: 26105MB IBM-DPTA-372730 [53040/16/63] at ata2-master using UDMA66 ad3: 26105MB WDC WD273BA [53040/16/63] at ata3-master using UDMA66 As far as I know, the WD273BA is in reality a DPTA-372730 in disguise, so I guess I shouldn't be surprised. Anybody know if it's possible to put the original IBM firmware on these disks? I've been having trouble with this one in UDMA66 mode, also on a BP6. The system just hangs solid at random: ad4: 13042MB WDC WD136BA [26500/16/63] at ata2-master using UDMA66 It works fine on UDMA33. I notice that you have ad2 and ad3 running in UDMA66 mode. I didn't realise this was possible; I'll experiment. If you shut off the PIIX contoller in the BIOS the Highpoint uses ad0-3 if not it uses ad4-7 I have found problems with cdroms on the highpoint so I use both. Not the controllers fault but the applications. -- Ted Sikora Jtl Development Group [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a better idea for package dependencies
On Tue, May 09, 2000 at 03:24:25PM -0400, Adam wrote: I cant comment on the complexity of registering a port as an installed package because I havent read the code, but it doesnt look too complex according to whats in /var/db/pkg... perhaps more makefile things could be done to register a package. I am seeing +COMMENT+CONTENTS +DESC in a simple port dir, and if it depends on other things, +REQUIRED_BY... thinking optimistically that this stuff could be acheived with simple commands like echo myport /var/db/foo/+REQUIRED_BY, and maybe grep to help with removing things from REQ... PLEASE get a CLUE about pkg_* and ports BEFORE commenting further. -- David([EMAIL PROTECTED]) Good suggestion. Did some reading in bsd.port.mk and came up with the basis for a hack to get a port installed without pkg_*. If only total elegant solutions are entertained here then I will say no further, but here goes: cd /usr/ports/foo/pkg_create make NO_PKG_REGISTER install (pkg_create gets installed but not recorded) Since you claim superior knowledge about ports than me, I wont bother explaining it. I'm only trying to satisfy your original question. " IF the pkg_* utils were ports, how would you install them??" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
Yeah, I was just joking, I kinda like some things about SVR4, but I still think it would be nice to keep the option of using some of the regular rc scripts that we have now. Imagine the confusion of the people that have ONLY used FreeBSD when they go in and see rc.d and all it's scripts. Personally I kinda like the rc.d stuff better myself, but I'm just thinking about the average user. What does the average user do with the rc scripts? (BTW, I'm not being combative here, just using your letter as an opportunity...) In my outline we would still have /etc/rc.conf[.local], which is what the average user interacts with now. It's what happens behind the scenes that I want to change. The way that the various services get started. Instead of the arcane, confusing system of rc* files we have now (most of which grew out of necessity, don't get me wrong) we would have a system that could be used at startup, and then also used while the system is running to upgrade and downgrade individual bits, or groups of bits. Well, I guess I am not an average user then. I have customized most of my rc scripts. You are right though, it seems much better to "change what goes on behind the scenes" because it took me quite a while to learn what everything we have now did, and it took me only a day or two to figure out how to use the system you describe (well the back end anyway) Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proposed pkg_delete change
Yeah, but some ports and projects don't have the same beginning to their names which prompted me to make my suggestion. = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Tue, 9 May 2000, Doug Rabson wrote: On Mon, 8 May 2000, Mike Pritchard wrote: On Mon, May 08, 2000 at 02:10:28AM -0400, Kenneth Wayne Culver wrote: I have a suggestion for pkg_delete: Very often when I'm deleting a package (such as kde, after testing the port) I want to delete that package, and all it's dependancies; instead of going around looking for the dependancies, I think it would be a nice idea to add an option to pkg_delete to automatically delete all dependancies that aren't currently used by anything else. If nobody is interested in doing this, I can do it when I have some spare time (finals here at school). And then submit patches. That would have saved me a *lot* of time about a month ago when I went and weeded out all of my packages when my /usr filled up. I basically did what you are proposing by hand and it took forever. e.g. pkg_delete some_package - oops, it depends on pkg_xxx, delete that, oops, it depends on pkg_xxx2, and so on, when in reality that only reason any of those additional packages were installed were for the original package. I just go to /var/db/pkg and type 'pkg_delete kde*' a few times. After a while they all get deleted. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd.Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Compilation Question
Hi Y'll A kernel source file that compiles flawlessly on RELEG_3, gives (among many others, these warnings: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wm issing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ans i -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../i2o/i2o_drv.c In file included from ../../i2o/include/i2oadptr.h:32, from ../../i2o/i2o_drv.c:357: ../../i2o/include/i2omsg.h: warning: 1 trigraph(s) encountered In file included from ../../i2o/include/i2obscsi.h:29, from ../../i2o/i2o_drv.c:358: ../../i2o/include/i2omsg.h: warning: 1 trigraph(s) encountered In file included from ../../i2o/include/i2oexec.h:37, from ../../i2o/i2o_drv.c:362: ../../i2o/include/i2omsg.h: warning: 1 trigraph(s) encountered In file included from ../../i2o/include/i2outil.h:37, from ../../i2o/include/i2oexec.h:38, from ../../i2o/i2o_drv.c:362: ../../i2o/include/i2omsg.h: warning: 1 trigraph(s) encountered In file included from ../../i2o/i2o_drv.c:363: ../../i2o/include/i2omsg.h: warning: 1 trigraph(s) encountered I have _no clue_ which line in the file does that. Tried to isolate it to no avail. Can you please tell me what does this wanring mean? Personal replies as to not clutter the list will be very appreciated. Thanx! Sincerely Yours 404.664.6401 Simon Shapiro Research Fellow, Earthlink Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
unknown: PNP...
I just updated an i386 machine after a month to the latest 5.0-CURRENT, and I now get some strange boot messages: isa0: too many memory ranges ... unknown0: PNP at port 0x20-0x21,0xa0-0xa1 irq 2 on isa0 unknown1: PNP0200 at port 0-0xf,0x81-0x83,0x87,0x89-0x8b,0x8f-0x91,0xc0-0xdf drq 4 on isa0 unknown2: PNP0100 at port 0x40-0x43 irq 0 on isa0 unknown3: PNP0b00 at port 0x70-0x71 irq 8 on isa0 unknown: PNP0303 can't assign resources unknown4: PNP0800 at port 0x61 on isa0 npxisa0: Legacy ISA coprocessor support at port 0xf0-0xff irq 13 on isa0 unknown5: PNP0c01 at iomem 0xf-0xf3fff,0xf4000-0xf7fff,0xf8000-0xf,0xcc800-0xc,0-0x9,0xfffe-0x,0xfec0-0xfec0,0xfee0-0xfee0 on isa0 unknown6: PNP0a03 at port 0x4d0-0x4d1,0xcf8-0xcff,0x480-0x48f on isa0 unknown7: PNP0c02 at port 0x208-0x20f on isa0 unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources unknown8: PNP0401 at port 0x378-0x37b,0x778-0x77a irq 7 on isa0 unknown: PNP0501 can't assign resources Any comments? -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Abit BP6 - UDMA66 and non IBM disks
Alan Cox wrote: About two days ago, I tested a machine with four IDE drives each on its own cable as the master. All four drives were: ad0: 29311MB Maxtor 53073U6 [59554/16/63] at ata0-master using UDMA66 I used the motherboard controller to support two of the drives. It was a atapci0: Intel ICH ATA66 controller port 0xffa0-0xffaf at device 31.1 on pci0 and a Highpoint-based ATA66 controller for the other two drives. The Highpoint locked up with the "resetting devices" message as soon as the system was stressed. I replaced the Highpoint controller with a Promise ATA66 and didn't see any problems after that. (I've never seen any problems with the Maxtor's on the Intel ATA66 controller either.) In summary, same disks, three different controllers, problems only occur with the Highpoint controller. (I believe the Abit BP6 uses the Highpoint controller.) I use the BP6 with FreeBSD-current and Slackware. The Highpoint works great with FreeBSD however I have a problem with the Maxtor running fsck under Linux. This has occurred since the beginning of support for the Highpoint. I have used Hedricks patches and nagged him about problems but the only remaining issue is fsck. It works perfectly with the PIIX controller. Benchmarks sizzle with the Maxtor/Highpoint almost 24MB/sec so the tradeoff is acceptable(to me). The best the IBM could muster was 20MB/sec. The Maxtor/PIIX runs a little over 19MB/sec occasionally hitting 20MB/sec. Regards, -- Ted Sikora Jtl Development Group [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
One more question (different now)
Hi Again,
Since you were so kind to me, I will impose another
one on you (the previous answers were _all_ correct! )
Given:
typedef struct junk {
...
} junk_t
volatile junk_t trash;
What I want to do is zero out trash.
bzero(trash, sizeof(junk_t));
produces a warning about loss of volatility.
So does:
bzero((void *)trash, sizeof(junk_t));
So, how do I make everyone happy?
Oh, the struct has to be volatile. Trust me on that one.
Sincerely Yours
404.664.6401
Simon Shapiro Research Fellow, Earthlink Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
One more question (different now)
On Tue, 09 May 2000 19:08:21 -0400 (EDT), Simon Shapiro [EMAIL PROTECTED] said: So does: bzero((void *)trash, sizeof(junk_t)); So, how do I make everyone happy? Put a comment on that line indicating that a warning is expected. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: One more question (different now)
The only answer I've seen for this one is to kick, hard, whoever it was
that added -Wcast-qual to the kernel options. Or write your own,
suboptimal, bzero code.
Hi Again,
Since you were so kind to me, I will impose another
one on you (the previous answers were _all_ correct! )
Given:
typedef struct junk {
...
} junk_t
volatile junk_t trash;
What I want to do is zero out trash.
bzero(trash, sizeof(junk_t));
produces a warning about loss of volatility.
So does:
bzero((void *)trash, sizeof(junk_t));
So, how do I make everyone happy?
Oh, the struct has to be volatile. Trust me on that one.
Sincerely Yours
404.664.6401
Simon Shapiro Research Fellow, Earthlink Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Hi Again,
Since you were so kind to me, I will impose another
one on you (the previous answers were _all_ correct! )
Given:
typedef struct junk {
...
} junk_t
volatile junk_t trash;
What I want to do is zero out trash.
bzero(trash, sizeof(junk_t));
produces a warning about loss of volatility.
So does:
bzero((void *)trash, sizeof(junk_t));
So, how do I make everyone happy?
Oh, the struct has to be volatile. Trust me on that one.
Sincerely Yours
404.664.6401
Simon Shapiro Research Fellow, Earthlink Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: a better idea for package dependencies
On Tue, May 09, 2000 at 05:01:02PM -0400, Adam wrote: Since you claim superior knowledge about ports than me, I wont bother explaining it. I'm only trying to satisfy your original question. " IF the pkg_* utils were ports, how would you install them??" I said that to make you think *WHY* pkg_* is in /usr/src and not /usr/ports, even though I said pkg_* issues are purely a ports issue. Geez. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: One more question (different now)
On Tue, May 09, 2000 at 04:27:10PM -0700, Mike Smith wrote: The only answer I've seen for this one is to kick, hard, whoever it was that added -Wcast-qual to the kernel options. Or we should just delete it from the options. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: One more question (different now)
On Tue, May 09, 2000 at 04:27:10PM -0700, Mike Smith wrote: The only answer I've seen for this one is to kick, hard, whoever it was that added -Wcast-qual to the kernel options. Or we should just delete it from the options. Ugh. I don't actually like that, because it serves a valid purpose. What irritates me mostly is just that there is no way of casting a volatile object into a non-volatile type, so you can't implement any sort of conditional volatility exclusion. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: One more question (different now)
Mike Smith wrote:
Ugh. I don't actually like that, because it serves a valid purpose.
What irritates me mostly is just that there is no way of casting a
volatile object into a non-volatile type, so you can't implement any sort
of conditional volatility exclusion.
You can however use a union and have a non-volatile object aliasing a
volatile object as in:
union u {
volatile int vi;
int nvi;
};
--
Marcel Moolenaar
mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
tel: (408) 447-4222
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: One more question (different now)
At 7:08 PM -0400 5/9/00, Simon Shapiro wrote:
Given:
typedef struct junk {
...
} junk_t
volatile junk_t trash;
What I want to do is zero out trash.
bzero(trash, sizeof(junk_t));
produces a warning about loss of volatility.
So, how do I make everyone happy?
Write a 'bzerov' function, which takes a volatile first
parameter. Presumably you could just copy the source
for bzero and change the 1st parameter declaration...
or
write a dumb 'bzerov' macro, which casts the first
parameter to be pointer to volatile char, and then
loops over it setting to zero one byte at a time.
---
Garance Alistair Drosehn = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
EVENTHANDLER_DECLARE
Sorry to bother y'll, but; Has anyone ever used that? I see no trace of any kernel code calling it, and the at_shutdown code appears to be gone. BTW, for all it is worth, any caching controller not using this is guaranteed to lose data. that can range from 4MB to 256MB, all of which the kernel is convinced was written to disk. IOW, disaster. Sincerely Yours 404.664.6401 Simon Shapiro Research Fellow, Earthlink Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: EVENTHANDLER_DECLARE
Sorry to bother y'll, but; Has anyone ever used that? I see no trace of any kernel code calling it, and the at_shutdown code appears to be gone. It's still used in the shutdown code; it was meant to be available for general use elsewhere, but I haven't seen anyone playing with it, so maybe the design tradeoffs were bad choices. BTW, for all it is worth, any caching controller not using this is guaranteed to lose data. Wrong layer. You should be using the bus shutdown method; look at eg. the Mylex driver to see how this is done. You should probably call your flush routine from the suspend method as well. (Note that the Mylex stuff doesn't correctly handle suspend/resume since we don't have a decent ACPI implementation yet) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: One more question (different now)
On 10-May-00 Marcel Moolenaar wrote:
Mike Smith wrote:
Ugh. I don't actually like that, because it serves a valid purpose.
What irritates me mostly is just that there is no way of casting a
volatile object into a non-volatile type, so you can't implement any sort
of conditional volatility exclusion.
You can however use a union and have a non-volatile object aliasing a
volatile object as in:
union u {
volatile int vi;
int nvi;
};
And you know for a fact that the compiler will generate
the right code. Right? :-)
Even if it did, I feel nervous. What if, in the example
above, the generated code does not clear the structure
on time, as indicated? What about other cases where
references to volatile data are being made?
Thanx for the tip, though...!
--
Marcel Moolenaar
mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
tel: (408) 447-4222
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Sincerely Yours
404.664.6401
Simon Shapiro Research Fellow, Earthlink Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: EVENTHANDLER_DECLARE - solved
Correction to the below message; Figured it out all by myself :-) Thanx! On 10-May-00 Simon Shapiro wrote: Sorry to bother y'll, but; Has anyone ever used that? I see no trace of any kernel code calling it, and the at_shutdown code appears to be gone. BTW, for all it is worth, any caching controller not using this is guaranteed to lose data. that can range from 4MB to 256MB, all of which the kernel is convinced was written to disk. IOW, disaster. Sincerely Yours 404.664.6401 Simon Shapiro Research Fellow, Earthlink Inc. Sincerely Yours 404.664.6401 Simon Shapiro Research Fellow, Earthlink Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: EVENTHANDLER_DECLARE
On 10-May-00 Mike Smith wrote: Sorry to bother y'll, but; Has anyone ever used that? I see no trace of any kernel code calling it, and the at_shutdown code appears to be gone. It's still used in the shutdown code; it was meant to be available for general use elsewhere, but I haven't seen anyone playing with it, so maybe the design tradeoffs were bad choices. I dunno. It seems to do anything I need; Call me with an argument. I do not even need the priority. BTW, for all it is worth, any caching controller not using this is guaranteed to lose data. Wrong layer. You should be using the bus shutdown method; look at eg. the Mylex driver to see how this is done. You should probably call your flush routine from the suspend method as well. This is dangerous for the OSM. When the i2o OSM shuts an IOP down, it is history. It will stop doing any work at all; network, disk, console, mouse, whatever. I reserve that for really, really shutdown/reset. This needs to happen after all other shutdown work was done, but before a physical reset is sent to the hardware. There is no telling how long the IOP will take to return from flush request. (Note that the Mylex stuff doesn't correctly handle suspend/resume since we don't have a decent ACPI implementation yet) I can emulate suspend/resume in the OSM easily. Actually, it does that just before shutting down. A single line of code. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message Sincerely Yours 404.664.6401 Simon Shapiro Research Fellow, Earthlink Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a better idea for package dependencies
On Tue, 9 May 2000, David O'Brien wrote: On Mon, May 08, 2000 at 06:30:17PM -0400, Kenneth Wayne Culver wrote: Actually, it has to do with the pkg_ commands, which I believe are built when you make world... yes. and aren't part of the ports, And are only used for Ports. Thus their behavior defines the behavior of the Ports Collection. Thus it is a Ports issue. IF the pkg_* utils were ports, how would you install them?? Oh, will you get off it? Finally someone posts something about a *technical* issue, it's got at least some reasonable claim to be on the list (it's sure involving sysinstall, if obliquely) and it's not giving a lot of noise. There must be better things to complain about. I could offer you maybe a dozen if you're not feeling particularly investigatory right now. Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: One more question (different now)
On 09-May-00 Mike Smith wrote: On Tue, May 09, 2000 at 04:27:10PM -0700, Mike Smith wrote: The only answer I've seen for this one is to kick, hard, whoever it was that added -Wcast-qual to the kernel options. Or we should just delete it from the options. Ugh. I don't actually like that, because it serves a valid purpose. What irritates me mostly is just that there is no way of casting a volatile object into a non-volatile type, so you can't implement any sort of conditional volatility exclusion. Agree. It is a mess. Ideally, if an object is volatile, then it should be respected as so. always. The ANSI standard is too vague on this issue and the number of poor suckers that have to have it is too small. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message Sincerely Yours 404.664.6401 Simon Shapiro Research Fellow, Earthlink Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: EVENTHANDLER_DECLARE
On 10-May-00 Mike Smith wrote: Sorry to bother y'll, but; Has anyone ever used that? I see no trace of any kernel code calling it, and the at_shutdown code appears to be gone. It's still used in the shutdown code; it was meant to be available for general use elsewhere, but I haven't seen anyone playing with it, so maybe the design tradeoffs were bad choices. I dunno. It seems to do anything I need; Call me with an argument. I do not even need the priority. It won't notify you that your code is about to be removed from the kernel. BTW, for all it is worth, any caching controller not using this is guaranteed to lose data. Wrong layer. You should be using the bus shutdown method; look at eg. the Mylex driver to see how this is done. You should probably call your flush routine from the suspend method as well. This is dangerous for the OSM. When the i2o OSM shuts an IOP down, it is history. It will stop doing any work at all; network, disk, console, mouse, whatever. I reserve that for really, really shutdown/reset. I'm not sure I understand what you mean by "dangerous". When your shutdown method is called, you're being told that you're about to stop being able to control your hardware, either because your code is about to be removed from the kernel (module unload) or because the system is being shut down. Before you return success from your shutdown method, you must have brought your hardware to a quiescent state, ready for immediate loss of power. It must not generate any more interrupts or access any more data once you have returned. You can veto your shutdown (by returning nonzero), which will fail a module unload, but _will_not_ fail a kernel shutdown. This needs to happen after all other shutdown work was done, but before a physical reset is sent to the hardware. There is no telling how long the IOP will take to return from flush request. That's fine. Again, the Mylex driver is doing exactly what you're talking about; I've been down this path just a few times now. 8) (Note that the Mylex stuff doesn't correctly handle suspend/resume since we don't have a decent ACPI implementation yet) I can emulate suspend/resume in the OSM easily. Actually, it does that just before shutting down. A single line of code. I'm assuming that you depend on the platform firmware to bring it out of any of the deep sleep modes, re-enumerate the PCI bus and restore all of its volatile state? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: EVENTHANDLER_DECLARE
Simon Shapiro wrote: On 10-May-00 Mike Smith wrote: Sorry to bother y'll, but; Has anyone ever used that? I see no trace of any kernel code calling it, and the at_shutdown code appears to be gone. It's still used in the shutdown code; it was meant to be available for general use elsewhere, but I haven't seen anyone playing with it, so maybe the design tradeoffs were bad choices. I dunno. It seems to do anything I need; Call me with an argument. I do not even need the priority. Well, you need to be called at "shutdown_post_sync" - anything before that is too soon as the kernel is still potentially pushing data out to the controller. This also happens to be where the module and bus shutdown events are called too. BTW, for all it is worth, any caching controller not using this is guaranteed to lose data. Wrong layer. You should be using the bus shutdown method; look at eg. the Mylex driver to see how this is done. You should probably call your flush routine from the suspend method as well. This is dangerous for the OSM. When the i2o OSM shuts an IOP down, it is history. It will stop doing any work at all; network, disk, console, mouse, whatever. I reserve that for really, really shutdown/reset. This needs to happen after all other shutdown work was done, but before a physical reset is sent to the hardware. There is no telling how long the IOP will take to return from flush request. That is no problem.. you can take as long as you need. The filesystems are unmounted, all the system daemons have been shut down, all dirty data has been pushed to the controller, sync(2) has happened. The system will do nothing else until your controller's shutdown method has returned. If you want to reset it after doing the flush, there is nothing stopping you - you can do it however you need to. 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-current" in the body of the message
Re: Abit BP6 - UDMA66 and non IBM disks
On Tuesday, 9 May 2000 at 4:14:01 -0500, Alan Cox wrote: About two days ago, I tested a machine with four IDE drives each on its own cable as the master. All four drives were: ad0: 29311MB Maxtor 53073U6 [59554/16/63] at ata0-master using UDMA66 I used the motherboard controller to support two of the drives. It was a atapci0: Intel ICH ATA66 controller port 0xffa0-0xffaf at device 31.1 on pci0 and a Highpoint-based ATA66 controller for the other two drives. The Highpoint locked up with the "resetting devices" message as soon as the system was stressed. I replaced the Highpoint controller with a Promise ATA66 and didn't see any problems after that. (I've never seen any problems with the Maxtor's on the Intel ATA66 controller either.) In summary, same disks, three different controllers, problems only occur with the Highpoint controller. (I believe the Abit BP6 uses the Highpoint controller.) I've had these symptoms too, but with a Western Digital drive. I'm still trying to track them down. They don't happen when running on ata0 or ata1. Søren suspects it to be a problem with the drive. 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-current" in the body of the message
Re: unknown: PNP...
Christian Weisgerber wrote: I just updated an i386 machine after a month to the latest 5.0-CURRENT, and I now get some strange boot messages: isa0: too many memory ranges ... unknown0: PNP at port 0x20-0x21,0xa0-0xa1 irq 2 on isa0 unknown1: PNP0200 at port 0-0xf,0x81-0x83,0x87,0x89-0x8b,0x8f-0x91,0xc0-0xdf drq 4 on isa0 Mike Smith wrote: Could someone please either take a look at this, or give an authoritative comment as to why it's happening. This is the ISA PnP code reporting devices enumerated via the PnP BIOS. At the moment, our support code isn't smart enough to use either the PnP interface or the resource manager, so the unknown device claims these resources to prevent anyone else trying to use them. It's quite harmless, and once things are cleaned up, you won't even see the messages. Something else I've noticed in the mean time is that PnP devices like my printer - that are also on buses that are probed for PnP devices - end up being probed twice at boot time. Can anyone give an ETA on when this "support code", as Mike puts it, will work properly? Christian "naddy" Weisgerber [EMAIL PROTECTED] Regards, Trent. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
Narvi wrote: Errrmmm Really, did you check the archives for the issue? There used to be a real long thread on why/why not sysV style init scripts. It produced not one but several flamewars iirc 8-) In short - if we change from the present scheme, we want something better than just stop and restart entry points for the scripts. What happens if the restarting is not an atomic, independent act? I already covered this. Please read all your mail on a thread before responding, thanks. Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
