Re: fxp driver not reset after Windows reboot?
Andrzej, did you receive a response regarding your email the Intel Pro 10/100B/100+ Ethernet being unresponsive after running windows? i seem to have the same problem. I'm working on the (longer-term) solution to this at the moment. In the meantime, it's going to need a driver tweak to fix. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cardbus woes
With the recent slaughter^Wrework of the PCI code, my hack to allocate resources for unattached PCI devices in pci_probe_nomatch() no longer works. The updated patch can be found at http://www.FreeBSD.org/~jhb/patches/cardbus.hack.patch. I have a set of working patches at http://ziplok.dyndns.org/msmith/pci.diff which handle resource reservation, making your hack unnecessary. They're not ready for commit yet, but they're known to work (assuming you get this message 8). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cardbus woes
I have a set of working patches at http://ziplok.dyndns.org/msmith/pci.diff which handle resource reservation, making your hack unnecessary. They're not ready for commit yet, but they're known to work (assuming you get this message 8). Cool, my hack is all b0rked anyways, so I'll try this out. No go. :( With this, my soundcard no longer probes properly: Verbose boot output, please? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI-PCI Bridge Problems
From: Michael Harnois [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 12, 2000 6:31 AM On Tue, 12 Dec 2000 05:02:59 -0800, Mike Smith [EMAIL PROTECTED] said: I'll keep working on this one; things will go a lot faster if I can get my hands on a system that misbehaves in a corresponding fashion. You're welcome to come to Iowa and use mine. I'll even put you up. Just make sure you bring a shovel... :-) Oh ick, snow. I hate that stuff. 8) On a more relevant tangent; Michael the first - is the most recent cut of the code still not finding things on your PCI bus? I noticed that your ATA controller *was* showing up... If you could, could you try applying http://ziplok.dyndns.org/msmith/pci.diff to a fresh -current source tree and building that? (Make sure you use 'config -g' as well, since the last set of problems reported may have been due to an unclean kernel compile directory). The output from a verbose boot with the above patch might help track some of this down. Thanks! Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI-PCI Bridge Problems
I cvsuped current ~2000/12/11 @ ~ 22:00, the previous version was from around 2000/12/07. Before the update my Dual intel nic was happy post update the nic isn't even probed. Hrm. That's odd; I have one of those here (with a Compaq label on it) as part of my test set. In fact, I have twelve different ethernet devices in the test machine right now trying to reproduce this. 8( attached is a pciconf -v -l from before and after as well as a a boot -v from after. If you need more info let me know and I'll go back to the 2000/12/11 kernel. About the only thing different I can see between your setup and mine is that your bridge gets bus 6, but comes up as pci bus 1. There may still be assumptions somewhere in the code that the pci bus device number corresponds to the bus number, although I'm not having any luck finding them. 8( I'll keep working on this one; things will go a lot faster if I can get my hands on a system that misbehaves in a corresponding fashion. Thanks for the report; keep your eyes out for commits to the PCI code that mention this problem. If you do try again, please let me know how you go. If you're motivated to get involved with the code, I'd be more than happy to point you at a few things worth checking out. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI-PCI Bridge Problems
I cvsuped current ~2000/12/11 @ ~ 22:00, the previous version was from around 2000/12/07. Before the update my Dual intel nic was happy post update the nic isn't even probed. attached is a pciconf -v -l from before and after as well as a a boot -v from after. If you need more info let me know and I'll go back to the 2000/12/11 kernel. Actually, I take some of what I said back. pcib1@pci0:13:0: class=0x060400 card=0x00dc chip=0x00241011 rev=0x03 hdr=0x01 vendor = 'Digital Equipment Corporation' device = 'DC21151/2 PCI-PCI Bridge' class= bridge subclass = PCI-PCI ... pcib1: PCI-PCI bridge at device 13.0 on pci0 pcib1: secondary bus 6 pcib1: subordinate bus 6 pcib1: I/O decode0x6-0x60fff pcib1: memory decode 0x0-0xf pcib1: prefetched decode 0x0-0xf pci1: physical bus=6 pci1: PCI bus on pcib1 There are bugs in the code you're running that I fixed tonight, but even so the decode registers there look *totally* wrong. Please cvsup and try again; I'm just about to commit some patches to the bridge code that should at least get that part right, then we'll see what's still going on. Sorry about this. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/usr/local vs. /usr/pkg
Andreas Klemm [EMAIL PROTECTED] types: On Mon, Dec 11, 2000 at 12:37:54AM -0500, David Gilbert wrote: ... but /usr/pkg supplanting /usr/local is one of the things that I like about NetBSD. /usr/pkg sounds a little bit odd ... ( at least for my ears). Why not choose what Solaris uses (/opt) ? I'd prefer /usr/opt. However, the reason not use either one is *because* Solaris uses them. See below. It would be an advantage, when designing filesystem size of your OS, that now you would have two completely separate paths /usr and /opt. But it also means you either have another file system where the OS is going to install things, or you have to make (in your words) too large a root file system. Installing ports in /usr means, having a too large /usr or to mount a new filsystem under /usr (/usr/local). Mounting an fs under a mounted fs I dislike much ... I take it you mean "Mounting an fs under a mounted fs other than root ...". But how do you decide what's "too large"? From what I can tell, best practice for first installs these days is to create two very large file systems. Everything installed from the distribution media (or sources) goes on /, and everything else goes in /home. If there isn't going to be anything saved locally, you ignore /home. I would claim that /opt is as bad as /usr/local, for the same reason. It has a history that predates BSDs usage of it for anything, and FreeBSD using it will cause problems for people who think that historical usage is different from installing software that comes with (or through) the OS distribution. My choice (/usr/opt) is bad for the same reason. I don't think /usr/pkg has any use prior to NetBSD using it for installed ports/packages, so it doesn't have that problem. Whether it goes on / or /usr is actually a minor issue. I want packages installed on /usr. If the standard winds up being /opt, I'll just symlink /opt to /usr/opt, and forget it. Likewise, if the standard is /usr/opt, you can symlink /usr/opt to your file system on /opt, and forget it. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/dev/pci isa_pci.c
On Sun, Dec 10, 2000 at 03:15:19AM -0800, Mike Smith wrote: msmith 2000/12/10 03:15:19 PST Modified files: sys/dev/pci isa_pci.c Log: The ICH2 reports itself as a PCI:ISA bridge, so don't special-case it here. On a related(?) note, my 810 (ICH) hasn't seen pci devices for a few days. By removing the ICH line from isa_pci.c, the warnings go away, but nothing is seen. Full dmesg's can be found at: http://www.fxp.org/~jedgar/FreeBSD/ICH/ Something funky is going on with the ICH's. I'm going to try to get hold of an i810 system tomorrow and work it out. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PCI power states (was Re: fxp driver not reset after Windows reboot? )
Based on the above, I would say that Windows has powered-down the NIC. This is outside of the scope of the driver, so I don't think a solution should be implemented there. Probably something for our APM folks. It's actually an ACPI-ish issue, however drivers are probably going to have to change to support it correctly. I'm not 100% keen on having the PCI code unconditionally bring a device to D0 before handing it over for probe or attach; I got bitten by this just recently with activating I/O and memory ranges, and I think the only way for things to be done safely is going to be for a PCI driver to be required to: - check and enable busmastering - check and enable memory/port I/O as required - bring the device to D0 power state All of these can be abstracted as PCI methods, so they won't require lots of cut-n-paste in each driver: pci_enable_busmaster(dev); pci_enable_io(dev, SYS_RES_IOPORT | SYS_RES_MEMORY); pci_set_powerstate(dev, PCI_POWERSTATE_D0); Consider the above a request for review on the matter. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
David O'Brien [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 11:33:33PM -0600, Mike Meyer wrote: The thing is, the package system has grown into something more than that. It really is vendor-supplied and vendor-supported third party software, and part of the distribution. I can back this up. As someone that maintains over 120 FreeBSD Ports, I get all kinds of email wanting support and this and that tweak in the Port (and thus pre-compiled Package) that they don't want to have to download the distfile and do the hacks themselves. In fact many of our Ports have quite a bit of patching to add very significant functionality changes than one would get if they took the distfile, built and installed the software the way the author intended them to. Thus the Ports Collection Packages are something very specific to FreeBSD and are not just random 3rd party software. I'm one of the people who send patches to the port maintainer. There are a couple of reasons for this. First, I get the *port* fixed faster that way. In some cases, the original author wasn't interested in the fixes, or was to busy to issue a new release, so the only way to get those into the port was through the port maintainer. The alternative was to quit building those from ports, and start building them as locally maintained software so I could apply the patches. Another reason is that I've found the port maintainer usually has a working relationship with the software author, and so patches that he's reviewed and passed on to the author get dealt with faster than if I sent them on myself. In at least one case, sending patches to the author was completely ignored. Sending them to the port maintainer got the port fixed in a matter of days, and the patches forwarded to the software author were added to the system for the next release (at which time the port patches could go away). mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Applix problems (Was: /usr/local abuse)
David O'Brien [EMAIL PROTECTED] types: On Mon, Dec 11, 2000 at 08:14:47AM -0600, Mike Meyer wrote: The problem is that the shared libraries aren't getting found when I run the applix binary after a reboot. Why do you say that? Where is the error message?? I say that because 1) that was VistaSource support's diagnosis, and 2) doing the ldconfig fixes the problem. The error message is in last Sunday, and not currently recreatable. /usr/local/applix/axdata/axshlib are ELF shared objects. I haven't investigated further. If someone got an explanation, I'm all ears. Applix sets LD_LIBRARY_PATH in order to find its shared libs. EXACTLY how are you [trying to] run it? The sequence goes like this: middle click to open a 9menu window. Left click on the word "applix", which causes 9menu to start a shell running the command "applix". The shell finds /usr/local/bin/applix on my path, and runs *that*. At that point, you're running VistaSource's software, so they should give you the details. After rebooting last Sunday, I did this - and the disk drives flashed, and the cpu load went up a bit, and then it all settled back down. I then followed the instructions I got from VistaSource for shutting applix down after it fails to start, which is to find and kill all the processes that have "applix" in the command line and remove the sockets it creates in /tmp. After that, I su, grep for ldconfig in /etc/rc, type "ldconfig " at a root prompt, copy and paste the ldconfig line (which has axshlib in it" to that prompt, and hit return. Then repeat the process to launch it, only this time I get a splash screen (why do people want to do that bit of WBD on Unix?) and the Applixware Office Iconbar before the disk thrashing ends. And that's all the details I have. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI power states (was Re: fxp driver not reset after Windows reboot? )
pci_enable_busmaster(dev); pci_enable_io(dev, SYS_RES_IOPORT | SYS_RES_MEMORY); pci_set_powerstate(dev, PCI_POWERSTATE_D0); Consider the above a request for review on the matter. Shouldn't that be: pci_enable_io(dev, SYS_RES_IOPORT | SYS_RES_MEMORY); pci_set_powerstate(dev, PCI_POWERSTATE_D0); device_specific_init(dev); pci_enable_busmaster(dev); In terms of ordering? Yes, definitely,and thanks for pointing it out. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Applix problems (Was: /usr/local abuse)
David O'Brien [EMAIL PROTECTED] types: On Mon, Dec 11, 2000 at 05:24:19PM -0600, Mike Meyer wrote: At that point, you're running VistaSource's software, so they should give you the details. Then I'll just back out of trying to help figure out why many others can run it outside of /usr/local. While I appreciate the help, it seems you missed a point. I reinstalled it in /usr/local - and ran into the exact same problem I had with it outside /usr/local (that it requires some frobbing after a reboot to work properly). I was wrong when I said it didn't like being moved; it just took rebooting to expose the problem, and it wasn't until last Sunday that I rebooted with it installed in /usr/local. Others have noted that the script it installs in $(PREFIX)/bin/applix has /usr/local wired into it, though. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [current] Re: Confusing error messages from shell image activation
Michael C . Wu [EMAIL PROTECTED] types:
I know I should not jump into this bikeshed. But IMHO, whereever
we have our packages install to, we should also place
our ports metadata (/var/db/pkg) and the ports skeleton in the
same place, preferably a mountpoint. This allow me to switch
between different sets of installation with ease. (No, please
do not tell me to change PREFIX and mv /usr/local /usr/local.bak)
With this setup, I can rm -rf whatever place this goes, and
have a clean system again. For the ports developers, we can
switch between configurations without the need for chroots or
jails taking up disk space.
Ok, I can see wanting that. And I can see how it would be handy for
ports developers. But my instant reaction was "yuch". The reason for
that is that, unlike the contents of ${PREFIX}, the contents of the
ports metadata is *not* generally recreatable from the /usr/ports
tree. This means it's more precious, and you might want to back it up
more frequently, etc.
While some method for ports developers to move the metadata (say an
environment variable) should be provided, I think the above is a good
reason for leaving the default as is.
BTW, pkg_add (at least) honors the environment variable PKG_DBDIR to
set the location of the ports metadata directory. Is there some reason
you can't just set that to /usr/local/etc/db/pkg or some such?
Final comment - I wish more ports developers *would* set PREFIX.
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Applix problems (Was: /usr/local abuse)
David O'Brien [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 11:42:37PM -0600, Mike Meyer wrote: On the other hand, Applixware Office ships a precompiled package for /usr/local, and doesn't like being installed anywhere else. Which means I've got a couple of hundred megabytes being backup up for no good reason :-(. Mine lives in /usr/opt just fine. What signs do you have of it not liking being out of /usr/local ? Tony Maher [EMAIL PROTECTED] types: On the other hand, Applixware Office ships a precompiled package for /usr/local, and doesn't like being installed anywhere else. Which means I've got a couple of hundred megabytes being backup up for no good reason :-(. Really?! I have it installed in /opt/applix and I dont think there are any symlinks anywhere in /usr/local for it. It works fine. My bad. I discovered last night that the problems I though were associated with it not being installed in /usr/local are occuring even though I *did* install it in /usr/local. Of course, last night was the first time I've rebooted with it installed in /usr/local, and that's when the problem shows up. The problem is that the shared libraries aren't getting found when I run the applix binary after a reboot. Here's the relevant part of /etc/rc.conf: ldconfig_paths="/usr/lib/compat /usr/X11R6/lib /usr/opt/lib /usr/opt/pgsql/lib /usr/opt/pilot/lib /usr/local/lib /usr/local/applix/axdata/axshlib" ldconfig_paths_aout="" # No aout in my userlands After the first reboot, running applix just causes off a lot of disk activity and creates processes and a socket in /tmp. Killing them, removing the file in /tmp, and then running "ldconfig $ldconfig_paths" (though I do it with cut-n-paste) solves the problem, and I can run applix just fine. Failing to do the ldconfig (at least, with applix somewhere other than /usr/local) doesn't solve the problem. As far as I can tell, the only difference is that /etc/rc runs the ldconfig as "ldconfig -elf". All the files in /usr/local/applix/axdata/axshlib are ELF shared objects. I haven't investigated further. If someone got an explanation, I'm all ears. Thanx, mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local misuse (Was: Confusing error messages from shell image activation)
Warner Losh [EMAIL PROTECTED] types: In message [EMAIL PROTECTED] Mike Meyer writes: : I know. Unfortunately, support for PREFIX seems to draw more lip : service than actual service. Actually, which ports, specically, doesn't this work with? I've installed several ports with PREFIX defined to something odd and have had minimal problems. Well, all the ones I *specifically* know about I've already PR'ed. Except for the ones that use Perl, and I don't remember if PR'ed that, or just made sure the maintainer was was aware of it. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Daniel C. Sobral [EMAIL PROTECTED] types: Mike Meyer wrote: Rant second: FreeBSD *violates* years of traditions with it's treatment of /usr/local. /usr/local is for *local* things, not add-on software packages! Coopting /usr/local for non-local software creates needless complexity and confusion, which of course leads to needless pain. Not for everyone. FreeBSD adopted one of the ways /usr/local was being used. You can keep ranting on this and pretending the way above is how everyone used /usr/local as long as you want, but the fact is that you won't get this changed. Interesting. What other OS distribution put things that went into /usr/local on their distribution media? I don't expect to get it changed until enough people are aware that it's a problem. Occasional rounds of consciousness-raising are required to make that happen. That may not happen until the old guard dies of old age; I asume we both want FreeBSD to be a viable OS that long. Warner Losh [EMAIL PROTECTED] types: In message [EMAIL PROTECTED] Mike Meyer writes: : Corrections first: The only place where FreeBSD fails to follow FHS : (in my quick perusal of it) is in putting packages in /usr/local : instead of /opt. You can't blame that part of FHS on Linux - I have as : yet to see a Linux distro or package do it that way. No, this bit : comes from commercial vendors, where it's also steeped in years of : tradition. Not as many as you might think. /usr/local predates /opt by several years. I'm aware that software was installing itself in /usr/local years before it was installing in /opt. On the other hand, vendor software was installing in /opt years before I ever saw it install in /usr/local. : Rant second: FreeBSD *violates* years of traditions with it's : treatment of /usr/local. /usr/local is for *local* things, not add-on : software packages! Coopting /usr/local for non-local software creates : needless complexity and confusion, which of course leads to needless : pain. Ummm, software packages have been make installing into /usr/local since at least 1985 when I started building them. no coopting has been done. If memory serves (and it may not at this remove), /usr/local/bin wasn't on my path until I started using VAXen, meaning there were few or no packages installing in /usr/local on v6 v7 on the 11s. However, FreeBSD is still the only vendor distribution I know of that installs software in /usr/local. That's the problem - software that comes from the vendor doesn't belong in the local administrative regime. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Garrett Wollman [EMAIL PROTECTED] types:
On Sun, 10 Dec 2000 09:37:53 -0600 (CST), Mike Meyer [EMAIL PROTECTED] said:
However, FreeBSD is still the only vendor distribution I know of that
installs software in /usr/local. That's the problem - software that
comes from the vendor doesn't belong in the local administrative
regime.
No software that is a part of FreeBSD installs in /usr/local. As a
convenience feature, FreeBSD includes software from third parties
which does so, and in most cases has always done so by default.
Whether or not it's part of FreeBSD is immaterial. It's part of the
distribution that comes from FreeBSD, and is treated differentlyh from
locally installed software (whether written locally or by a third
party) in every case *except* where it installs - and that's only
because it's installed in the wrong place.
In other words, "It's not part of FreeBSD" is a rationalization.
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
/usr/local abuse
Joe Kelsey [EMAIL PROTECTED] types: Mike Meyer writes: If memory serves (and it may not at this remove), /usr/local/bin wasn't on my path until I started using VAXen, meaning there were few or no packages installing in /usr/local on v6 v7 on the 11s. If you remember v6 and v7, then please enumerate the packages which installed in /opt on those systems. All "packages" I am aware of from the v6/v7 era installed in /usr or in /usr/local, although I am sort of fuzzy on the exact derivation of /usr/local at this point in time. I do recall having a /usr/local on my V6 PDP-11/40, but it could have been contamination leaking over from the 32V system. I do remember the abomination of /usr/ucb which put binaries in /usr/ucb but also included /usr/ucb/lib, etc. I always hated that structure. I know that we made extensive use of /usr/local in 1983 on 4.1bsd, especially in installing software taken from Usenet, so I think that /usr/local really started with extensive use of Usenet distribution, which was coincident with wide-spread use of BSD on VAXen. As far as I remember, I never encountered the use of /opt until Solaris. That's what I remember as well. So what? I'm not advocating that packages install in /opt. I'm claiming that installing them in /usr/local is a mistake. Other distributions that have adopted FreeBSD's package/ports system have benefited from that mistake by avoiding it. Then again, your quoting of "packages" points up something else - I never saw prepackaged binaries for v6 or v7. Or BSD, for that matter. I never encounterd a package system until Solaris. That would make /opt a tradition as old as packages. Brian Dean [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 10:13:42AM -0600, Mike Meyer wrote: Whether or not it's part of FreeBSD is immaterial. It's part of the distribution that comes from FreeBSD, and is treated differentlyh from locally installed software (whether written locally or by a third party) in every case *except* where it installs - and that's only because it's installed in the wrong place. In other words, "It's not part of FreeBSD" is a rationalization. You are really reaching here. Contributed software that the FreeBSD Project has chosen to integrate, i.e., Perl, Sendmail, just to name a few, are integrated tightly and installed in /usr/bin, etc, not in /usr/local. Actualy, I'm *responding* to someone who's really reaching. Ports, on the other hand are installed in /usr/local or /usr/X11R6. What happend to "that's what PREFIX is for"? You seem to mis-understand that a FreeBSD port is basically a set of patches and a source fetching mechanism that is included with FreeBSD as a convenience for building and installing third party software. The actual software that gets built and installed is _not_ part of FreeBSD. This is not a rationalization. You didn't read what I wrote. I never claimed that packages or a ports are part of FreeBSD (after all, I do know what they are). I claimed that they are part of the FreeBSD distribution. Or are you going to deny that the ports tree and binary packages are on the installation cdrom? Sure, the software in ports/packages aren't part of FreeBSD. Using that to claim they should have the same status or treatment as locally written or maintained software is a rationalization. I for one would be really upset if when I installed a Port, it's binaries started getting dropped into /bin, /usr/bin, etc. I suspect many others would too. I won't argue - that's pretty clearly a mistake as well. I'm really not exactly sure what you are complaining about. For example, the last time I built Emacs for Solaris (several years ago admittedly), by default it installed itself into /usr/local. If you install Emacs onto FreeBSD, it goes into /usr/local. The behaviour is the same. Are you proposing that since FreeBSD provides a set of patches so that Emacs builds cleanly, that it should therefore install it somewhere other than /usr/local? You seem to mis-understand what a port does. Any port that doesn't provide exactly that set of patches is broken. If I install emacs from the ports tree, the package database will claim that all the files are in /usr/opt. If some files from the port land in /usr/local, then the port is not PREFIX clean, and should be fixed. Basically, I'm complaing that 1) the default PREFIX for ports co-opts part of the file name space that it shouldn't, and 2) PREFIX is given only lip service. Fixing #1 is the best option, because people who think local means local could use precompiled packages from the FreeBSD project and commercial vendors with the same administrative regimen they give all software that isn't locally maintained. Fixing #2 would help, though. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Package installation location
Forrest Aldrich [EMAIL PROTECTED] types: Haha... okay, then what's the argument about. You're about six years late. The ports system has used $PREFIX for precisely this purpose since October 1994. As Jacques pointed out, you set LOCALBASE in /etc/make.conf. The problem is that *it doesn't work*. Well, not very well. Part of it is that it's only given lip service: the porters handbook says "make your ports PREFIX clean"; portlint doesn't do any checking about it. The porters handbook doesn't even provide instructions on how to test for whether or not a port is PREFIX clean. Making things LOCALBASE clean isn't even suggested. Admittedly, most port maintainers respond well when I report that things are broken, but checking for this should be done before the port is commited, not afterwards! Lots of other random things break: Packages built with a PREFIX value cannot reliably be installed with another value of PREFIX (no, I don't think that should be a requirement). This means that the prebuilt packages on the CDROM are unusable under these conditions. Since distfiles have been banished from the distribution, the pain of setting PREFIX to anything other than /usr/local for my clients that don't have good network connectivity is higher than the cost of doing intermixing the two different file types. For commercial packages, that's not even an option! The system perl build checks the /usr/local tree for modules, not the LOCALBASE tree. Perls module installation package also installs things in /usr/local, no matter what LOCALBASE is set to. This means that all ports that install PERL modules either 1) aren't PREFIX clean or 2) don't find those modules if they are. The python port breaks the other way: the binary only checks the LOCALBASE heirarchy for modules(*). Locally maintained modules wind up being scattered in among the ports modules, and thus require special treatment. I'm not sure about other ports that support modules, but it wouldn't surprise me if they had similar problems. Ports that have build dependencies on other binaries sometimes assume that the binary in question is on roots path. The startup scripts in /root set the path to include things in the /usr/local heirarchy, *not* the LOCALBASE heirarchy. Thus those builds - while being PREFIX clean - are still broken (not LOCALBASE clean). In fact, all the hook for supporting "local" things are pointed directly at /usr/local; none of them check LOCALBASE. All of these would be solved if the FreeBSD took a lesson from their peers. Most of them could be solved without changing the default value for LOCALBASE - if people wanted them solved. mike *) Python calls them packages; I'm using the Perl terminology to avoid confusion. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Nat Lanza [EMAIL PROTECTED] types: Mike Meyer [EMAIL PROTECTED] writes: Whether or not it's part of FreeBSD is immaterial. It's part of the distribution that comes from FreeBSD, and is treated differentlyh from locally installed software (whether written locally or by a third party) in every case *except* where it installs - and that's only because it's installed in the wrong place. In other words, "It's not part of FreeBSD" is a rationalization. Your argument doesn't make much sense to me. Ok, let's walk through the details (bottom of the letter). So if I compile sawfish myself I should install it in /usr/local, but if I install a FreeBSD package for it, it should never go in /usr/local? It should go where you want it to. /usr/local is a bad place because of it's tradition of being for locally maintained software. If I grab a sawfish FreeBSD package from the sawfish website, where should that install? /usr/local? /opt? /usr/pkg? Not /usr/local - that's for locally maintained software. I'd rather it go on /usr, so I don't like /opt. When I got to choose, I chose /usr/opt. But anything other than /usr/local on /usr would do as well. Third party software is third party software, no matter who compiled and packaged it. That's true. But if it's packaged, it belongs in an area reserved for *packages*. FreeBSD is the only system I know of that coopts /usr/local for packages, instead of reserving it for things that are locally maintained. Whether that locally maintained software is written locally or comes from a third party is irrelevant to this discussion. If I install a package of third-party software, the end result should be about the same as if I compiled and installed it by hand -- the packaged software is a convenience, not a fundamentally different entity. That's correct. The differences aren't in the software, they are in the administrative regimen. Let's look at how you deal with FreeBSD proper, ports/packages, 3rd party software that isn't from a port or package, and locally written software. Administrative FreeBSD port/pkg3rd party local item Binary from FreeBSD FreeBSD author author Source from FreeBSD patches and author author location from FreeBSD Responsible for FreeBSD Portlocal local it building on maintainer maintainer maintainer maint- my FreeBSD box ainer requires local src No No Yes Yes configuration? Updates fromFreeBSD FreeBSD author author Patches best sent FreeBSD Portauthor author to maintainer maintainer As you can see, the only difference between locally written software and third party software is that the author in the latter case is local. Meanwhile, the primary difference between software that is part of FreeBSD and a port/pkg is that the person who takes responsibility for some part of FreeBSD is always a FreeBSD committer, whereas the person who takes that responsibility for a port/package may not be a FreeBSD committer. Sure, sometimes that person for a port is the author - but that's also true for FreeBSD. For 3rd party and local software, you always deal with the author; for FreeBSD and a port or package, you deal with an intermediary that has taken responsibility for the software on FreeBSD, who may *not* be the author. The critical difference is the "requires local src configuration" line. For FreeBSD or any of the ports or packages, I can blow away the source tree without worrying about needing it back; I can always get it back from FreeBSD again. For the same reason, I don't worry much about the binaries. For locally written software, if I lose ths source, I'm SOL. For true third party software, how screwed I am depends on how hard it was getting the thing to build on FreeBSD. As a general rule, I always save them. The binaries get the same treatment. Having to figure out which is which is *much* easier if the two are in different directory hierarchies. Clearly, a package is *not* the same as either third party or locally written software. For people who don't care about any of those differences, packages co-opting /usr/local doesn't matter. For people who do, there's PREFIX - except it doesn't work very well, and can't work for binary builds (and with the CDROM set no longer having distfiles on it, that's a major PITA). mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Package installation location
Brian Dean [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 01:02:09PM -0600, Mike Meyer wrote: The problem is that *it doesn't work*. Well, not very well. Part of it is that it's only given lip service: the porters handbook says "make your ports PREFIX clean"; portlint doesn't do any checking about it. The porters handbook doesn't even provide instructions on how to test for whether or not a port is PREFIX clean. Making things LOCALBASE clean isn't even suggested. Just to nitpick this one statement, PREFIX is set to LOCALBASE (see /usr/ports/Mk/bsd.port.mk) so if PREFIX is honoured by the port, then LOCALBASE will be honoured by default. Not doing it this way would not allow you to override PREFIX for one particular port. Thus if you set LOCALBASE to /usr/opt in /etc/make.conf for instance, but for port "foo" you want it to go somewhere else, you can build that with make PREFIX=/usr/local/foo, for instance. If foo honoured LOCALBASE instead, it would ignore your one-time PREFIX override. Thus PREFIX is the correct thing for the ports to worry about, not LOCALBASE, LOCALBASE just being the default value for PREFIX. My bad - I coined the phrase "LOCALBASE clean" to describe a situation I've seen, without explaining the meaning. Wherease "PREFIX clean" means "all installed files are in the PREFIX tree", I intend "LOCALBASE clean" to mean "all files installed by other ports are looked for in the LOCALBASE tree". The porters handbook explains this, but doesn't even mention that it's something that could break your ports build if you don't obey it. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
Joe Kelsey [EMAIL PROTECTED] types: Mike Meyer writes: Sure, the software in ports/packages aren't part of FreeBSD. Using that to claim they should have the same status or treatment as locally written or maintained software is a rationalization. You are simply wrong in your characterization of /usr/local. As far back as I can remember, /usr/local has been used for locally installed software as separate from the default software in /bin and /usr/bin. I have personally use /usr/local to install software obtained from Usenet since at least 1983. I estimate that 90% of my /usr/local use has been for software obtained over some network distribution mechanism, and only 10% has been for actually locally written software. Actually, my characterization of /usr/local agrees with that 100%. What you've missed is that the important characteristic of ports/packages isn't that they are "software obtained over some network distribution mechanism." After all, the entire FreeBSD distribution fits that category. Are you therefore going to argue that it should all be installed in /usr/local because I get it from a CVS server? Each vendor supplied their own packaging commands, as SunOS did long before Solaris (really SYSVR4). The correspondence between ports and packages in FreeBSD is really quite separate from the distribution packages. Simply because a package exists does not make it part of the distribution. At least FreeBSD uses a different nomenclature for each, unlike Red Hat which calls everything an RPM and you can't tell the difference between what Red Hat officially includes in the system and what is simply a pre-compiled port. True - mere existence doesn't make a package part of a distribution. Being put on the distribution media makes it part of a distrbution. However, as shown above, the distribution mechanism is *irrelevant* to this debate. Definition: distribution: officially part of FreeBSD. I don't agree. A distribution is a software collection bundled and distributed together. port: A set of patches, source and makefiles to ease the process of installing third part software. Yes, and the ports are part of the FreeBSD distribution, even if they aren't part of FreeBSD. package: A pre-compiled port. Yup. Some some packages are part of the FreeBSD distribution (again, without being part of FreeBSD), and some aren't. I don't have any problem seeing the distinction between a port/package and the official FreeBSD distributions. Neither do I. Nor do I have any problem seeing that it's *irrelevant* to the issue at hand. Using the fact that something distributed with FreeBSD is a port instead of "officially part of FreeBSD" is just a rationalization for the system defaulting to a behavior that creates administration problems and increases the overhead of running a system. Joe Kelsey writes: When the BSD started, they tried to distinguish between /usr/local and /usr/public, but that never took hold. Certainly, when GNU distributions started, the FSF very quickly took up the then default (from the long history of standardized distributions in the moderated unix source newsgroups, both before and after the great renaming) usage of /usr/local as the place for network distributed software packages. Basically, /usr/local is for anything the local administration wants to officially support. The ports use of this (and by extension, pre-compiled ports (packages)) is thus completely justified. Are you therefore claiming that the "official FreeBSD" distribution is not officially supported by the local administration? Seems a strange position to take for someone who wants to run FreeBSD. Of course, anyone who actually deals with users knows that they assume anything installed on the system is officially supported by the local administration - even if there are explicit statements otherwise. The issue isn't support, the issue is maintenance. Anything you get from FreeBSD - whether officially part of FreeBSD or just a port or package - will work on FreeBSD as is (failure to do so is a bug), can be gotten from FreeBSD again, and there are tools bundled with FreeBSD to detect updates (which come from FreeBSD), install and uninstall the software. None of that is true for third party software, meaning you need locally grown mechanisms to back up, install, uninstall, etc. such software. It's a *lot* easier to do that if the two classes of software are in two different trees. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
David O'Brien [EMAIL PROTECTED] types:
This control is part of why it would be nice to have /usr/pkg separate
from /usr/local. I've given up on FreeBSD and had to create my own
/usr/treats to hold what should have been in /usr/local if the FreeBSD
Packages hadn't polluted it.
I went the other way, because "that's what PREFIX is for". I figured
there would be less pain involved in moving a system designed to be
moved than in moving random software that may or may not be so
designed. After having done so for a while, it's not at all clear that
was a correct decision. That this is the case says a lot about the
implementation of that design, none of it good.
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
Joe Kelsey [EMAIL PROTECTED] types:
David O'Brien writes:
On Sun, Dec 10, 2000 at 11:22:17AM -0800, Joe Kelsey wrote:
Basically, /usr/local is for anything the local administration wants to
officially support. The ports use of this (and by extension,
pre-compiled ports (packages)) is thus completely justified.
Do you understandy why NetBSD's Packages install in /usr/pkg ?
What is your position behind that?
I have no problem with /usr/pkg. I personally do not see the need for
it. I have been arguing with Mike over his historic characterization of
/usr/local as being a repository of locally written software, and I
think I have proved my point that his characterization is incorrect.
I think I've proved that you completely misunderstood my
characterization of /usr/local. I also think that I proved Brandon's
characterization of using /usr/local for packages as "steeped in
decades of tradition" as false.
My argument is solely that Mike is incorrect in characterizing
/usr/local as a place for locally written software. I also find that
his table is incorrect historically. The table he presented conveys his
*wish* for administrative purposes and his attempts to justify it by
some sort of historical argument do not hold water.
I don't think I ever claimed that it was solely for locally *written*
software. I claimed it was for locally *maintained* software. There's
a difference.
I don't know where you got the idea that the table had any kind of
historic representation. Nothing in it represents *history*. It
describes the world as it is now. If you feel that something in it is
incorrect, please say what it is instead of making vague statements
about the entire table.
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
PREFIX clean vs. LOCALBASE clean (Was: Package installation location)
David O'Brien [EMAIL PROTECTED] types: Wherease "PREFIX clean" means "all installed files are in the PREFIX tree", Correct. I intend "LOCALBASE clean" to mean "all files installed by other ports are looked for in the LOCALBASE tree". If all ports are PREFIX clean, you will have that. Thus it doens't need to be discussed separately. Using the two definitions above, the first sentence is false. In particular, assume that the port APort depends on BPort in some way, and is PREFIX clean. That means that everything in APort is installed in PREFIX, and all APorts references to things in APort look for them there. Neither of those statements precludes APort from looking for things that are part of BPort directly in /usr/local instead of in LOCALBASE. Doing so would make APort PREFIX clean while it was not LOCALBASE clean. I've only seen this break during the build. Most typical is the applications configuration software looking in /usr/local for an include file or library from BPort instead of looking in LOCALBASE. Some things assume that $(LOCALBASE)/bin is in the path, which is probably true for most users. However, the scripts provided by FreeBSD in /root add /usr/local/bin, *not* $(LOCALBASE)/bin. So such runtime dependencies don't break for users, but do for root - which means they are more likely to be noticed if they are build dependencies than if they are run dependencies. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
Crist J. Clark [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 01:51:25PM -0800, David O'Brien wrote: On Sun, Dec 10, 2000 at 12:26:38PM -0800, Joe Kelsey wrote: To the extent that NetBSD *forces* the local administrator to use /usr/pkg, I find it contains the same deficiency. Nope. One can ``ln -s /usr/local /usr/pkg'' and get the behavior those that like everything in one place prefers while still segregating stuff for those that prefer it. That makes no sense. The big argument has been that packages should not go into /usr/local because /usr/local is for something else. If you symlink do the symlink trick, you only have one real location for files. If you were to do that, /usr/local or /usr/pkg would be identical. Might as well make /usr/local the "real" location and symlink /usr/pkg. What's the difference? The difference is the cases aren't symmetric. If you want the two merged, then it doesn't matter what the system calls it, you can symlink your preferred name to theirs (or vice versa) and you're done. If you want the two split, the system name becomes something you *can't* use for your local packages, period. Which is why FreeBSD choosing a name that has a historical usage is bad. If someone feels that packages aren't appropriate for that historical usage and wants to use other software that wants that usage, they're screwed. PREFIX lets people feel smug about being able to move it, but as far as I was able to determine when I asked, no one with the commit bit actually runs systems using PREFIX that way. Providing an untested "solution" isn't a good thing. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PREFIX clean vs. LOCALBASE clean (Was: Package installation location)
David O'Brien [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 02:19:12PM -0600, Mike Meyer wrote: I intend "LOCALBASE clean" to mean "all files installed by other ports are looked for in the LOCALBASE tree". If all ports are PREFIX clean, you will have that. Thus it doens't need to be discussed separately. Using the two definitions above, the first sentence is false. How is it false? As described below. In particular, assume that the port APort depends on BPort in some way, and is PREFIX clean. Which is PREFIX clean? Aport or Bport? (it is often good to not use pronouns in technical disucssions...) Actually, dangling pronouns are bad in any discussion, and that was one. Both are PREFIX clean. That means that everything in APort is installed in PREFIX, and all APorts references to things in APort look for them there. Which is correct if Aport is PREFIX-clean. By definition, yes. Neither of those statements precludes APort from looking for things that are part of BPort directly in /usr/local instead of in LOCALBASE. Yes it does if Aport is PREFIX-clean. s./usr/local.PREFIX.g and would be a better way to say it, adding PREFIX != LOCALBASE. Take a second look at the definition of the "PREFIX clean" you agreed to before, and the conditions I stated above: all files installed in by APort are in PREFIX, and all references to things installed by APort use PREFIX. That doesn't say anything about how APort references things installed by other ports! Of course, your suggested change fixes some of those cases, but it's not correct for things installed by other ports according to my reading of bsd.port.mk. The port being built things in PREFIX; other ports installed things in LOCALBASE or X11BASE, as appopriate. So fixing references to things in other ports requires s./usr/local.LOCALBASE.g, hence "LOCALBASE clean" for things that fail to deal with that case. As a final note, neither fix corrects the cases where the /usr/local reference that makes things work when LOCALBASE and PREFIX are both /usr/local comes from outside of the ports tree completely. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Nate Williams [EMAIL PROTECTED] types: I'm aware that software was installing itself in /usr/local years before it was installing in /opt. On the other hand, vendor software was installing in /opt years before I ever saw it install in /usr/local. Most vendor software I know pre-dates /opt, and installed itself in /usr/local. I'm with Warner on this one, installing in /usr/local predates /opt by many years. Before /opt, vendors always used /usr/local, or worse they installed in /bin and /usr/bin. Oh, I agree that installing things in /usr/local predates /opt by years. I'm curious as to what vendor provided software installed itself in /usr/local, though, as I've never seen any. If memory serves (and it may not at this remove), /usr/local/bin wasn't on my path until I started using VAXen, meaning there were few or no packages installing in /usr/local on v6 v7 on the 11s. On V7 (the earliest software I have), vendor software installed itself in /usr/[bin|lib], which is IMO worse than /usr/local. That sounds like you're agreeing with me, at least about v7. Nate Williams [EMAIL PROTECTED] types: Then again, your quoting of "packages" points up something else - I never saw prepackaged binaries for v6 or v7. I did on SysIII. As a matter of fact, the entire distribution was bundled into separate packets (all of them installed in /usr). :( SysIII was not something I ever worked with. I went from v7 to BSD until, and stayed pretty much BSD until I started working with Solaris in the early/mid 90s. In any case, I think you're wasting your time trying to convince folks here. It appears to me that this is an argument going nowhere, and the claims you're making of history and tradition are way off the mark, thus making the arguments have much less weight. I few this as consciousness-raising. That's an ongoing process. My claims about "history" and "tradition" are attempts to refute Brandon's assertion that packages going into /usr/local has "years of tradition behind it." Mostly, it's about what *packages* are, not what /usr/local was used for. By your own admission, /usr/local wasn't used on v7. So the discussion should turn to when BSD started seeing prebuilt vendor packages to install in /usr/local. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Andrew Reilly [EMAIL PROTECTED] types:
On Sun, Dec 10, 2000 at 12:31:10PM -0600, Mike Meyer wrote:
Not /usr/local - that's for locally maintained software. I'd rather it
go on /usr, so I don't like /opt. When I got to choose, I chose
/usr/opt. But anything other than /usr/local on /usr would do as well.
So do you also put the configurations in ${PREFIX}/etc, or
/usr/local/etc? Even though you got them from a readily
replaceable source, you can't retrieve your local configurations
that way.
${PREFIX}/etc, and stored in perforce. The perforce database is on
/usr/local, and saved along with everything else.
In fact, *all* my system configuration files are stored in
perforce. In theory, I can restore a system configuration from
that. Since I haven't actually used it, I expect it to work as well as
setting LOCALBASE works.
That's true. But if it's packaged, it belongs in an area reserved for
*packages*. FreeBSD is the only system I know of that coopts
/usr/local for packages, instead of reserving it for things that are
locally maintained. Whether that locally maintained software is
written locally or comes from a third party is irrelevant to this
discussion.
Well, I'll just stick my oar in for /usr/local. I count myself
among the aesthetically dismayed when I first encountered /opt
on a SunOS box. (Or was that Solaris? Time fades...)
I dislike /opt as well. For two reasons. One is that it's not on /usr
meaning I have to either set aside another large FS for system
software, or tweak things to get it there. The other is that all the
packages have their copy of the hierarchy. If there were a hook to
install symlinks in a standard heirarchy under /opt, it wouldn't
bother me so much. But there isn't, so I have to figure out what needs
to be installed, do it by hand, and take some action to insure it gets
recreated if I need to do that.
The critical difference is the "requires local src configuration"
line. For FreeBSD or any of the ports or packages, I can blow away the
source tree without worrying about needing it back; I can always get
it back from FreeBSD again. For the same reason, I don't worry much
about the binaries. For locally written software, if I lose ths
source, I'm SOL.
Don't you keep the source that you write somewhere in your home
directory? I do.
Yup. I also keep the source for random software from the network in my
home directory. I don't keep the source for ports anywhere. That's
part of the basis for the claim that "installed over the network" and
"FreeBSD packages" are *not* identical, and losing the ability to
easily separate them is bad.
For true third party software, how screwed I am
depends on how hard it was getting the thing to build on FreeBSD. As a
general rule, I always save them. The binaries get the same
treatment. Having to figure out which is which is *much* easier if the
two are in different directory hierarchies.
Whenever I have to build something outside the ports hierarchy,
I finish by diffing the orig and modified source trees. I put
the source tarball into /usr/ports/distfiles, in case someone at
FreeBSD gets around to building a port of it, and stick the
diffs in my $HOME/src directory.
Why don't you go ahead and turn it into a port, and submit that? I've
done that - even for locally written software. Being able to use the
ports mechanisms to maintain the installation of software is a win. I
also PR them, and every once in a while one of them gets committed
before the ports structure changes so much the port is outdated.
Whether I turn true third party software into a port or not, I put
network sources in an external source branch, and my build version in
a local branch so I can use source software management tools to deal
with upgrades from the vendor. I *never* do that with a port. I don't
manage that software - someone appointed by FreeBSD does. Again,
that's a reason for wanting the two kinds of software in different
hierarchies, and FreeBSD coopting the place where much of that
software expects to be installed being a pain.
Clearly, a package is *not* the same as either third party or locally
written software. For people who don't care about any of those
differences, packages co-opting /usr/local doesn't matter. For people
who do, there's PREFIX - except it doesn't work very well, and can't
work for binary builds (and with the CDROM set no longer having
distfiles on it, that's a major PITA).
I agree that PREFIX/LOCALBASE should work: you can't legislate
taste. I'm going to keep it to /usr/local and /usr/X11R6,
though, thanks all the same.
Making the default something other than /usr/local makes it more
likely that PREFIX/LOCALBASE will work. Also, as was pointed out
elsewhere in the thread, if ports go somewhere that nobody uses for
anything, a simple symlink will make it look like it's where ever you
want it, and you get the two things merged. If
Re: Confusing error messages from shell image activation
Nate Williams [EMAIL PROTECTED] types: I ran mostly DEC boxes until the early 90s, which had all software installed in /usr/bin or /usr/local/bin. Well, I ran DEC boxes for Dec (at WSE) back in the late 80s and early 90s, and don't remember anything being in /usr/local that I didn't drag of the net (or write myself) and install there, on either VAXen or MIPS boxes. By your own admission, /usr/local wasn't used on v7. So the discussion should turn to when BSD started seeing prebuilt vendor packages to install in /usr/local. Late '80s on DEC boxes running Ultrix (which one could argue is one of the earliest commercial 'vendor' BSD unices). I don't consider Solaris a BSD unix, so it using /opt isn't a valid point, which makes the whole concept of '/opt' for BSD packages a moot point. :) I wish people would quite acting like moving packages out of /usr/local meant going to something like /opt. I don't think anyone in their right mind would suggest that. Probably the same time-frame for SunOS, although I didn't have experience with it until the early 90's. However, if necessary, I can try and dig out installation docs for some software which ask to have the stuff unpacked in /usr/local. I'd certainly be interested in that. Of course, as you yourself said, the argument about tradition is a sideline. The real issue is that ports/packages have one source, and things that may *not* have a mechanism to move them out of /usr/local (however badly broken) have another some of us want - quite legitimately - want to treat those two things differently, and packages using a directory name that has an established use makes that difficult. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/usr/local abuse
Nate Williams [EMAIL PROTECTED] types: By your own admission, /usr/local wasn't used on v7. So the discussion should turn to when BSD started seeing prebuilt vendor packages to install in /usr/local. Late '80s on DEC boxes running Ultrix (which one could argue is one of the earliest commercial 'vendor' BSD unices). I don't consider Solaris a BSD unix, so it using /opt isn't a valid point, which makes the whole concept of '/opt' for BSD packages a moot point. :) I wish people would quite acting like moving packages out of /usr/local meant going to something like /opt. I don't think anyone in their right mind would suggest that. '/opt', '/usr/pkg', '/whatever-you-want-to-call-it'. You were the one who claimed that Solaris was the first 'vendor' to provide packages, and they used opt. No, I said they were the first OS vendor I was aware of that used packages, as opposed to tarballs with ad hoc scripts. The real issue is that ports/packages have one source, and things that may *not* have a mechanism to move them out of /usr/local (however badly broken) have another some of us want - quite legitimately - want to treat those two things differently, and packages using a directory name that has an established use makes that difficult. Not true. You can change the source to point to '/usr/mike-likes-it-here', and it *should* work. If it doesn't, then it's borken. :) True. I can also go through and fix everything in FreeBSD to use /usr/packages-really-go-here, and release the resulting system as EvenMoreFreeBSD. This is probably a lot easier that what you suggest, as it involves fixing an identifiable set of software that claims to be configurable for that (to bad the claim is only partly true). Doing what you propose involves changing much larger set of software, much of which doesn't even claim to be movable in that way. Fixing broken things is a good thing. Your argument about moving it from /usr/local to show how broken is a good test procedure, but turning it into policy is something completely different. I *know* how broken it is - I tried to use the existing mechanism to move it, based on the argument in the above paragraph. The thing is, using *any* name that has ever been used by the community for something (doesn't really matter what) for something new is bad, because Unix doesn't have a mechanism that lets you separate things once they've been used. Using a totally new name avoids that, and linking it to the name you want is trivial. Hmm - maybe they should go in /usr/.local? I think the 'tradition' of FreeBSD installing packages in /usr/local is enough to leave things the way they are, especially since non-broken packages allow you to install it somewhere else on *your* system. FreeBSD, of course, *does* have such a tradition. NetBSD and BSD/OS don't. I can even see why, when jkh first built the port system, he would make it use /usr/local. After all, he's just making it easier for people to install software that normally installs there. The thing is, the package system has grown into something more than that. It really is vendor-supplied and vendor-supported third party software, and part of the distribution. Those claiming that packages aren't part of the FreeBSD distribution are claiming that something like 75% of the "FreeBSD subscription" isn't in the FreeBSD distribution. In which case, calling it a "FreeBSD subscription" would seem to be a misnomer as bad as calling a planet thats 75% water "dirt". mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Andrew Reilly [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 09:46:46PM -0700, Nate Williams wrote: Fixing broken things is a good thing. Your argument about moving it from /usr/local to show how broken is a good test procedure, but turning it into policy is something completely different. I think the 'tradition' of FreeBSD installing packages in /usr/local is enough to leave things the way they are, especially since non-broken packages allow you to install it somewhere else on *your* system. You have to admit that the "prebuilt packages" argument is a pretty good one. I don't used many myself (only cvsup, I think), but if it's true that the distribution CDs ship these pre-built programs, rather than the distfiles, then they should be built in such a way as to minimise the amount of "built-in policy". Building for /usr/pkg (which can be sym-linked to /usr/local) does seem to solve that problem, without having to invent a mechanism for tweaking compiled-in paths after the fact. The course of this conversation made me realize that the reasons I subscribed to FreeBSD in the first place no longer hold - except for financial contributions to the project, that is. The install disk and and live file system are nice to have, but not crucial. The real reason was having all those precompiled packages and/or distfiles around. But the distfiles vanished as of 4.0, and the ability to use the packages vanished when I set LOCALBASE to /usr/opt and rebuilt all my installed ports. (On the subject of third-party software the installs in /usr/local, the only binary thing that I run is StarOffice5.2, and it installed itself in /usr/local/office52, but I think that it's pretty agnostic about where it lives.) The office52 port is quit happy installing anywhere - I've got it at /usr/opt on my system. The WordPerfect and NetScape ports are also PREFIX clen. On the other hand, Applixware Office ships a precompiled package for /usr/local, and doesn't like being installed anywhere else. Which means I've got a couple of hundred megabytes being backup up for no good reason :-(. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/usr/local abuse
Warner Losh [EMAIL PROTECTED] types: In message [EMAIL PROTECTED] Nate Williams writes: : I know that as recent as 3=4 years ago, Purify installed itself by : default in /usr/local, on SunOS and Solaris. Lucid did this as well, : although things start getting pretty fuzzy going back that far. :) purify and the binary distributions of xemacs installed themselves into /usr/local on Solaris in the 1992-1996 time frame. As did *ALL* of the software binaries we downloaded from the net. Framemaker installed in /usr/local as well in the SunOS 3.5/4.0 time frame. Interleaf installed itself in /usr/local on SunOS 4.0/4.1 time frame. How much of that software did you get from the OS vendor? : My claims about "history" and "tradition" are attempts to refute : Brandon's assertion that packages going into /usr/local has "years of : tradition behind it." Mostly, it's about what *packages* are, not what : /usr/local was used for. : I disagree. I do too. Exactly what do you disagree with? That I'm arguing about what packages are? Or my assertion that packages installing in /usr/local doesn't have years of tradition behind it? The former is clearly true. And I've never tried to claim that people haven't been installing third party software in /usr/local for years (though some interpreted my comments about "locally maintained software" to exclude such). My claim is that the package system has grown into something other than "something to make installing third party software more convenient". It is pretty much a direct translation of some vendors practice of providing precompiled freeware into an OSS environment. The end user no longer has to worry about porting to or configuring for the OS - someone appointed by the OS vendor does that. The end user doesn't worry about updates to the software - the vendor provides them with udpates to the OS. The end user doesn't have to worry about what is and isn't part of the software - tools for doing all that come with the OS (well, with FreeBSD, anyway, if not with all the commercial OSs). Sure, with FreeBSD the end user sometimes has to *compile* the package. On the other hand, the end user sometimes has to compile the OS as well; that's part of dealing with an OSS system. Now, back to /usr/local and tradition - how many OS vendors provide software that installs in /usr/local. So far, no one has named one other than FreeBSD and OpenBSD, which copied FreeBSD. All the ones you named aren't OS vendors, they are third parties distributing their own software. Those are perfectly reasonable things to install in /usr/local; the OS vendor has nothing to do with them. That's not true for FreeBSD packages. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Brandon D. Valentine [EMAIL PROTECTED] types: There are other places where FreeBSD doesn't comply with the appropriate standard - packages vs. FHS, for instance. I claim that We don't seek to comply with the arbitrarily devised linux filesystem standard. We comply with hier(5), a standard steeped in decades of tradition. Corrections first: The only place where FreeBSD fails to follow FHS (in my quick perusal of it) is in putting packages in /usr/local instead of /opt. You can't blame that part of FHS on Linux - I have as yet to see a Linux distro or package do it that way. No, this bit comes from commercial vendors, where it's also steeped in years of tradition. Rant second: FreeBSD *violates* years of traditions with it's treatment of /usr/local. /usr/local is for *local* things, not add-on software packages! Coopting /usr/local for non-local software creates needless complexity and confusion, which of course leads to needless pain. All of which has nothing to do with the question of whether we want to continue giving error messages that are wrong, or commit this patch and provide ones that are actually informative. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/usr/local misuse (Was: Confusing error messages from shell image activation)
Will Andrews [EMAIL PROTECTED] types:
On Sat, Dec 09, 2000 at 08:21:28PM +0100, [EMAIL PROTECTED] wrote:
Agreed. It would be nice if FreeBSD could use the same system as NetBSD,
storing the packages/ports under /usr/pkg.
That's why PREFIX exists.
I know. Unfortunately, support for PREFIX seems to draw more lip
service than actual service. I've urged a number of times that
portlint should test for this, or that the porters handbook should
include instructions for checking this (it's actually pretty easy),
all to no avail. Last time I checked, Perl modules installed by the
standard perl module installer always go to /usr/local. Other may go
to ${PREFIX}, but the Perl interpreter doesn't know to search there
for modules, so the port generally winds up broken anyway.
On the upside, I regularly pr (with patches as often as possible)
ports that aren't PREFIX-clean, and they do get fixed.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Unix/FreeBSD consultant,email for more information.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local misuse (Was: Confusing error messages from shell image activation)
David O'Brien [EMAIL PROTECTED] types:
On Sat, Dec 09, 2000 at 01:59:51PM -0600, Mike Meyer wrote:
I know. Unfortunately, support for PREFIX seems to draw more lip
service than actual service.
I disagree. If one of the ports I maintain isn't PREFIX-clean, let me
know and it _will_ be fixed. If you know others, please open a PR, let
me know and I'll assign it to the maintainer.
Like I said, I do report them when I find them. However, things like
ports with perl modules being either PREFIX dirty or broken tend to be
pretty damning. But my comment is based on the experience of running a
system with LOCALBASE set to something other than /usr/local. If you
run systems that way and have a different experience, I'd be
interested in hearing about it.
or that the porters handbook should include instructions for checking
this (it's actually pretty easy),
I always thought ``make PREFIX=/tmp/foo package'' is pretty obvious.. but
maybe not...
It's not obvious to me. It's also not mentioned in the handbook
anywhere. I suspect that most people are like me, and seldomp build
packages - which would explain why it's not obvious. What does the
above command do if the port isn't PREFIX clean?
My personal test is "make PREFIX=/tmp/foo install make
deinstall". If something in the plist is installed outside of
/tmp/foo, the deinstall will complain when it can't find it.
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ffs_valloc: dup alloc panics with stable/current
On Fri, Dec 08, 2000 at 03:44:28AM +0200, Tomi Vainio - Sun Finland - wrote: sense = 3 asc = 11 asq = 0 This is not so bad but 5-30 minutes after this command system will always panic. Are you surprised? The system is complaining that it's having intermittent difficulty accessing the disk, so it shouldn't be at all surprising that you'd have disk corruption problems as a result. Actually, it's upstream from the RAID controller. There don't appear to be any actual complaints from the controller about read errors, so I'm a little skeptical that this is actually the "real" problem. Start by checking your SCSI cabling and termination. Almost all SCSI problems boil down to that eventually. The entire system; disks, controller, etc. is all pretty skanky by the sound of it. It wouldn't surprise me too much if the system is suffering eg. multiple-master data corruption, or straight out memory/cache errors. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ffs_valloc: dup alloc panics with stable/current
We got old Mylex DAC960PD-Ultra-raid-adapter and have tried to use it with FreeBSD 4.2-stable and 5.0-current. Adapter is configured with three luns 5+5*9G, 8+8*9G (raid5) and 1+1*2G (mirrored boot disk). All 9G disks are quite old Seagate Barracuda 9 disks ST19171W. System is working quite well but under heavier load we start to get scsi errors from luns. sense = 4 asc = 3 asq = 0 sense = 1 asc = 3 asq = 0 sense = 3 asc = 12 asq = 0 sense = 3 asc = 11 asq = 0 Your disks just aren't up to this sort of workload. This is not so bad but 5-30 minutes after this command system will always panic. cd /uu ; dump 0buf 126 - /w | restore xbf 126 - mode = 0100644, inum = 720391, fs = /uu panic: ffs_valloc: dup alloc This looks like memory or PCI data corruption. You don't say how you're generating this load, or what the motherboard is, but I suspect that you may have hardware issues here. One question - I assume you're not seeing any read error diagnostics from the Mylex driver (other than the disk errors?) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __asm help..
I'm trying to write some experimental mutex operations similar to those in -current, but to do differnt things (e.g. a read/write lock) however, I am having some problems with the __asm stuff. Julian; Wheels were invented around 1500BC. We don't need to go through all that again. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/dev/acpica acpi.c acpi_button.c acpi_ec.c acpi_isa.c acpi_lid.c acpi_pcib.c acpi_processor.c acpi_resource.c acpi_thermal.c acpi_timer.c acpiio.h acpivar.h
Modified files: sys/dev/acpica acpi.c acpi_button.c acpi_ec.c acpi_isa.c acpi_lid.c acpi_pcib.c acpi_processor.c acpi_resource.c acpi_thermal.c acpi_timer.c acpiio.h acpivar.h Log: - Convert a lot of homebrew debugging output to use the ACPI CA debugging infrastructure. It's not perfect, but it's a lot better than what we've been using so far. The following rules apply to this: o BSD component names should be capitalised o Layer names should be taken from the non-CA set for now. We may elect to add some new BSD-specific layers later. I don't think this "infrastructure" is useful. As far as I experienced, the message is too noisy or too few infomation. I've been very slowly coming around to like it. It's important to pick your debugging options carefully, and to be prepared to wade through thousands of lines of output (a serial console is mandatory). However, I've been careful to keep the BSD parts separate from the ACPI CA parts, so you can just turn on the BSD-related debugging without getting the eleven bazillion mutex operations, etc logged. I also added the ! support *specifically* so that I can turn lots of stuff on, and then turn the really noisy and useless stuff off again. But most importantly, I didn't have anything better up my sleeve. If you've got a better integrated debugging infrastructure, I'm all ears. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: growfs(8) for FreeBSD
So you can use it either with hardware RAID controllers which allow for non destructive extending of the size of existing volumes at the end(!). Cool. We support the FlexRAID Virtual Sizing stuff on the AMI controllers already, and I bet that the Mylex MORE stuff would work too. * handle byteorder correct on non intel platform (we don't have any alpha hardware but think ufs on alpha is not ufs on intel) Actually, I believe they're the same; as long as you have used explicitly-sized types everywhere, you should be fine. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ffs_valloc: dup alloc panics with stable/current
This is not so bad but 5-30 minutes after this command system will always panic. cd /uu ; dump 0buf 126 - /w | restore xbf 126 - mode = 0100644, inum = 720391, fs = /uu panic: ffs_valloc: dup alloc This looks like memory or PCI data corruption. You don't say how you're generating this load, or what the motherboard is, but I suspect that you may have hardware issues here. /w fs contains cvsupped FreeBSD source, objs and ports alltogether 1G of data. Load test is this simple "cd /uu ; dump 0buf 126 - /w | restore xbf 126 -" between two partitions. Ok, so there's no major traffic anywhere else. That's irritating. First motherboard we tried was Intel PPro 200Mhz (FX440 based I think/Natoma?). Second one is newer 633MHz Celeron system but I don't know manufacturer. But the same symptoms? Have you tried replacing the controller (or even just the onboard RAM)? I don't currently have one of these old controllers that I can use in a PC; the only one I do have is working fine under heavy load in an Alpha. One question - I assume you're not seeing any read error diagnostics from the Mylex driver (other than the disk errors?) Sometimes we have got more those scsi errors before fs panic. But no other errors? In particular, nothing that looks like a "real" I/O error? The problem that you're seeing looks like filesystem metadata corruption. If it's not memory/system related, it has to be in the datapath from the disks through the driver. I'm not aware of any bugs in the driver that could cause this. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __asm help..
Since all I WANT to do is pushf disable intr fiddle popf (chache hit) I am annoyed by the fact that I have all those extra bus cycles going on. I can live with it for development but it still annoys me. You haven't yet explained how you plan to disable interrupts on the other CPUs... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: write(2) returns error saying read only filesystem when trying to write to a partition
CC: to -current as that's what I'm running. "John W. De Boskey" wrote: Hi, I can't answer your questions directly, but you might want to checkout the sources to newfs (/usr/src/sbin/newfs/newfs.c or http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sbin/newfs/newfs.c?annotate=1.31 line 417). I'll be glad to review your program if you would like. I'm not after a review, I'd like FreeBSD-CURRENT fixed. The program works on Compaq True64 UNIX v 4.0d It also works on Solaris 7 (only tested sparc). So it seems FreeBSD is broken here. FreeBSD just behaves differently. If you want to write to the whole disk, open the whole-disk device, not the 'c' partition. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: write(2) returns error saying read only filesystem when trying to write to a partition
Mike Smith wrote: The program works on Compaq True64 UNIX v 4.0d It also works on Solaris 7 (only tested sparc). So it seems FreeBSD is broken here. FreeBSD just behaves differently. If you want to write to the whole disk, open the whole-disk device, not the 'c' partition. Thanks Mike, /dev/da18 works fine for me although I notice that /dev/da18s1 does not. There seems to be some inconcistencies in this area. That would be something of an understatement... Please tell me (and for the benefit of the list) as to why I cant use /dev/da18s1c ? The 'c' device won't let you overwrite the beginning of the slice/disk, since that's where the partition information is kept. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNA?
Do we support any of the PNA 2.0 cards (10 Mb net over telephone line)? E.G. 3com 3c410, or D-Link DHN-520? No; as far as I'm aware they're all using the Broadcom MAC, and Broadcom refuse to give us documentation. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB related commit leads to hung systems if USB-IRQ=Disabled in BIOS
In my bios I have PnPOS=NO, USB-IRQ=Disabled. The commit below results in a PCI interrupt storm and a terminally wedged system right after interrupts are enabled. This would be a bug in the UHCI or OHCI driver then. You can avoid it by not running the driver. Poul-Henning | nsayer 2000/12/03 09:07:24 PST | | Modified files: | sys/pci ohci_pci.c uhci_pci.c | Log: | We now have the ability to assign the correct IRQ when PNP-OS is turned | on. So stop failing the attach if the IRQ is unassigned. With this | patch, I can now boot with PNP-OS YES in my BIOS no differently than | PNP-OS NO (which is a good thing since Windows hangs with PNP-OS NO). | | Obtained from:msmith | | Revision ChangesPath | 1.21 +1 -11 src/sys/pci/ohci_pci.c | 1.32 +1 -11 src/sys/pci/uhci_pci.c -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB related commit leads to hung systems if USB-IRQ=Disabled in BIOS
In my bios I have PnPOS=NO, USB-IRQ=Disabled. The commit below results in a PCI interrupt storm and a terminally wedged system right after interrupts are enabled. This would be a bug in the UHCI or OHCI driver then. You can avoid it by not running the driver. I should have mentioned; you can probably also avoid it by letting your BIOS give the USB controller an IRQ, since it'll almost certainly also perform whatever initialisation the driver is currently missing out on. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB related commit leads to hung systems if USB-IRQ=Disabled in BIOS
I should have mentioned; you can probably also avoid it by letting your BIOS give the USB controller an IRQ, since it'll almost certainly also perform whatever initialisation the driver is currently missing out on. Right, that is what I did once I realized that this particular commit was the culprit. The commit isn't (really) the culprit; it's just exposed a bug in the USB chipset driver in question. (I'm mostly just making this point so that other people don't go blaming 'correct' PCI behaviour for their problems 8). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNA?
Mike Smith wrote: Do we support any of the PNA 2.0 cards (10 Mb net over telephone line)? E.G. 3com 3c410, or D-Link DHN-520? No; as far as I'm aware they're all using the Broadcom MAC, and Broadcom refuse to give us documentation. I don't know whether their chips support version 2.0 of the standard (how important is this?) but Davicom Semiconductor is listed at http://www.freebsd.org/commercial/hardware.html . 10 seconds with their site confirms that they only support the 1Mbps standard. 2.0 is the standard revision which covers 10Mbps operation. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB modem?
Mark Huizer [EMAIL PROTECTED] types: I have a USB modem here, (Siemens), that I would like to get to work under FreeBSD, but I can't even find the right tools to get vendor and product ID's to add to usbdevs :-( Try looking in dmesg - USB device that don't have known product and vendor ID's have theirs printed. Failing that, check the usbdevs(8) man page. The serious catch about USB modems is that they have to support the USB CDC spec. Not all of them do. If it does, the serial device will be umodem0 (1, 2, 3, ...), and you use it just like a tty line tied to an external modem. Is it a case of being in the usbdevs list _and_ supporting those specs? Or just following the specs? I believe that being listed in usbdevs isn't a requirement, but I'm not positive. I also haven't had any look getting the thing to work dynamically loading the various modules involved. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Unix/FreeBSD consultant,email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PnP OS = ?
I have the modem in the office, not at home. And of course there is that tricky part where Windows wants my BIOS set to PNP OS=YES and FreeBSD wants it set to NO. but well :-) we can survive that for the moment. Can you expand on what actually goes wrong if you boot -current with it set to YES? This is part of what I'm working on right now... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
David O'Brien [EMAIL PROTECTED] types: On Wed, Nov 29, 2000 at 07:41:14PM -0600, Mike Meyer wrote: Hmm - what's the stupidity? I have a test machine running both -current and -stable Do you have the two FreeBSD installations on the same disk? If so, I'd love to hear how you did it. I spoke with others and they also had problems when trying it sysinstall. I finally did 1 normal install and then booted that and created the 2nd slice, lable, BSD partitions, etc.. by hand and then untared the 2nd installation bits. Yup, they're both on the same disk. At this point, I've done that two ways. First was with a system already running -current. I just used a 4.1-RELEASE CD and did a standard install from that - carefully ignoring the slice -current was on, except to mount it's swap instead of allocating one on the -RELEASE slice. Upgrading that to -stable went without a hitch. Later, I had a system running -stable, and wanted to create a -current slice on the same system. Like you, I used the running -stable to create, partition and label a second slice. I then nfs-mounted /usr/src and /usr/obj from a -current system onto the -stable system, and did a "make installworld DESTDIR=/new" from that /usr/src. Then a "make distribution" in /usr/src/etc with the appropriate DESTDIR to get those files installed. Finally tweak the new -current's config files from the running -stable system. I think I had more problems because of differences between the /etc/make.conf files on the -current NFS server and the -stable system than anything else. Again, I set things up with one swap partition shared between the two OSs. I've seen the claim that FreeBSD can swap to a Linux swap partition, but never tested it. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB modem?
Mark Huizer [EMAIL PROTECTED] types: Does anyone here have experience on tryuing to add USB devices? I do. I have a USB modem here, (Siemens), that I would like to get to work under FreeBSD, but I can't even find the right tools to get vendor and product ID's to add to usbdevs :-( Try looking in dmesg - USB device that don't have known product and vendor ID's have theirs printed. Failing that, check the usbdevs(8) man page. The serious catch about USB modems is that they have to support the USB CDC spec. Not all of them do. If it does, the serial device will be umodem0 (1, 2, 3, ...), and you use it just like a tty line tied to an external modem. mike -- Mike Meyer http://www.mired.org/home/mwm/ Independent WWW/Unix/FreeBSD consultant,email for rates. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
Warner Losh [EMAIL PROTECTED] types:
In message [EMAIL PROTECTED] "David O'Brien" writes:
: Except for stupidity in libdisk(I believe) and thus sysinstall, there is
: no, none, zero reason why one cannot have two installations of FreeBSD in
: two different slices on the same disk.
I've done make buildworld/installworld of both -current and -stable
onto one disk in the 3.x/4.0-current time frame. It took a lot of
tweaking, but I was able to boot off either one. I think that
booteasy didn't boot the second partition properly and I had to play
loader games. Sadly, the disk that had this on it one day started
thumping, turning it into a rather large paperweight...
FWIW, my system running both -current and -stable off of one disk uses
grub for booting, not booteasy.
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: your mail
David O'Brien [EMAIL PROTECTED] types: On Wed, Nov 29, 2000 at 08:06:14AM +0100, News User wrote: I'm building news machines with two partitions for OSen, to allow me to boot into my choice, where my choice has been FreeBSD-STABLE or FreeBSD-CURRENT to see how the two compare, and if there are any significant improvements in -CURRENT. I know, ``don't do that'' but hey... Except for stupidity in libdisk(I believe) and thus sysinstall, there is no, none, zero reason why one cannot have two installations of FreeBSD in two different slices on the same disk. Hmm - what's the stupidity? I have a test machine running both -current and -stable (and NetBSD-current, Solaris, Linux, and last and least Win98), and haven't encountered any problems with it. mike -- Mike Meyer http://www.mired.org/home/mwm/ Independent WWW/Unix/FreeBSD consultant,email for rates. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for current on LCA based alphas
On Tue, 28 Nov 2000, Wilko Bulte wrote: On Mon, Nov 27, 2000 at 02:42:52PM -0600, Mike Eldridge wrote: On Sat, 25 Nov 2000, Bernd Walter wrote: LCA systems doesn't like probing after PCI slot 19. Probing slot 20 panics the system. The following patch made it into single user mode on my AXPpci33. I asume it will also work on multias. I can't tell more as the tested system is a 4.1-RELEASE and I need to update the world before further testing. Hmm, what exactly happens when slot 20 is probed? I remember my problems with my Multia were related to PCI interrupts. It would spit out "dec_axppci_33_intr_map: bad interrupt pin 192" about 50 or so times and then panic. Wasn't this somehow related to the version of the SRM console code? Well, 4.0 didn't panic. That brings me to another point, for some reason, when I attempted to upgrade the SRM, it appeared as if it wrote the firmmware successfully, there were no errors, it went through the process, *but* when I checked the version of SRM, it was still the same. I really haven't messed with it at all lately because I'm waiting for a proper serial cable so that I can plug the Multia's serial port up to one of my linux boxen. D25M to D9M, quite possibly the most difficult cable to assemble. I had 2 dozen various 9-25 pin adapters, and I couldn't combine any of them with a D9M-D9F cable in any way to come out with a D25M-D9M cable. I've only seen this particular problem with 4.1.1 (I don't think I've tried 4.1 yet, although I can't remember for sure). Mike - Save the whales. Feed the hungry. Free the mallocs. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for current on LCA based alphas
On Sat, 25 Nov 2000, Bernd Walter wrote: LCA systems doesn't like probing after PCI slot 19. Probing slot 20 panics the system. The following patch made it into single user mode on my AXPpci33. I asume it will also work on multias. I can't tell more as the tested system is a 4.1-RELEASE and I need to update the world before further testing. Hmm, what exactly happens when slot 20 is probed? I remember my problems with my Multia were related to PCI interrupts. It would spit out "dec_axppci_33_intr_map: bad interrupt pin 192" about 50 or so times and then panic. Mike - Save the whales. Feed the hungry. Free the mallocs. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: page coloring
Isn't the page coloring algoritm in _vm_page_list_find totally bogus? No, it's not. The comment is, however, misplaced. It describes the behavior of an inline function in vm_page.h, and not the function it precedes. Hrm. My comment was based on John Dyson's own observations on its behaviour, and other discussions which concluded that the code wasn't flexible enough (hardcoded assumptions on cache organisation, size etc.) If this isn't applicable, my apologies for confusing the matter. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Alfred Perlstein [EMAIL PROTECTED] types:
* Mike Meyer [EMAIL PROTECTED] [001122 22:41] wrote:
Could I get some feedback on URL:
http://www.freebsd.org/cgi/query-pr.cgi?pr=22755 ? It's just a
one-line kernel patch with some attendant updates in the kernel and
libc, but it makes dealing with broken #! scripts *much* saner, and no
one has even seen fit to comment on it yet :-(.
Thank you for taking time to look at it.
This patch may break compliance, ENOEXEC is the proper error code,
Um - compliance with what, exactly? I know it breaks compliance with
Unix standards for user friendliness, but that was the point. I also
agree that ENOEXEC is the best currently existing error code - but for
this it pretty much sucks. Exec returns other codes providing more
informative error messages; adding one more shouldn't be a problem.
the shell should try to be a bit smarter about explaining why
ENOEXEC was returned.
Um - not "the" shell; all of them. Given that the authors of some of
them are worried about portability, doing so portably is probably
important as well. That's why I decided it belonged in the
kernel. Doing this means that all shells get the benefit of it without
a source change, and the only change other than better error messages
was if there is an executable with the same name behind a broken
script in the path - and I *couldn't* convince myself that was a
problem!
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Confusing error messages from shell image activation
Could I get some feedback on URL: http://www.freebsd.org/cgi/query-pr.cgi?pr=22755 ? It's just a one-line kernel patch with some attendant updates in the kernel and libc, but it makes dealing with broken #! scripts *much* saner, and no one has even seen fit to comment on it yet :-(. Thanx, mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
That's what I mean. You call this, and it will remap the CIS (if it has been unmapped), walk it for you and pass you a pointer to each CIS entry one at a time to the function you specify. Warner I'd rather have a seek/read interface than have a callback. Let's be realistic; the right way to do this is going to be to use the ivar interface; cardbus_get_cistuple(dev, index) just like all the other PCI bus accessor functions. PCI will just need to pass the request through to its parent, assuming its parent is a cardbus bridge, or veto it otherwise. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
IIRC, and I haven't looked it up, the CIS entries that would be problematical have two next pointers. One is for the next function, while the other is for the first entry specific to this function. The driver code could look at the CIS entry to tell what to do, and if it was the wrong function, call cis_skip_this_function(dev, cookie, cis); which would skip this function and position the read pointer hidden in the cookie to point to the first entry in the next function's cis (or more accurately, the first entry in the series of entries that are specific to that function). No; the CIS parser should know which function it's being called on behalf of, and simply elide the tuples that don't relate to that function. It is complications like this that lead me to want to not allow CIS reading at all, but rather provide the commonly parsed information easily to the driver. I don't want drivers groveling through all this stuff to find an ethernet address when the bus is able to parse the CIS and return this on request. Having said that, and based on my experience with some really whacko hardware in the 16-bit world, I think that I can't justify this stand because it makes writing a device driver for whacked out hardware impossible w/o gross hacks (cf older revs of if_xe.c). Export the commonly-known stuff through the "right" interface (eg. cardbus_get_cistuple(dev, CARDBUS_CIS_STATION_ADDRESS)) and then provide a backdoor (cardbus_get_cistuple(dev, CARSBUS_CIS_RAW + index)) for the evil side, perhaps. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
: Let's be realistic; the right way to do this is going to be to use the : ivar interface; cardbus_get_cistuple(dev, index) just like all the other : PCI bus accessor functions. PCI will just need to pass the request : through to its parent, assuming its parent is a cardbus bridge, or veto : it otherwise. Why does this have to go even to the bridge? Because it's the bridge driver that has to parse the CIS; it needs it to eg. set power and so forth. And because the bus code should be generic. The cardbus bus code already deals with the CIS and it should be the one to arrange things to happen. We can tweak the current cardbus CIS reading stuff to do this and maybe combine it somewhat with the pccard CIS reading stuff. Also, the index doesn't make so much sense because each CIS entry is a variable length, so we'd have to walk the chain. Index is the tuple index, not the byte offset in the CIS; sorry I didn't make that clear. Also, this isn't a PCI thing, so no PCI code should be called. :-) Interrupts aren't a PCI thing either, but we pass attempts by PCI drivers to do stuff with them up through the stack. This really isn't any different. For mapping some parts of the CIS, I think that you need to do that at the cardbus bridge, which means that you can only do that for the cardbus children that are attached. Going up through multiple bridges isn't going to work. This is especially true for the 16-bit CIS entries. Yeah; I don't think I was proposing anything like this. Eg, if you have something like the following: pci --- pccbb0 --- cardbus0 --- pcib --- pci -- pccbb0 -- cardbus1 -- dc then when the dc driver wants to map the CIS, the cardbus bus will ask the pccbb to map it, which will go up the usual food chain for mapping, but after it leaves the pccbb it is just a normal map request. The second cardbus bridge (pccbb0) doesn't get into the act of mapping the CIS. Once mapped, cardbus1 will be returning the CIS to dc and also handling the jump discontinuties that can happen in the CIS. This is why I want to have cardbus be its own bus that happens to implement all the pci bus things properly. It is, in C++ terms, a subclass: it is a pci bus plus a few other things. I don't think we should try to shoehorn it all into the PCI bus code. Something tells me that it will result in chaos. I think that you're overrating the things that need to be "shoehorned" into PCI to make it a comfortable superset of stock PCI + hot-plug PCI + CardBus. So far all we have is passing through a CIS tuple accessor function. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] Mike Smith writes: : No; the CIS parser should know which function it's being called on behalf : of, and simply elide the tuples that don't relate to that function. This isn't always the right thing to do. At least in the 16-bit world, there are drivers that want to look at the CIS entries for the other function of the card for various reasons (some of them need to know what kind of modem is present, iirc, to initalize some things in a non-standard way, the example was the NetBSD driver mhz, iirc). I don't wish to preclude that. The ROM BAR is only implemented for function 0 and the ROM contains information for all functions of the chip. So, functions greater than 0 must have the flexibility to activate at least the ROM BAR on function 0 as well as access that region. Does the driver need the ROM, or the CIS which may be inside the ROM? If the driver needs structured information from inside the ROM, this falls into the same category as the CIS. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
function its own CIS chain. These CIS chains can live in configuration space, in memory space or the expansion ROM (which I assume is the same thing as the ROM BAR on function 0, but maybe I'm mistaken) and the bridge is responsible for properlly mapping the last two. The config space presents the biggest problem because we don't have any way to access it with the bus_space(9) functions, so special code is needed in the cardbus bus driver to know where to read from. The code reading the CIS should be using callbacks into the hardware-specific code, which will know how to read/write PCI configuration space. Having said that, there's a good argument to be made for adding PCI configuration space as a new bus_space type. Any thoughts on why this might be a bad idea? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
: You can also short IOCHK to ground to get an NMI which kicks you into : the debugger, even in an interrupt context. : : Bad news for you warner: On a too large sample of my newer : motherboards this doesn't work anymore :-( There's also a pci signal that you can either pull up or pull down that's supposed to give you the same results. I've never really needed to know it. SERR behaviour is programmable and there is no standard for it. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PXE build?
Does anyone know of any current issues with PXE? Some ROMs out there are pretty bad. I've searched the mailing lists and I don't see any mention of a problem similar to mine. I'm running FreeBSD-CURRENT from 2000 09 15 on a server. The client has an Intel 21143 based ethernet card that claims it has PXE 2.0 (Build 74) support. Are you *sure* the card is 21143-based? At any rate, the Intel PXE codebase is buggy for the 8255x chips up to build 082, so you're probably running bad code there. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad commit?
As near as I can tell on my laptop, the following change causes panics with kernel page faults. With it, my laptop panics every time on boot (although in slightly different places for my two different kernels) and without it I'm rock solid. Has anybody else seen this? Yes; I think it's broken the resource manager. Warner mckusick2000/11/14 12:46:02 PST Modified files: sys/sys rman.h sys/kern subr_bus.c subr_rman.c Log: In preparation for deprecating CIRCLEQ macros in favor of TAILQ macros which provide the same functionality and are a bit more efficient, convert use of CIRCLEQ's in resource manager to TAILQ's. Approved by:Garrett Wollman [EMAIL PROTECTED] Revision ChangesPath 1.13 +3 -3 src/sys/sys/rman.h 1.83 +3 -5 src/sys/kern/subr_bus.c 1.14 +30 -35src/sys/kern/subr_rman.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Typo in secure/lib/libcrypto/Makefile
=== RCS file: /home/ncvs/src/secure/lib/libcrypto/Makefile,v retrieving revision 1.26 retrieving revision 1.27 diff -u -p -r1.26 -r1.27 --- src/secure/lib/libcrypto/Makefile 2000/11/13 02:21:37 1.26 +++ src/secure/lib/libcrypto/Makefile 2000/11/14 22:12:02 1.27 @@ -1,4 +1,4 @@ -# $FreeBSD: src/secure/lib/libcrypto/Makefile,v 1.26 2000/11/13 +.# $FreeBSD: src/secure/lib/libcrypto/Makefile,v 1.27 2000/11/14 22:12 ^ A period before the comment somehow crept into the commit. -- Mike Heffner [EMAIL PROTECTED] Blacksburg, VA ICQ# 882073 http://my.ispchannel.com/~mheffner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ISA PnP resource allocation
Now that someone has implementented resource alignment in the resource
allocator, someone could review and integrate the attached patch.
This looks fine to me. I assume you'd want the same changes applied to
aligning memory regions?
Background:
I do have an old system with several PnP devices. Two of the request the
following IO ports:
first device: port range 0x100-0x3ff size=1 align=1
second device: port range 0x100-0x3f0 size=8 align=8
The first device gets port 0x100-0x100 allocated. Then the code
in isa_common.c tries to allocate the ports for the second device.
0x100 is already used, so it gets the next free range: 0x101-0x108,
ignoring the alignment constraints.
The general problem in the code /sys/isa_common.c
isa_find_port(), isa_find_memory(), etc.
The loops in these routines try to honor the alignment constraints but
the real work is done in /sys/subr_rman.c. Regardless of resource usage
the for(...)-look in above functions is only run once.
I already filed a PR for this problem but my first solution was a real
hack (kern/21461).
[another solution would be to introduce another flag for
rman_reserve_resource() not to search for alternate regions.
Daniel
Index: isa/isa_common.c
===
RCS file: /data/cvs/src/sys/isa/isa_common.c,v
retrieving revision 1.18
diff -u -r1.18 isa_common.c
--- isa/isa_common.c 2000/07/12 00:42:08 1.18
+++ isa/isa_common.c 2000/11/09 20:11:31
@@ -207,10 +207,10 @@
start, size);
res[i] = bus_alloc_resource(child,
SYS_RES_IOPORT, i,
- 0, ~0, 1, 0 /* !RF_ACTIVE */);
+ 0, ~0, 1,
rman_make_alignment_flags(align)/* !RF_ACTIVE */);
if (res[i]) {
- result-ic_port[i].ir_start = start;
- result-ic_port[i].ir_end = start + size - 1;
+ result-ic_port[i].ir_start = res[i]-r_start;
+ result-ic_port[i].ir_end = res[i]-r_start + size - 1;
result-ic_port[i].ir_size = size;
result-ic_port[i].ir_align = align;
break;
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: savecore broken because kern.bootfile is set wrong
Something actually was changed at some point perhaps?
On i386, kernelname is dug out of bootinfo and copied
(in assembler).
On alpha:
p = getenv("kernelname");
if (p)
strncpy(kernelname, p, sizeof(kernelname) - 1);
Did the loader used to set kernelname as an environment variable?
It should still do it. (The forth code handles this) My only Alpha is
running -stable, and $kernelname is set correctly there (see the output
of 'kenv').
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Interrupt allocation
Timesharing requires co-operation from both device and bus, but this is a completely different issue. No drivers currently support timesharing. `sio' at a minimum probably should, as it was the motivating example for adding that feature. (My laptop has three PnP sio ports: an internal modem, an external DB-9, and a dual-ported infrared transceiver. There are only two interrupts available among them.) They are probably x-bus parts and would support shared interrupts. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
At one (gross) time in history, Alphas included an x86 emulator in ROM to facilitate this (and other BIOS POST initialization stuff, mostly). They still do. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unwanteed halt powerdown under -current (linuxerator?)
Hi, executing /compat/linux/bin/rpm issues a halt and powerdown under -current an my TECRA8000. Is it just me? No. You don't have the Linux module loaded. There's a Linux system call which (alarmingly) maps to shutdown-and-poweroff if run as a FreeBSD binary. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unwanteed halt powerdown under -current (linuxerator?)
Hi, Hi, executing /compat/linux/bin/rpm issues a halt and powerdown under -current an my TECRA8000. Is it just me? No. You don't have the Linux module loaded. There's a Linux system call which (alarmingly) maps to shutdown-and-poweroff if run as a FreeBSD binary. Not really. See my previous mail. It seems that a SYSV4 Syscall maps to the evil call. Unless you had the SVR4 module loaded, it would still have been run as a FreeBSD binary, which would give you exactly the same behaviour. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/dev/random thoughts
Like everyone else, I've been bit by /dev/random blocking because it
didn't have enough entropy. I recently got bit after booting the
system single-user to do some work, meaning nothing in the discussion
about when/where/how to deal with the entropy information addressed
this one.
It seems like we're being a bit paranoid about things - arguments
about that not being possible notwithstanding. I mean - if I mount a
few dozen file systems using inode numbers drawn from a PRNG instead
of being cryptographic quality, then *quit using the PRNG*, how much
extra exposure do I have?
It's clear to me it would be less painful if we had two bike sheds -
uh, behaviors for /dev/random. One would be active at system boot
time, and hence while the system was running single user. It wouldn't
require lots of entropy, and also wouldn't be of cryptographic quality
(though that would be nice)u. The other would be the quality system
being built, but would be enabled by some userland action. Once
enabled it can't be turned off. The obvious userland action is writing
to /dev/random to give it entropy.
However, someone who actually understands the issues should go through
the rc sequence and figure out when we need cryptographic quality
randomness (or we could add a "CRYPTORANDOM" to the NetBSD-like RC,
and things that require that can be flagged as such). This is the step
needed to decide if doing this kind of split has any advantage at all.
The one problem I see is preventing someone from shotting themselves
in the foot by, for instance, creating ssh host keys using the
low-quality /dev/random. There are certainly others.
Just some thoughts, possibly useful, probably not - but I thought
worth sharing.
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Need help to boot (was : -current hangs during boot)
I had my first CVSup-ed source tre d/loaded today. It compiled correctly (make buildworld) and installed correctly (make installworld). But on rebooting the box, the loader fails to find a bootable kernel. It seems my loader.conf got trashed somewhere ... I get the list of the / partition, but the command load kernel gives me the "not found" message. You should have build and installed a new kernel at the same time. Try 'boot /kernel'. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: platform byte order macros?
On Fri, Oct 27, 2000 at 09:49:57PM +1100, Bruce Evans wrote: [...] NetBSD supports the ntohl family on constants, but only on some arches (at least in last year's version). It takes fancier macros to support constants. This gives an excuse to change the inline functions back to macros :-). Cool! My upcoming byte-swapping changes to IPv4 code would benefit from having these macros. Could you please review the attached patch (it was obtained from NetBSD)? ... +#ifdef __OPTIMIZE__ Using macros does not "optimise" anything, and this is a very poor choice of defines. __MACRO_ENDIAN_CONVERSIONS might be better. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: platform byte order macros?
On Fri, Oct 27, 2000 at 07:34:06AM -0700, Mike Smith wrote:
On Fri, Oct 27, 2000 at 09:49:57PM +1100, Bruce Evans wrote:
[...]
NetBSD supports the ntohl family on constants, but only on some arches
(at least in last year's version). It takes fancier macros to support
constants. This gives an excuse to change the inline functions back to
macros :-).
Cool! My upcoming byte-swapping changes to IPv4 code would benefit from
having these macros. Could you please review the attached patch (it was
obtained from NetBSD)?
...
+#ifdef __OPTIMIZE__
Using macros does not "optimise" anything, and this is a very poor choice
of defines. __MACRO_ENDIAN_CONVERSIONS might be better.
Huh, you would not call this optimization?!
No, since it is incapable of dealing with a non-constant argument.
#include sys/types.h
#include stdio.h
void
foo(void)
{
printf("%hx\n", htons(0x80));
}
--- a.s.without Fri Oct 27 18:11:26 2000
+++ a.s.with Fri Oct 27 18:11:59 2000
@@ -13,12 +13,7 @@
movl %esp,%ebp
subl $8,%esp
addl $-8,%esp
- movl $128,%eax
-#APP
- xchgb %ah, %al
-#NO_APP
- andl $65535,%eax
- pushl %eax
+ pushl $32768
pushl $.LC0
call printf
leave
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
Gerhard Sittig writes: On Wed, Oct 25, 2000 at 06:04 +0700, Alexey Dokuchaev wrote: Though I see your point, actually, many UNIX books, including some pretty old ones, refer to sending HUP signal as standard way of restarting/resetting daemons. Please tell the software authors about it, too. :) Although there might be some form of convention, not everyone might follow it (some might not be able even if they tried without breaking established behaviour). Wrapping those services will make starting, stopping, reloading, querying status and whatever you usually do to them easy and consistent for the user again. Actually, the HUP convention has been around since at least v6. As noted, it's still not universal. The pid file convention is more recent, and less followed. Fixing that in a startup script is easy (and what I recommend for string daemons that use the HUP convention, so that it can be used for the script's stop command :-). Now, which process do I need to create a pidfile for to get my ipfw config reloaded? mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
Gerhard Sittig writes:
What's new is:
- include the general config at the start (and yes, in every
single script -- but this should be neglectable in terms of
speed penalty and makes them work separately, too -- which is a
real big gain!)
This isn't really new; it's been nagging me for a while. Also,
periodic.conf does this now. I'm not convined it's negligible when
added up over dozens of scripts. I'm planning on taking some
measurements to see how much this really costs. I believe I have a
solution if it turns out to be non-negligible.
- maybe include (source) some common code like
- determining pids belonging to program names
- starting processes in an supervised or backgrounded or any
other special way
- have some printouts, error level summary, etc
but I don't see FreeBSD having this level of "rc lib" as NetBSD
has in rc.subr or even RedHat has in /etc/rc.d/functions(sp?).
So only the sourced rc.conf (default and customized) remains.
Said solutions works shell functions as well.
The real new part eating most of the time to implement is the
shutdown path (which I understand to be somewhat absent in
FreeBSD right now, "kill -TERM everything" seems to do the job
right now).
Well, rc.shutdown has the appropriate loop processing in it for doing
this for the rc.d directories already. So the new part is the
per-system shutdown. That's where the shell subroutine library comes
in handy. Provide functions start/stop/reconfig that do the right
thing for the conventional single daemon subsystem like so (vertically
compressed to save space):
start() {
eval command="\$${name}_program \$${name}_flags"
command
echo $! /var/run/${name}.pid
echo -n " $name"
}
stop() {
kill -TERM /var/run/${name}.pid
echo -n " $name"
}
config() {
kill -HUP /var/run/${name}.pid
}
run()
eval check="\$${name}_enable"
case "${check}" in
[Yy][Ee][Ss]) run="yes" ;;
[Nn][Oo]) run="no" ;;
esac
case "$1" in
start) if [ "$run" = "yes" ]; then start(); fi ;;
stop) if [ "$run" = "yes" ]; then stop(); fi ;;
config) if [ "$run" = "yes" ]; then config(); fi ;;
*) echo "Usage: $0 [ start | stop | config ] $12 ;;
esac
}
Then simple daemons turn into:
#!/bin/sh
#
# PROVIDES: foobar
# REQUIRES: ...
# ...
name=foobar
. /etc/rc.setup
run
Breaking out the seperate functions allows you to change just part of
it easily. For example, if the daemon creates a pid, or the flags to
it, you'd do:
#!/bin/sh
# ...
name=smartbar
. /etc/rc.setup
start() {
$foobar_program $foobar_flags
echo -n " foobar"
}
run
Some things are hairy enough to require doing everything over, and
there is probably a better way to organize the subroutines, but that's
the general idea.
The next step is to get ports authors to start using /etc/rc.setup or
whatever it gets called :-).
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: src/release/Makefile patch so cdrom will autoboot
Don't want to step on toes.. Someone please commit. I believe we need to 'load /kernel' no matter what... it's the 'read' that's in question. Allows a cdrom to autoboot. Actually, the kernel should be autoloaded anyway, but you appear to be right here. patch also located at ~jwd/src/src/release/Makefile.patch so you don't have to cut'n'paste. Unless someone has a good reason not to, I think you should just commit it. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
Garrett Rooney writes: On Tue, Oct 24, 2000 at 04:49:40AM +0700, Alexey Dokuchaev wrote: Well, would not be this stepping aside from BSD startup sequence, which we all know and love? Having dozens of small files instead of pair of big ones always frustrates me when I have to work with linux. and at the very least, with a number of smaller files, assuming they're named well, you can find what you're looking for faster, and not have to dig though the one monolithic script to find out how sometihng is working. Well, we *already* have over a dozen /etc/rc.* files on -current. And we *don't* have the advantage of a consistent interface to control all the functions in /etc/rc. If you break things up, then if you need to restart the mail server, just go "/etc/rc.d/sendmail restart". dhcpd? "/etc/rc.d/sendmail/dhcpd restart". Etc. Of course, for consistency ports should be tweaked to use have the same provides/requires setup, and use rc.subr instead of the homegrown hacks. Which brings up the real downside of doing this - you have to parse rc.subr and rc.conf for *every* one of those scripts. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
Alexey Dokuchaev writes: Well, we *already* have over a dozen /etc/rc.* files on -current. And we *don't* have the advantage of a consistent interface to control all the functions in /etc/rc. If you break things up, then if you need to restart the mail server, just go "/etc/rc.d/sendmail restart". dhcpd? "/etc/rc.d/sendmail/dhcpd restart". Etc. Actually, the point is that writing TONS of scripts to get your work done (that's what Linux world does) always pissed me off. You have a shell script that is in fact a wrapper for another shell script, and like this in turn it goes on and on and on again. Icky! :-) I don't like how Linux smells. Well, I don't like Linux much either. On the other hand, I hate dealing with a lots of little things all of which are just slightly different from each other even more - and the latter is what you get from /etc/rc. Why can't I simply write kill -1 `cat /var/run/sendmail.pid`? I don't consider it being sagnificantly longer than writing /etc/rc.d/sendmail restart. After all, if your typing speed is good enough, it doesn't really matter whether you type in 30 or 20 chars. You can still do that. However, do you know how to get everything listed in /etc/defaults/rc.conf to reread it's config file? With the approach being advocated, the answer is "yes" - even if you don't know whether or not the daemon in question *has* a config file. That's the thing I like about all those scripts (SysV, linux, whatever) - I didn't have to deal with cruft like that. Yeah, for some things, this means you wind up running a script that's a wrapper for the vendor-provided script to make it meet your standards. If you really hate that, ignore the vendors script and talk directly to the application - but they get little enough use that I'd rather use the vendor's API and let it be wasteful. After all, if they got a lot of use, having different interface wouldn't be a problem. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release breakage on today's -current
will I'm sure there are better things to disable, like MFS, SYSV*, will P1003_P1B and friends, and ICMP_BANDLIM. MFS is required; don't forget we have mfsroot.flp :-) The name is historical; we use md(4) not MFS. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
Jordan Hubbard writes: [redirected to just -current; I'm not sure what this has to do with -net] I agree. I've been using them for a while on my dog slow Windows CE machine. There were some minor issues when they were first committed to NetBSD on some platforms (due to a too early use of ps and some brokeness in ps on pmax, for example), but these were quickly resolved. So, who wants to do a proof-of-concept implementation for -current which integrates with our existing rc.conf mechanism? In order to obey POLA, we should at least have the separate scripts switch off the same knobs whenever possible. I'm in the midst of trying to install NetBSD so I can look at this. If no one else steps forward to do it, I can put together a patch. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smp instability
Chuck Robey writes:
I'm having rather extreme problems with stability on my dual PIII
setup. I know this is to be expected, but it's gotten so extreme on my
system, I can't spend more than a few minutes before it locks up.
Is there any chance that I could make things better by using a sysctl to
tell the box it's now a single-cpu system? I can't read man pages at the
moment (I'm composing this on my Sparc Ultra-5) so if this might work, and
someone knows the exact command to use, I'd appreciate a bit of help.
Try "sysctl -w machdep.smp_active=0". It's not clear how much good
this will do since you'll still be running an SMP kernel. Please
let us know how that works.
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /boot partition?
David O'Brien writes: On Fri, Oct 13, 2000 at 07:18:05PM +0300, Maxim Sobolev wrote: Nope, the loader can load stuff from other partitions, even from some strange ones like msdos ;), so theoretically it should be possible to have /boot, or even /boot/kernel, on another partition (it may require to tweak loader config files, though), but I really do not see any reasons behind such weird setup. Our IA-64 offering may end up having /boot as a native partition (ie, vfat32) as their firmware understands it. Solaris 8 uses this setup. One partition of about 10meg for booting, mount as /boot after the system comes up. BTW, kudos to the FreeBSD install team. Much as the FreeBSD install may be maligned, it's much more intuitive, flexible and in general better than what Sun is doing with for Solaris 8. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot partition?
Maxim Sobolev writes:
"Michael C . Wu" wrote:
On Fri, Oct 13, 2000 at 07:22:20AM -0500, Mike Meyer scribbled:
| Just curious - now that the kernel has moved into /boot/kernel/kernel,
| does anyone know how well would it work to put /boot in it's own
| partition (possibly in it's own slice)?
I do not think loader can see stuff in other partitions.
Nope, the loader can load stuff from other partitions, even from some strange
ones like msdos ;), so theoretically it should be possible to have /boot, or
even /boot/kernel, on another partition (it may require to tweak loader config
files, though), but I really do not see any reasons behind such weird setup.
Since you implied a question...
This is a standard setup for Linux, so Linux people dealing with
problems with the root file system try and make it work in -stable
(with no luck). The best example would be to make /boot one file
system so you can get vinum loaded and running, then have everything
else on a vinum disk. This minimizes the set of things you don't have
on vinum.
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
system lockups in -current - during boot.
I'm getting hard lockups booting a -current kernel supped about 6 hours ago. If I try to boot multiuser, I get a message about the ethernet interface being configured, and then nothing. If I boot single user, it comes up fine, and I can configure the NIC. The system then locks up maybe 10 seconds later, doing nothing but tapping return every so often. I don't get enough response to start a debugger in either case. The best data I can contribute is a dmesg from the same hardware booting -stable. Suggestions? Pointers? Fixes? mike Oct 14 23:27:24 eve /kernel: Copyright (c) 1992-2000 The FreeBSD Project. Oct 14 23:27:24 eve /kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Oct 14 23:27:24 eve /kernel: The Regents of the University of California. All rights reserved. Oct 14 23:27:24 eve /kernel: FreeBSD 4.1.1-STABLE #0: Fri Oct 13 04:24:22 CDT 2000 Oct 14 23:27:24 eve /kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EVE Oct 14 23:27:24 eve /kernel: Timecounter "i8254" frequency 1193182 Hz Oct 14 23:27:24 eve /kernel: Timecounter "TSC" frequency 501138990 Hz Oct 14 23:27:24 eve /kernel: CPU: AMD-K6(tm) 3D processor (501.14-MHz 586-class CPU) Oct 14 23:27:24 eve /kernel: Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Oct 14 23:27:24 eve /kernel: Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX Oct 14 23:27:24 eve /kernel: AMD Features=0x8800SYSCALL,3DNow! Oct 14 23:27:24 eve /kernel: real memory = 67043328 (65472K bytes) Oct 14 23:27:24 eve /kernel: avail memory = 62480384 (61016K bytes) Oct 14 23:27:24 eve /kernel: Preloaded elf kernel "kernel" at 0xc02d3000. Oct 14 23:27:24 eve /kernel: K6-family MTRR support enabled (2 registers) Oct 14 23:27:24 eve /kernel: npx0: math processor on motherboard Oct 14 23:27:24 eve /kernel: npx0: INT 16 interface Oct 14 23:27:24 eve /kernel: pcib0: Host to PCI bridge on motherboard Oct 14 23:27:24 eve /kernel: pci0: PCI bus on pcib0 Oct 14 23:27:24 eve /kernel: pcib2: VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge at device 1.0 on pci0 Oct 14 23:27:24 eve /kernel: pci1: PCI bus on pcib2 Oct 14 23:27:24 eve /kernel: pci1: ATI Rage128-RF graphics accelerator at 0.0 irq 11 Oct 14 23:27:24 eve /kernel: isab0: VIA 82C596B PCI-ISA bridge at device 7.0 on pci0 Oct 14 23:27:24 eve /kernel: isa0: ISA bus on isab0 Oct 14 23:27:24 eve /kernel: atapci0: VIA 82C596 ATA66 controller port 0xe000-0xe00f at device 7.1 on pci0 Oct 14 23:27:24 eve /kernel: ata0: at 0x1f0 irq 14 on atapci0 Oct 14 23:27:24 eve /kernel: ata1: at 0x170 irq 15 on atapci0 Oct 14 23:27:24 eve /kernel: uhci0: VIA 83C572 USB controller port 0xe400-0xe41f irq 10 at device 7.2 on pci0 Oct 14 23:27:24 eve /kernel: usb0: VIA 83C572 USB controller on uhci0 Oct 14 23:27:24 eve /kernel: usb0: USB revision 1.0 Oct 14 23:27:24 eve /kernel: uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Oct 14 23:27:24 eve /kernel: uhub0: 2 ports with 2 removable, self powered Oct 14 23:27:24 eve /kernel: ugen0: Diamond Multimedia Systems, Inc. SupraExpress 56e USB V.90, rev 1.00/1.00, addr 2 Oct 14 23:27:24 eve /kernel: xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xe800-0xe87f mem 0xeb00-0xeb7f irq 5 at device 10.0 on pci0 Oct 14 23:27:24 eve /kernel: xl0: Ethernet address: 00:50:04:84:ac:f1 Oct 14 23:27:24 eve /kernel: miibus0: MII bus on xl0 Oct 14 23:27:24 eve /kernel: xlphy0: 3Com internal media interface on miibus0 Oct 14 23:27:24 eve /kernel: xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Oct 14 23:27:24 eve /kernel: pci0: unknown card (vendor=0x1274, dev=0x5000) at 12.0 irq 5 Oct 14 23:27:24 eve /kernel: pcib1: Host to PCI bridge on motherboard Oct 14 23:27:24 eve /kernel: pci2: PCI bus on pcib1 Oct 14 23:27:24 eve /kernel: fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 Oct 14 23:27:24 eve /kernel: fdc0: FIFO enabled, 8 bytes threshold Oct 14 23:27:24 eve /kernel: fd0: 1440-KB 3.5" drive on fdc0 drive 0 Oct 14 23:27:24 eve /kernel: atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 Oct 14 23:27:24 eve /kernel: atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 Oct 14 23:27:24 eve /kernel: kbd0 at atkbd0 Oct 14 23:27:24 eve /kernel: psm0: PS/2 Mouse irq 12 on atkbdc0 Oct 14 23:27:24 eve /kernel: psm0: model Generic PS/2 mouse, device ID 0 Oct 14 23:27:24 eve /kernel: vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Oct 14 23:27:24 eve /kernel: sc0: System console at flags 0x100 on isa0 Oct 14 23:27:24 eve /kernel: sc0: VGA 16 virtual consoles, flags=0x300 Oct 14 23:27:24 eve /kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Oct 14 23:27:24 eve /kernel: sio0: type 16550A Oct 14 23:27:24 eve /kernel: sio1 at port 0x2f8-0x2ff irq 3 on isa0 Oct 14 23:27:24 eve /kernel: sio1: type 16550A Oct 14 23:27:24 eve /kernel: ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 Oct 14 23:27:24 eve /kernel: ppc0: SMC-like chipset (ECP/EPP
/boot partition?
Just curious - now that the kernel has moved into /boot/kernel/kernel, does anyone know how well would it work to put /boot in it's own partition (possibly in it's own slice)? Thanx, mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Upgrading -stable - -current, boot failure?
I've got a system with 4.1-STABLE installed. I mount -current sources
on it, do make buildworld/buildkernel/installkernel/installworld and
reboot. The boot loader runs, gives me the "booting default in..."
countdown, prints "|", and then stops. After thrashing the disks (with
*no* boot messages), I get a prompt from init.
Since the same sources build and boot properly elsewhere, I assume
I've missed a step. I normally run mergemaster after installworld and
rebooting singleuser. Could someone provide the clue I've not got?
thanx,
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
video mpeg broken?
It seems that something has broken plaympeg - at least for video. In trying to play video back, I get a black window and no images. Audio playback seems fine. This is something I don't do often, so I'm not sure when it happened. Anyone else seeing this? Anyone working on it? Thanx, mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: video mpeg broken?
Nickolay Dudorov writes:
In article [EMAIL PROTECTED] you wrote:
It seems that something has broken plaympeg - at least for video. In
trying to play video back, I get a black window and no images. Audio
playback seems fine. This is something I don't do often, so I'm not
sure when it happened.
I've seen this "black window" with plaympeg also.
It sometimes help if I move the window - after that I can see
the video. (My system - -current with XFree86-4.01 and
Matrox MGA G200 AGP, SDL -1.1.4, SMPEG - 0.4.0).
Well, that doesn't work here. The system is -current (as of Saturday),
XFree86-4.0.1, Diamond Viper 550, SDL-1.1.5, SMPEG-0.4.0.
Thanx,
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernels won't boot
That was it. Is the 4MB kernel size limit documented anywhere? I don't know :-) I luckily noticed this by a lot of trials. I'm not aware of any 4MB limit on kernel size (and I ought to be if there is one 8). Can you run the details past me? (I've regularly booted much larger kernels in the past...) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Latest ACPI megapatch update
http://people.freebsd.org/~msmith/acpica-bsd-20001008.tar.gz New in this patch: - Fixes for the EC code (error handling) - Fixes for power/sleep button handling (should work for both control method and fixed buttons) - Host:PCI bridges are now detected and attached using ACPI rather than by rummaging in PCI configuration space. (If this fails, we fall back to the old techniques). - Print the current temperature in detected thermal zones (just cosmetic, and reveals that some machines are a bit confused already). Comments, suggestions, bugfixes, etc. welcome as per usual. It looks like we will be switching to this codebase fairly soon (the acpi-jp folks have been discussing this), so anyone with an interest in it is encouraged to tinker. There is a known problem with this code and the Dell Inspiron 7500 (and possibly other laptops with similar BIOS AML) which I'm trying to fix. Don't expect it to work there yet. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
re: sio problems?
attila! writes: on Sat, 7 Oct 2000 20:03:12 -0500 (CDT), Mike Meyer [EMAIL PROTECTED] said: I recently got my digital camera back out, and started pulling the old pictures from it. I noticed something I hadn't ever seen before - silo overflows from the sio port. At the moment, I'm wondering if this is a known problem that is being investigated (SMPNG comes to mind), or something new. Other than the sio irq overflows, which does not seem to particularly impact performance and which I am sure will be solved, I think team has done a superb job with the SMPNG cutover. Well, it's making a serious impact on performance for camera. I wasn't able to reliably download images at even half speed. I gave up and dropped from 115K to 9.6K. I can probably get better speed than that, but even if it's 28K, that's noticable :-(. On the other hand, that's the only real problem I've seen. Unfortunately, I haven't used the thing since the hardware was cutover from -stable, so I can't pin it down either. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org
Yea, guess so, but I cant help but notice this started after the buyout by BSDI Uh, folks, releng4 is hosted at (and donated by) Yahoo, and BSDi have exactly *nothing* to do with its availability or otherwise. Before making absurd allegations like this, please apply a few neurons to the task. Note also that you're insulting those of us that choose to work for BSDi in the name of FreeBSD; not really the brighest of things to do. On Sun, 8 Oct 2000, Thomas T. Veldhouse wrote: And releng4.freebsd.org is totally missing from the Internet. I suppose they are having another hardware problem again? Seems FreeBSD is a bit tough on hardware these days. Tom Veldhouse [EMAIL PROTECTED] - Original Message - From: "Bill Woods mail" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, October 08, 2000 8:18 PM Subject: current.freebsd.org whats up with current.freebsd.org, its not allowing anon ftp 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 -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
