Re: Junior Kernel Hacker task: improve vnode->v_tag
On Sat, 8 Sep 2001, Chris Costello wrote: > On Saturday, September 08, 2001, Poul-Henning Kamp wrote: > > No actually not, I want something short and predictable like > > "VT_CODA". > >How about my second suggestion: making v_tag point to > mp->mnt_stat.f_fstypename, or a copy thereof? Good, but I as far as I understand this, the only legitimate point of v_tag is to tell applications like fstat(1) the type of the vnode. fstat can find chase the kernel pointers in vp->v_mount->mnt_stat->f_fstypename almost as (un)easily as it could chase vp->v_tag if v_tag is a pointer. Copying the string would give ugly bloat, but would not be all that much worse than the bloat for a pointer on alphas (the contents of the string "VT_CODA" takes the same space as a pointer on alphas). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: none (cvs mirrors)
>From: Kris Kennaway <[EMAIL PROTECTED]> >To: KSrinivasa Raghavan <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], >[EMAIL PROTECTED] >Subject: Re: none (cvs mirrors) >Date: Fri, 7 Sep 2001 16:46:15 -0700 > >On Fri, Sep 07, 2001 at 11:24:58PM +, KSrinivasa Raghavan wrote: > > Hi Kris, > > > > cvsup servers doesn't seem to work as cvs servers. The anoncvs server > > worked yesterday, but today I am seeing other problems. > >Yes, I was being sarcastic. They're different protocols. > I thought both the services were provided by the same system but ... > > I have been checking out sources directly into /usr directory and using >it. > > Today I am getting this error message: > > > > # cvs co ports/www/w3m-img > > cannot mkdir /cvstmp/cvs-serv64094/./CVS > > No space left on device > > > > I didn't create cvstmp before too and it worked. > > > > Couldn't find any query related to this in FreeBSD mailing list. > >Known problem..should be fixed soon. > >Kris ... happy to know about the fix coming soon. Thanks, Srini. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Junior Kernel Hacker task: improve vnode->v_tag
On Saturday, September 08, 2001, Poul-Henning Kamp wrote: > No actually not, I want something short and predictable like > "VT_CODA". How about my second suggestion: making v_tag point to mp->mnt_stat.f_fstypename, or a copy thereof? -- +---+--+ | Chris Costello| Why do we want intelligent terminals | | [EMAIL PROTECTED] | when there are so many stupid users? | +---+--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Junior Kernel Hacker task: improve vnode->v_tag
In message <[EMAIL PROTECTED]>, Chris Costello writes: >On Tuesday, September 04, 2001, Maxim Sobolev wrote: >Content-Description: ASCII C program text >> Index: coda/coda.h >> === >> RCS file: /home/ncvs/src/sys/coda/coda.h,v >> retrieving revision 1.9 >> diff -d -u -r1.9 coda.h >> --- coda/coda.h 1999/12/29 04:54:30 1.9 >> +++ coda/coda.h 2001/09/04 18:46:42 >> @@ -41,7 +41,7 @@ >> #ifndef _CODA_HEADER_ >> #define _CODA_HEADER_ >> >> - >> +#define VT_CODA "VT_CODA" >... > > I don't think that the point of this is to use a string like >that, but rather a descriptive string, i.e. No actually not, I want something short and predictable like "VT_CODA". -- 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
Need a Home Loan? We Can Help!!
Title: Free Rate Quote "Refinancing Your Current Mortgage Makes $ense!" Mortgage Rates Are So Low! You Can Save Thousands Of Dollars By Taking Advantage Now! "WE ARE AN ASSOCIATION OF MORTGAGE BROKERS AND LENDERS WITH THE BEST RATES AND THE LOWEST COSTS!" We have thousands of loan programs through hundreds of lenders! You can choose from "Adjustable Rate Mortgages as low as 3.95%" and "Fixed Rate Mortgages as low as 6.50% all with the lowest costs in the Nation!"* "YOU CAN BUY DOWN YOUR INTEREST RATE TO AS LOW AS YOU CAN AFFORD!" *All rates are based on qualification! Click here for your "FREE RATE QUOTE"! CLICK ON LOANS BELOW FOR YOUR FREE APPLICATION! Purchase Loans - Thousands of programs for First Mortgages!Refinance Loans - Reduce your monthly payments and Get Cash Back! Second Mortgages - We can help you get from 90% up to 125% of your homes value! (ratios vary by state) Debt Consolidation - Combine all your bills into One Low Monthly Payment!First Time Home Buyers - We can help you buy with Low Money Down, and even Get Cash Back! *All rates are based on qualification! We have programs for EVERY credit situation!Click here for your FREE RATE QUOTE! If you feel that you have received this message in error, please follow the below instructions and you will be removed immediately. We immediately honor all requests to be removed from this list. This message is being sent to you in compliance with the Federal legislation for commercial e-mail (H.R.4176 - Section 101, Paragraph (e)(1)(a)) and Bill s.1618 Title III passed by the 105th US Congress., further transmissions to you by the sender of this e-mail may be stopped at no cost to you by submitting a request to be removed. Click Here to Send a Remove Request. No need to type any message.
Re: none (cvs mirrors)
On Fri, Sep 07, 2001 at 11:24:58PM +, KSrinivasa Raghavan wrote: > Hi Kris, > > cvsup servers doesn't seem to work as cvs servers. The anoncvs server > worked yesterday, but today I am seeing other problems. Yes, I was being sarcastic. They're different protocols. > I have been checking out sources directly into /usr directory and using it. > Today I am getting this error message: > > # cvs co ports/www/w3m-img > cannot mkdir /cvstmp/cvs-serv64094/./CVS > No space left on device > > I didn't create cvstmp before too and it worked. > > Couldn't find any query related to this in FreeBSD mailing list. Known problem..should be fixed soon. Kris PGP signature
Re: none (cvsup2 as cvs server)
Hi Jim, Does it have a different user:password ? (I used anoncvs:anoncvs). # export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/ncvs # cvs login (Logging in to [EMAIL PROTECTED]) CVS password: cvs [login aborted]: connect to cvsup2.freebsd.org:2401 failed: Connection refused Thanks, Srini. >From: Jim Bryant <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: John Polstra <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED], [EMAIL PROTECTED] >Subject: Re: none >Date: Wed, 05 Sep 2001 20:49:39 -0500 > >John Polstra wrote: > >>In article <[EMAIL PROTECTED]>, >>KSrinivasa Raghavan <[EMAIL PROTECTED]> wrote: >> >>>For some reasons I was unable to checkout sources from cvs server of >>>FreeBSD sources. I have been using anoncvs.FreeBSD.org to fetch the >>>files. >>> >> >>I believe the administrators have been upgrading that system. I >>don't know when it will be back up. >> >> >>>I am getting "Operation timed out" errors. Are there any other cvs >>>servers >>>from which I can check out the sources ? >>> >> >>Not as far as I know. >> >>By the way, more people would read your mail if you would type in a >>subject. :-) >> >>John > > >cvsup2.freebsd.org through cvsupn.freebsd.org seem to work just fine... > > >jim _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Junior Kernel Hacker task: improve vnode->v_tag
On Friday, September 07, 2001, Chris Costello wrote: >But is it necessary that you really use those defines? The > idea is not to use them globally. Perhaps getnewvnode() should > get the string from `mp->mnt_stat.f_mntfromname', instead... ^ Er, fstypename... -- +---++ | Chris Costello| Unprecedented performance: | | [EMAIL PROTECTED] | Nothing ever ran this slow before. | +---++ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re:none (cvs mirrors)
Hi Kris, cvsup servers doesn't seem to work as cvs servers. The anoncvs server worked yesterday, but today I am seeing other problems. I have been checking out sources directly into /usr directory and using it. Today I am getting this error message: # cvs co ports/www/w3m-img cannot mkdir /cvstmp/cvs-serv64094/./CVS No space left on device I didn't create cvstmp before too and it worked. Couldn't find any query related to this in FreeBSD mailing list. Thanks, Srini. >From: Kris Kennaway <[EMAIL PROTECTED]> >To: Jim Bryant <[EMAIL PROTECTED]> >CC: John Polstra <[EMAIL PROTECTED]>, [EMAIL PROTECTED], >[EMAIL PROTECTED] >Subject: Re: none >Date: Wed, 5 Sep 2001 20:35:51 -0700 > >On Wed, Sep 05, 2001 at 08:49:39PM -0500, Jim Bryant wrote: > > > >>For some reasons I was unable to checkout sources from cvs server of > > >>FreeBSD sources. I have been using anoncvs.FreeBSD.org to fetch the > > >>files. > > > cvsup2.freebsd.org through cvsupn.freebsd.org seem to work just fine... > >as cvs_up_ servers, yes. As cvs servers, they don't work quite so well. > >Kris ><< attach3 >> _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: hack volatile bzero and bcopy
In message <[EMAIL PROTECTED]> Bruce Evans writes: : In the case of if_ie.c and bcopy(), bcopy() is not suitable for copying : memory that doesn't behave like RAM. Some optimized versions of it : do out of order and/or repeated copies. This might be very bad for : volatile device memory. I think rewriting if_ie.c to use bus_space : would make most of the warnings go away automatically. Right. bus_space_read/write_N likely should be used instead. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Junior Kernel Hacker task: improve vnode->v_tag
On Tuesday, September 04, 2001, Maxim Sobolev wrote: Content-Description: ASCII C program text > Index: coda/coda.h > === > RCS file: /home/ncvs/src/sys/coda/coda.h,v > retrieving revision 1.9 > diff -d -u -r1.9 coda.h > --- coda/coda.h 1999/12/29 04:54:30 1.9 > +++ coda/coda.h 2001/09/04 18:46:42 > @@ -41,7 +41,7 @@ > #ifndef _CODA_HEADER_ > #define _CODA_HEADER_ > > - > +#define VT_CODA "VT_CODA" ... I don't think that the point of this is to use a string like that, but rather a descriptive string, i.e. #define VT_FDESCFS "file-descriptor file system" #define VT_NFS "network file system" But is it necessary that you really use those defines? The idea is not to use them globally. Perhaps getnewvnode() should get the string from `mp->mnt_stat.f_mntfromname', instead... -- +---+---+ | Chris Costello| As far as we know, our computer has never | | [EMAIL PROTECTED] | had an undetected error.- Weisert | +---+---+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SSH remote X problem
Le 2001-09-07, Pete Carah écrivait : > On both of my -current systems, I can't remotely display X apps back > to my (non-current) laptop. I don't know if this is related to the > upgrade in ssh (my suspicion) or some other (likely library) issue. With -CURRENT cvsupped from this afternoon, I can launch an X client on the -CURRENT box and have the X connection forwarded to my -STABLE desktop machine. Thomas. -- Thomas Quinot ** Département Informatique & Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: One fixed, one (of mine) to go
> Apparently debug.acpi.avoid doesn't avoid the timer problem anyhow, > and the earlier panic appears to have been too early (but was fixed; > thanks Mike). I'm going to ignore the bogus clock some and try to track > things down as Mike suggested in private mail. That should be debug.acpi.disable, as per acpi(4). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
> I suppose I could volunteer for this. I've been dissecting the loader for > months now and hitting the 4th "fence" has been bothersome.. As far as > braving those pesky naysayers, I thought about doing it on my own anyway so > if no one wants the change, I'll just keep it for my own systems. =) > > If nothing else, I'm very curious to see how small I can get a Scheme > implementation.. I'd at least be curious to see how small the alternatives are. I'm not enormously keen to migrate since the .4th support code we have is fairly comprehensive, but it would be foolish to ignore the options. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI problems
> Since you posted this message to -current, I just assumed you > had upgraded to the latest code, and thus were using ACPI (this > is the same thing that ended up confusing Mike Smith, who also > made the mistake in correcting me to say that ACPI was being > loaded twice on your system). Actually, I said that this was a possible problem. > The general form of the problem is: > > 1) PnP BIOS tells FreeBSD about the devices > 2) The device.hints tells FreeBSD about the > devices This is the general form of a different problem. The hints DO NOT supply PNP identifiers. Got it yet? > A "quick hack", which was iscussed but not implemented at > the time I read the message about it, would be to disable > the ACPI timer It's a) implemented and b) documented in the acpi(4) manpage (and has been for some time). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SSH remote X problem
On both of my -current systems, I can't remotely display X apps back to my (non-current) laptop. I don't know if this is related to the upgrade in ssh (my suspicion) or some other (likely library) issue. One of them is running X 4.1.0 downloaded from xfree86.org; the other 3.3.6, so the problem is not likely to be in the X side of things. Error is a timeout trying to open the remote server: -- puffin.altadena:1009% xclock Error: Can't open display: puffin.altadena.net:10.0 after a long pause. One telling thing may be that puffin is the aladdin-V system where the clock runs fast; however the other has a normal timecounter (and times out faster). Also this happens when ACPI is disabled completely so I don't think the bogus timecounter matters here. (this happens with either protocol V1 or V2). The X server is on a 4-stable (4.4-RC in uname) system so SSH is the updated 2.3.0. Don't know if it happens between two ssh-2.9 systems (the one here is not cooperating bringing up xdm, likely because pam likes to core if you enable K4 currently). -- Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: hack volatile bzero and bcopy
> well this is th idea, because I think that bcopy is probably a safe > operation > on the volatile structures if the driver knows that they are presently > owned by it.. (e.g. mailboxes) *probably* safe? For truly volatile memory bzero & bcopy are *not* safe. Anyone remember the origial 68000's `clr' instruction that did read followed by write to clear memory? You _can_ use that clr instn in bzero if the passed in ptr does not point to volatile memory. bcopy can also use efficiency tricks if the src & dst are not aligned on the same 4 byte boundary. AMD 29k for example had an `extract' instruction that allowed unaligned copying at memory bandwidth. But usually one punted on boundary conditions and didn't think twice about refetching a word. One can't be so cavalier if bcopy accepted volatile ptrs. You can use similar tricks on systems with wide cache lines and some of these tricks would be illegal on volatile memory. > out-of order is probably ok for a buffer if you know that it's > presently yours to write into. If the area being bcopied/bzeroed has this behavior why not remove the volatile from the struct ptrs instead of "fixing" bcopy/bzero? > 2/ add to the prototype of bzero and bcopy so that volatile pointers are > acceptable > arguments. (I don't see any reason to not do this). Because the (informal) defn of bcopy/bzero does not allow volatile arguments. You are wagging the dog. Why not just cast these ptrs at the call sites where you _know_ bcopy, bzero use is safe. That sort of documents what is going on without opening a big hole. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: postfix fails to start
On Friday 07 September 2001 09:54 am, Michael Harnois wrote: > On Fri, 7 Sep 2001 17:03:00 +0200 (METDST), [EMAIL PROTECTED] (Hellmuth Michaelis) said: > > After the reboot i tried postfix: > > > > Sep 7 16:19:49 hmscrap postfix[372]: fatal: could not find any > > active network interfaces > > Do you have a way to try dhclient? As I said, that failed with a > similar error for me. I had the same problem with postfix this morning. I did a portupgrade on it and after it rebuilt it seems to work. I wasn't so lucky with dhcpd, it still can't find it's interface and rebuilding the port doesn't help. I don't use dhclient, but all these problems seem to be similar. Maybe today's build will fix it? We'll see... Beech -- Micro$oft: "Where can we make you go today?" --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __getcwd & errno 20 (Not a directory) vfs_cache.c
Peter Wemm wrote: > >The really annoying aspect to this is that it doesn't > > happen everytime, and happens more often when in a nfs > > mounted directory vs. a local directory. > > Yes, this is expected due to __getcwd(2) being incomplete. > > NFS expires the directory nodes after about 10 minutes. This stops > __getcwd() working, and stops things like /proc/*/file from working. (just > try executing /usr/local/bin/something where /usr/local is NFS mounted, and > wait for ~10 minutes.. /proc/pid/file will switch to: > lr-xr-xr-x 1 test users 7 Sep 6 23:51 /proc/521/file@ -> unknown Implementing "getcwd" as a system call is a stupid idea; I believe the only reason FreeBSD has this is that Linux had it first. A canonically correct answer would be to return "." in all cases, anyway, since it would allow current-directory relative programs to work. The only programs which would suffer are: o Programs which are too stupid to remember that they called "chdir", but want to cache the cwd so that the next time they are run, they can call "chdir" again (and forget again). o Programs which print out the current working directory as eye candy for the user. Remember that there are file systems which permit hard links on directories, and then "forget" the down path, for which the both of these uses will inevitably break, anyway. Even the existance of a "getcwd(3)" (as opposed to a "getcwd(2)") begs for these to break on the assumption that such links will either be "remembered" following traversal, or will all have equivalent permissions. It's really, really stupid to assume that "all the world's an EXT2FS", or "all the world's a post 1994 BSD FFS"... and this is nowhere _more_ true than when doing things like an NFS mount of a completely alien FS. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: postfix fails to start
From the keyboard of Michael Harnois: > > Sep 7 16:19:49 hmscrap postfix[372]: fatal: could not find any > > active network interfaces > > Do you have a way to try dhclient? As I said, that failed with a > similar error for me. I´ll see if i can try. In the meantime i tried to find out why postfix fails: for the "postfix" port, it fails in postfix´ src/util/inet_addr_local.c and (thank Wietse Venema, it seems _all_ files have a builtin TEST case with a main() !!!) one can compile just this file with cc -o TEST -DTEST -DFREEBSD5 -I../../include -L../../lib inet_addr_local.c -lutil in that same subdirctory and get a program TEST which when executed exhibits the above described behaviour. The main thing this program does is to open a socket and then do a ioctl(sock, SIOCGIFCONF, (char *) &ifc) which does not fail, but seems that it somehow does not work as advertized anymore. Perhaps i can find out more later as i now have to tell my kids a goodnight story hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: hack volatile bzero and bcopy
Bruce Evans wrote: > > > > This just breaks the warning. well this is th idea, because I think that bcopy is probably a safe operation on the volatile structures if the driver knows that they are presently owned by it.. (e.g. mailboxes) The correct answer would be, as you suggest, bus-space operations but that's more work than this driver really warrants at this stage. It's just be acceptable in my eyes to "break the warnings" as you put it. (remember, pointless warnings distract from real warnings). > > In the case of if_ie.c and bcopy(), bcopy() is not suitable for copying > memory that doesn't behave like RAM. Some optimized versions of it > do out of order and/or repeated copies. This might be very bad for > volatile device memory. I think rewriting if_ie.c to use bus_space > would make most of the warnings go away automatically. out-of order is probably ok for a buffer if you know that it's presently yours to write into. I'd like to to some of the following: 1/ add the hack to places that do this to reduce distracting warning messages or 2/ add to the prototype of bzero and bcopy so that volatile pointers are acceptable arguments. (I don't see any reason to not do this). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
failure to detect network interfaces
As of about two days ago, -current began to exhibit a problem which affects at least postfix and dhclient, wherein these two programs fail to find any active network interfaces. Could someone who understands such things take a look at the thread "postfix fails to start"? Thanks. -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota "Begin the morning by saying to thyself, I shall meet with the busy-body, the ungrateful, arrogant, deceitful, envious, unsocial. All these things happen to them by reason of their ignorance of what is good and evil." --Marcus Aurelius To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: postfix fails to start
On Fri, 7 Sep 2001 17:03:00 +0200 (METDST), [EMAIL PROTECTED] (Hellmuth Michaelis) said: > After the reboot i tried postfix: > Sep 7 16:19:49 hmscrap postfix[372]: fatal: could not find any > active network interfaces Do you have a way to try dhclient? As I said, that failed with a similar error for me. -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota "Begin the morning by saying to thyself, I shall meet with the busy-body, the ungrateful, arrogant, deceitful, envious, unsocial. All these things happen to them by reason of their ignorance of what is good and evil." --Marcus Aurelius To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
auth a835a7f2 unsubscribe freebsd-current albedo@transbay.net
auth a835a7f2 unsubscribe freebsd-current [EMAIL PROTECTED] Dan Albers w: 510-848-6767 x211 h: 510-845-8540 www.7FF.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org
First we had hardware problems, then NFS was broken on the cluster for awhile, preventing current.freebsd.org from getting at the CVS repository. It's fixed now and I see that a snapshot is building as we speak. - Jordan From: Alexey Zelkin <[EMAIL PROTECTED]> Subject: current.freebsd.org Date: Fri, 7 Sep 2001 19:49:56 +0300 > hi, > > Is there any reason why 5.0-RELEASE snapshots are not building/uploading > to current.freebsd.org for about 3 months ? Latest i386 snapshot is > 20010618. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
freebsd> I suppose I could volunteer for this. It would be great, but current /boot/loader has also the fancy feature, tty screen handling (see /usr/share/examples/bootforth if you have never seen before). I heavily depend on this feature for the selection menu of boot kernel using a sample menu; without this feature, I cannot make my duplex CD-ROM[1]. It would be my great pleasure that "creating a boot menu" feature is also implemented in the new /boot/loader. ... or everybody consider that /boot/loader *only* does kernel and module loading? -- - Makoto `MAR' MATSUSHITA Appendix: [1] See also: http://current.jp.FreeBSD.org/#CD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: One fixed, one (of mine) to go
> >Is there a way to set a loader env from a file? (I presume that is part > >of what prompted the rather funny quasi-flame-war about loader interpreter > >base. Lisp indeed :-) Actually I remember Jordan (and at least one more > >who is now in the fbsd group; who?) getting into the forth loader > >business well before FBSD came on the scene, on the PC532 (of which > >mine never got finished before NSC discontinued the chip :-( > > Yes. The file is /boot/loader.conf. Here's what I have in there at the > moment: > > # -- sysinstall generated deltas -- # > userconfig_script_load="NO" > hw.ata.wc="1" > snd_pcm_load="YES" # Digital sound subsystem > snd_maestro_load="YES" # Maestro > debug.acpi.avoid="_SB_.PCI0.PX40.SIO_" Some things (e.g. acpi_load="NO", either from loader.conf or manual) have no effect in this situation; so the loader is overriding at least parts of loader.conf for acpi. That is one reason I didn't already use this file!!! and was brute-forcing not using acpi by eliminating the module completely... Also, all of Mike's examples mentioned manual "set debug.acpi.avoid="...""; one of the machines in question is remote and so manual boots are a pain. The loader docs are not at all clear that loader.conf and manual sets do the same thing. Apparently debug.acpi.avoid doesn't avoid the timer problem anyhow, and the earlier panic appears to have been too early (but was fixed; thanks Mike). I'm going to ignore the bogus clock some and try to track things down as Mike suggested in private mail. -- Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
On 07-Sep-01 Donny Lee wrote: > Kazutaka YOKOTA wrote: >> Please send me the entire dmesg output after you boot >> the system with "boot -v" at the loader prompt. >> >> And do you have the following line in /boot/device.hints? >> hint.psm.0.irq="12" > > i have ibm 570e, with the same PS/2 mouse problem, Ohh. worse.. > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x3a > fault code = supervisor read, page not present > instruction pointer= 0x8:0xc0268092 > stack pointer = 0x10:0xcd1dc948 > frame pointer = 0x10:0xcd1dc948 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process= 50 (sysctl) > trap number= 12 > \|/ \|/ > "@'/ .. \`@" > /_| \__/ |_\ >\__U_/ > (ps. funny, but i'v run out of humor booting like this... ) > panic: page fault Do you have a debug kernel, if so, can you do 'gdb -k kernel.debug' in your sys/i386/compile/FOO directory and then do 'l *0xc0268092' to see what source line it died on. It's a NULL pointer dereference (as can be seen from the small fault virtual address) so seeing the source line will probably make it rather obvious. Also, compiling ddb into the kernel and getting a traceback would help, too. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
current.freebsd.org
hi, Is there any reason why 5.0-RELEASE snapshots are not building/uploading to current.freebsd.org for about 3 months ? Latest i386 snapshot is 20010618. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
Kazutaka YOKOTA wrote: > Please send me the entire dmesg output after you boot > the system with "boot -v" at the loader prompt. > > And do you have the following line in /boot/device.hints? > hint.psm.0.irq="12" i have ibm 570e, with the same PS/2 mouse problem, Ohh. worse.. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3a fault code = supervisor read, page not present instruction pointer= 0x8:0xc0268092 stack pointer = 0x10:0xcd1dc948 frame pointer = 0x10:0xcd1dc948 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process= 50 (sysctl) trap number= 12 \|/ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ (ps. funny, but i'v run out of humor booting like this... ) panic: page fault syncing disks... done uptime: 5s pccbb0: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] pccbb1: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] Automatic reboot in 15 seconds - press a key on the console to abort -- // Donny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
acpi can't map ports/memory
Yesterday I tried three different nic cards in this machine, two use the rl driver and one uses the xl. I got exactly the same error on all three. These all work pre-acpi commit. here's the dmesg: ACPI debug layer 0x0 debug level 0x0 Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Thu Sep 6 20:37:32 AKDT 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/INTAKE Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 901601981 Hz CPU: AMD Athlon(tm) Processor (901.60-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc044<,AMIE,DSP,3DNow!> real memory = 402653184 (393216K bytes) avail memory = 385740800 (376700K bytes) Preloaded elf kernel "kernel" at 0xc04c2000. Pentium Pro MTRR support enabled Using $PIR table, 8 entries at 0xc00fa040 acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI" frequency 3579545 Hz acpi_cpu0: on acpi0 acpi_cpu: CLK_VAL field overflows P_CNT register acpi_cpu: CLK_VAL field overlaps THT_EN bit acpi_button0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 pci0: on acpi_pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 4.0 (no driver attached) xl0: <3Com 3cSOHO100-TX OfficeConnect> irq 5 at device 5.0 on pci0 xl0: couldn't map ports/memory device_probe_and_attach: xl0 attach returned 6 isab0: at device 20.0 on pci0 isa0: on isab0 atapci0: port 0x1800-0x180f at device 20.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0x14c0-0x14df irq 11 at device 20.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ukbd0: Logitech USB Receiver, rev 1.10/10.20, addr 2, iclass 3/1 kbd0 at ukbd0 uhid0: Logitech USB Receiver, rev 1.10/10.20, addr 2, iclass 3/0 ums0: Logitech USB Receiver, rev 1.10/9.10, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. uhci1: port 0x14e0-0x14ff irq 11 at device 20.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhid1: American Power Conversion Back-UPS 350 FW: 5.1.D USB FW: c1, rev 1.10/1.00, addr 2, iclass 3/0 pci0: at device 20.4 (no driver attached) pcm0: port 0x1814-0x1817,0x1810-0x1813,0x1000-0x10ff irq 10 at device 20.5 on pci0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 ppc0 port 0x378-0x37f on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: PRINTER HP ENHANCED PCL5,PJL plip0: on ppbus0 lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 ppc1: cannot reserve I/O port range sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xee08-0xee0b on acpi0 ppc1: cannot reserve I/O port range ppc1: cannot reserve I/O port range npx0: on motherboard npx0: INT 16 interface orm0: at iomem 0xc-0xc,0xe9000-0xebfff,0xec000-0xe on isa0 fdc1: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 ppc1: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio2: configured irq 3 not in bitmap of probed irqs 0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ad0: 29311MB [59554/16/63] at ata0-master UDMA66 ad1: 38166MB [77545/16/63] at ata0-slave UDMA66 acd0: DVD-ROM at ata1-master PIO4 acd1: CD-RW at ata1-slave PIO4 Mounting root from ufs:/dev/ad1s1a Beech -- Micro$oft: "Where can we make you go today?" --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
> > > 6134244763480 69298 10eb2 scheme > > > > Is that statically-linked? I'm curious to know the size of the bootloader > > forth footprint. The loader is about 150k, so I'm sure you could probably > > fit a nice Scheme interpreter in under that size... ?? > > Dynamically linked. Here is the statically linked size: > > $ size scheme >textdata bss dec hex filename > 127659 110929236 147987 24213 scheme Hmm, if it's stripped down a bit, it might fit nicely in the loader, replacing that 40k libficl mess.. ;) > Here is the /boot/loader size for comparison sake: > > textdatabss dec hex > 4096147456 0 151552 25000 > But ultimately someone has to do the actual work for this to > go beyond mere wishful thinking. I'd be happy to help out > (but not take on the whole task) if anyone braves the > naysayers :-) I suppose I could volunteer for this. I've been dissecting the loader for months now and hitting the 4th "fence" has been bothersome.. As far as braving those pesky naysayers, I thought about doing it on my own anyway so if no one wants the change, I'll just keep it for my own systems. =) If nothing else, I'm very curious to see how small I can get a Scheme implementation.. --Rick C. Petty, aka Snoopy [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
> > Is that statically-linked? I'm curious to know the size of the bootloader > > forth footprint. The loader is about 150k, so I'm sure you could probably > > fit a nice Scheme interpreter in under that size... ?? > > ie. almost all of the size is the dictionary/runtime library. I'll bet it's comparable to a tiny, stripped-down implementation of Scheme.. Only one way to find out... ;) > It's quite hard to beat this, and to be frank, Scheme's syntax is not much > better than Forth's. 8) That's debatable. At least it's consistant & makes sense. Syntax is only an argument of preference. I like Scheme better than LISP because there's less syntax to learn. But the original concern was not of syntax but of the number of committers who know the language. I'll bet there are quite a few who know/love Scheme. I think that if a choice is made, to move to Scheme over LISP because in theory it should have a smaller footprint. Not that it makes a significant difference so long as the loader fits nicely on /boot and out of the way of the loaded kernel (which loads at over 1 MB). --Rick C. Petty, aka Snoopy [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1247] Re: ACPI and PS/2 mouse problem
>I'm not sure exactly what to do here. These resources contain information >we need to know about where we cannot put PnP devices. But if we feed the >information into our current resource manager, we end up with conflicts >with existing devices. > >For the moment, I've changed the code to allocate IRQs shared. The >PS/2 mouse driver should do the same. I'm still trying to work out >what we can and cannot depend on here. 8( The psm driver has been updated to share the irq 12, as of rev 1.37. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
Please send me the entire dmesg output after you boot the system with "boot -v" at the loader prompt. And do you have the following line in /boot/device.hints? hint.psm.0.irq="12" Kazu >I don't know why, but >NOW I have broken PS/2 mouse _without_ acpi module :( >VAIO Z505HS. > >atkbdc0: at port 0x60,0x64 irq 1 on isa0 >atkbd0: flags 0x1 irq 1 on atkbdc0 >kbd0 at atkbd0 >kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d >atkbd1: unable to allocate IRQ >psm0: unable to allocate IRQ > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: postfix fails to start
Ok, today in the morning i checked a fresh current tree out to a different machine which just got done with a make build/installworld, new kernel and a mergemaster run. Before i did that, i updated the postfix port, compiled it and verified it works (this was on a current as of August 1st). After the reboot i tried postfix: Sep 7 16:19:49 hmscrap postfix[372]: fatal: could not find any active network interfaces ifconfig output is indeed normal: rl0: flags=8843 mtu 1500 inet 172.24.124.124 netmask 0xff00 broadcast 172.24.124.255 ether 00:a0:d2:a5:c8:c0 media: Ethernet autoselect (100baseTX) status: active and the net runs without any noticable problems. The current sources i used are from today 9:00 MET (one hour east of GMT). I had a look at the relevant postfix source file but i have no clue what might cause this ... hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
top(1) takes ages to start up
... because it walks through the entire NIS db just to find out what the
longest user name is (/src/usr.bin/top/machine.c 1.5). At this site,
this means 2800 RPC calls and dozens of seconds when the network and/or
NIS server are busy.
What do others think of the following patch?
Thomas.
--- machine.c.dist Fri Jun 1 00:36:51 2001
+++ machine.c Fri Sep 7 16:31:45 2001
@@ -212,7 +212,7 @@
sysctlbyname("kern.smp.active", &smpmode, &modelen, NULL, 0) < 0) ||
modelen != sizeof(smpmode))
smpmode = 0;
-
+#ifndef NO_GETPWENT
while ((pw = getpwent()) != NULL) {
if (strlen(pw->pw_name) > namelength)
namelength = strlen(pw->pw_name);
@@ -223,6 +223,9 @@
namelength = 13;
else if (namelength > 15)
namelength = 15;
+#else
+namelength = 8;
+#endif
if ((kd = kvm_open("/dev/null", "/dev/null", "/dev/null", O_RDONLY, "kvm_open"))
== NULL)
return -1;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: proctitle progress reporting for dump(8)
On Wed, 5 Sep 2001, Mikhail Teterin wrote: > On 5 Sep, Bruce Evans wrote: > > snprintf, strlen, vsnprintf, sysctl, sysctlbyname > > > > I think all of these are safe in practice. > > > > It also accesses some variables that are not safe to access in > > a signal handler (non-auto ones that are not of type "volatile > > sig_atomic_t" or are accessed by reads). This is unsafe in practice. > > E.g., concurrent calls to setproctitle() might corrupt the state of > > the ps_strings variable. > > Mmm, I don't know what those strings are used for -- what's the worst, > that could happen here -- corrupted PS output, or worse? Probably security holes from buffer overruns. strlen() on the static buffer may give a result larger than the buffer size if it is called concurrently with an snprintf() that is modifying the buffer. Then vsnprintf(buf + len, sizeof(buf) - len, fmt, ap) gives a buffer overrun. > In any case, it seems, like a simple lock -- a static variable in the > signal handler would work: > > static signal_handling; > ... > if (signal_handling) > return; > if (signal) > signal_handling = 1; > ... > signal_handling = 0; > > Or is this not safe enough -- race of both signal handlers checking for > the signal_handling at the same time? What would be the right way to do > this generally? Thanks. The signal mask would normally prevent concurrent calls from the SIGINFO handler, but in general you need more than the above (an atomic test-and- set of `signal_handling'). setproctitle() is a library function so it should do this generally or not at all. But it can't do this, since it has no way to handle the `signal_handling' case. It can't just return, because its spec doesn't permit it to fail, and it can't give up control in non-threaded programs. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __getcwd & errno 20 (Not a directory) vfs_cache.c
On Thu, Sep 06, 2001 at 11:50:17PM -0700, Peter Wemm wrote: > Poul-Henning Kamp wrote: > > > > You are not supposed to call __getcwd() directly. > > Yes, but it would be an excellent junior-kernel-hacker task to make it work > in all cases, ie: manually searching parent directories. netbsd does this, > as does linux, and if we're going to emulate the linux getcwd(2) syscall > then we need it. The NetBSD code is probably a good place to start for > pointers, but it wont be directly usable due to name-cache differences. A fix for the Linux enulated version of this was committed last week, I think. Yep - committed by Andrew Gallatin: http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sys/compat/linux/ David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: hack volatile bzero and bcopy
[I replied to parts of this in reponse to a later message] On Thu, 6 Sep 2001, Julian Elischer wrote: > typedef void Xcopy( void volatile *, void volatile *, int); > #define VBCOPY(A,B,L) (*(Xcopy *)&bcopy)((A),(B),(L)) > typedef void Xzero( void volatile *, int); > #define VBZERO(A,L) (*(Xzero *)&bzero)((A),(L)) > > This is kind-of a hack but a couple of things come to mind: > 1/ Most drivers should probably use volatile mor ethan they do if they > share > structures with hardware. These often need bcopy(), so this is probably > not an unlikely > combination.. They probably shouldn't use shared hardware/software structs. > 2/ initializing these volatile structures with bzero is also not > unlikely. > 3/ It probably wouldn't hurt if bzero ALWAYS had a volatile pointer > argument. > and it may remove several warnings in other drivers as well. I think only one-field-at-a-time initialization and duplication of volatile structs is right in general. Consider weird hardware that has some 32-bit registers and some 8-bit registers where it is essential to do only 32-bit accesses to the 32-bit registers and only 8-bit accesses to the 8-bit registers. > questions: > Is this hack to horrible to contemplate? Yes. > Is it a reasonable thing thing to define bzero to take a volatile > argument. This would prevent certain optimizations. Some people want to use memset() instead of bzero(). It's clear that memset() doesn't take volatile pointers (the C standard says so). We could have special versions of all copying and memory-setting functions, ones which take all combinations of volatiles and consts, but 2 versions is already too many IMO. We already have zillions of versions for bus_space. > BTW what is ovbcopy() for? is it for overlaping? Yes. It is moot in BSD, because plain BSD bcopy() handles overlapping copies, at least in userland, and it would be confusing for it to have differernt behaviour in the kernel. Thus ovbcopy is essentially just an an alternative entry point for bcopy. It was mainly used in ancient sources ... > I notice that KAME ar the major users of it, and it's defined to be the but now it is used a lot here (for portability?). > I also notice that NetBSD are (or were) having a kill > ovbcopy/bcopy/bzero effort > to replace them with memcpy and friends. I have a kill memcpy/memset effort :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: RFC: hack volatile bzero and bcopy
On Thu, 6 Sep 2001, John Baldwin wrote: > On 07-Sep-01 Julian Elischer wrote: > > > > Here is a hack to remove the 20 or so warning messages from if_ie.c No hacks please. I fixed some of these locally a few years ago without using any hacks, but gave up. if_ie.c should be rewritten to not use volatile qualifiers to a fault. > > Most of them are due to the supply of volatile pointers to bcopy and > > bzero. > > > > I do the following to produce macros that call bzero and bcopy, but > > don't produce > > warning messages when called with volatile arguments. > > > > typedef void Xcopy( void volatile *, void volatile *, int); > >#define VBCOPY(A,B,L) (*(Xcopy *)&bcopy)((A),(B),(L)) > > typedef void Xzero( void volatile *, int); > >#define VBZERO(A,L) (*(Xzero *)&bzero)((A),(L)) This just breaks the warning. > sys/cdef.h already has some rather general purpose macros for thsi sort of > thing in the form of __DEVOLATILE(), __DECONST(), and __DEQUALIFY(). These will be terminated with extreme prejudice. Making it easy to break the warnings for removing const qualifiers is bad enough, but there are cases where removing const qualifiers is not a bug. I can't think of any cases where removing volatile qualifiers is not a bug. Well, there are cases where volatile memory becomes unvolatile because you lock it while it is being accessed, but these cases are probably better handled by not declaring it as volatile. In the case of if_ie.c and bcopy(), bcopy() is not suitable for copying memory that doesn't behave like RAM. Some optimized versions of it do out of order and/or repeated copies. This might be very bad for volatile device memory. I think rewriting if_ie.c to use bus_space would make most of the warnings go away automatically. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
On Thu, Sep 06, 2001 at 08:51:44PM +0900, Kazutaka YOKOTA wrote: I don't know why, but NOW I have broken PS/2 mouse _without_ acpi module :( VAIO Z505HS. atkbdc0: at port 0x60,0x64 irq 1 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d atkbd1: unable to allocate IRQ psm0: unable to allocate IRQ > As reported in this list by several people, you may be seeing that > your PS/2 mouse is not detected after the recent ACPI update. > > This seems to be caused by ACPI in some BIOS assigns IRQ 12 (mouse > interrupt) to both the PS/2 mouse device node and the system reserved > resource node. > > To see if this is to be your case, put the following line in > /boot/device.hints and reboot. > > debug.acpi.disable="sysresource" > > If this brings your mouse back, I recommend you to keep that line > there until the proper fix is committed. > > If it doesn't solve the problem, there must be other causes ;-( > You had better contact the FreeBSD ACPI developers > ([EMAIL PROTECTED]) ML. > > Kazu > > PS: I am going to commit some update to the psm driver shortly. > But, that alone won't fix the problem. Sorry... -- bye Juriy Goloveshkin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
anoncvs.freebsd.org's disk is full?
Hi, When I try to cvs checkout via :pserver:[EMAIL PROTECTED]:/home/ncvs, I receive message as follows cannot mkdir /cvstmp/cvs-serv35384/./CVS No space left on device --- Yoichi NAKAYAMA [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
My Recommended Development/Testing environment for -current
Matt Dillon writes:
> * On my -STABLE box I build the -current world. I usually
> try to build it -DNOCLEAN but if that fails I just rebuild it from
> scratch. NOTE!!! DO NOT ACCIDENTLY TRY TO INSTALL THE -CURRENT WORLD
> ON YOUR STABLE BOX!!!
>
> stable> cd /FreeBSD/FreeBSD-current/src
> stable> make -DNOCLEAN -j 10 buildworld
>
> * On my -STABLE box I build the -current kernel. Again I try to use
> -DNOCLEAN to reduce [re]compilation times, but just build it from
> scratch too some times. NOTE!!! DO NOT ACCIDENTLY TRY TO INSTALL
> THE -CURRENT KERNEL ON YOUR STABLE BOX!!!
>
One problem - in such testing you newer see problems building world on
-CURRENT, so without below patch world not builds on my -CURRENT
--- src/gnu/usr.bin/perl/Makefile.inc.orig Thu May 31 15:04:52 2001
+++ src/gnu/usr.bin/perl/Makefile.inc Fri Sep 7 13:22:09 2001
@@ -41,7 +41,7 @@
done ;\
for i in `cd ${PERL5SRC}; find $${d} -type f | grep -v CVS` ;\
do \
- ln -s ${PERL5SRC}/$${i} $${i} ;\
+ ln -sf ${PERL5SRC}/$${i} $${i} ;\
done ;\
done
@ln -sf ${PERL5SRC}/ext/File/Glob/Glob.pm lib/File/Glob.pm
Sometime I am use a bit different scheme, on my -STABLE box I have cvsup and
source tree, it mounted through NFS to -CURRENT box read-only, and above it
mounted unionfs tree for building and changing sources.
> -Matt
--
TSB Russian Express, Moscow
Vladimir B. Grebenschikov, [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
last commit broke ps/2 mouse support on VAIO Z505HS(without acpi)
last commit broke ps/2 mouse support on my VAIO -- bye Juriy Goloveshkin Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #45: Fri Sep 7 13:00:55 MSD 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VAIO Calibrating clock(s) ... TSC clock: 496307697 Hz, i8254 clock: 1193179 Hz Timecounter "i8254" frequency 1193179 Hz CPU: Pentium III/Pentium III Xeon/Celeron (496.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x387f9ff real memory = 268369920 (262080K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x004cf000 - 0x0ffe7fff, 263294976 bytes (64281 pages) avail memory = 255967232 (249968K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f6cb0 bios32: Entry = 0xfd880 (c00fd880) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd880+0x11e pnpbios: Found PnP BIOS data at 0xc00f6ce0 pnpbios: Entry = f:b33f Rev = 1.0 pnpbios: Event flag at 400 Other BIOS signatures found: Preloaded elf kernel "kernel" at 0xc04a9000. Preloaded elf module "vesa.ko" at 0xc04a90a8. Preloaded elf module "cd9660.ko" at 0xc04a9144. Preloaded elf module "procfs.ko" at 0xc04a91e4. Preloaded elf module "if_ppp.ko" at 0xc04a9284. Preloaded elf module "if_tun.ko" at 0xc04a9324. Preloaded elf module "miibus.ko" at 0xc04a93c4. Preloaded elf module "if_fxp.ko" at 0xc04a9464. Preloaded elf module "snd_pcm.ko" at 0xc04a9504. Preloaded elf module "snd_ds1.ko" at 0xc04a95a4. Preloaded elf module "usb.ko" at 0xc04a9644. Preloaded elf module "ugen.ko" at 0xc04a96e0. Preloaded elf module "uhid.ko" at 0xc04a977c. Preloaded elf module "ukbd.ko" at 0xc04a9818. Preloaded elf module "ulpt.ko" at 0xc04a98b4. Preloaded elf module "ums.ko" at 0xc04a9950. Preloaded elf module "umass.ko" at 0xc04a99ec. Preloaded elf module "cam.ko" at 0xc04a9a8c. Preloaded elf module "uscanner.ko" at 0xc04a9b28. Preloaded elf module "agp.ko" at 0xc04a9bc8. Preloaded elf module "random.ko" at 0xc04a9c64. Preloaded elf module "atspeaker.ko" at 0xc04a9d04. null: mem: Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 02 20 01 00 01 00 00 00 00 22 00 00 01 27 00 03 02 00 01 00 01 09 01 00 01 1b 01 00 01 00 01 01 01 02 01 03 01 04 01 05 01 07 01 0d 01 0e 01 10 01 11 01 12 01 13 01 14 01 15 01 VESA: 24 mode(s) found VESA: v2.0, 2496k memory, flags:0x0, mode table:0xc0390202 (122) VESA: MagicMedia 256AV 48K VESA: NeoMagic MagicMedia 256AV 01.0 random: pci_open(1):mode 1 addr port (0x0cf8) is 0x80010014 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) Using $PIR table, 8 entries at 0xc00fdf40 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: physical bus=0 map[10]: type 3, range 32, base 4000, size 24, enabled found-> vendor=0x8086, dev=0x7190, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 found-> vendor=0x8086, dev=0x7191, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 found-> vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 map[20]: type 4, range 32, base fc90, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 map[20]: type 4, range 32, base fca0, size 5, enabled found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 intpin=d, irq=9 map[90]: type 4, range 32, base 1040, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x03 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 map[10]: type 1, range 32, base fedf7000, size 11, enabled map[14]: type 1, range 32, base fedf7c00, size 9, enabled found-> vendor=0x104d, dev=0x8039, revid=0x02 bus=0, slot=8, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 intpin=a, irq=9 powerspec 1 supports D0 D3 current D0 map[10]: type 1, range 32, base fedf8000, size 15, enabled map[14]: type 4, range 32, base fcc0, size 6, enabled map[18]: type 4, range 32, base fc8c, size 2, enabled found-> vendor=0x1073, dev=0x0010, revid=0x02 bus=0, slot=9, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 intpin=a, irq=9 powerspec 1 supports D0 D2 D3 current D0 map[10]: type 1, range 32, base fede, size 16, enabled map[14]: type 4, range 32, base fc38, size 3, enabled found-> vendor=0x14f1, dev=0x2443, revid=0x01 bus=0, slot=10, func=0 class=07-80-00, hdrtype=0x00, mfdev=0
Re: __getcwd & errno 20 (Not a directory) vfs_cache.c
In message <[EMAIL PROTECTED]>, Peter Wemm writes: >Poul-Henning Kamp wrote: >> >> You are not supposed to call __getcwd() directly. > >Yes, but it would be an excellent junior-kernel-hacker task to make it work >in all cases, ie: manually searching parent directories. netbsd does this, >as does linux, and if we're going to emulate the linux getcwd(2) syscall >then we need it. The NetBSD code is probably a good place to start for >pointers, but it wont be directly usable due to name-cache differences. I fully agree, but that was not the subject :-) -- 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
Re: KSE kernel comparissons
Peter Wemm wrote:
> For what it is worth, I am in agreement with Julian. The KSE code is at
> an ideal "checkpoint" stage, but we must not rush it and screw things up.
>
> The main reason that I would like it to be committed soon is that it
> reduces the amount of "moving target" that the KSE part of the work has to
> track. The bulk of the current changes in the current diffs are API related
> and dont really change the core structural things too much. Trying to keep
> a live branch up to date *and* implement the structural changes is a tall
> order. We saw what happened to the BSD/OS folks, they spent 2 or 3 days
> a week catching up to the current tip of tree, and only ~2 days on actual
> SMP work. If we get this checkpoint into the main tree in a timely fashion
> then we get the bulk of the tree-chasing out of the way and can implement
> ${Your_favorite_thread_frontend} at your leisure. Heck, this stuff is
> generic enough that it is required for any of the thread systems, be it
> full-blown KSE, or the NetBSD style lwp/sa, or linuxthreads style things,
> or whatever.
>
> If any committers want to get involved, there is a stale p4 quickstart
> guide at: http://people.freebsd.org/~peter/p4cookbook.txt. You can
> check out //depot/projects/kse/sys/... and review to your hearts's content.
>
> My personal check list before committing it to -current is:
> - an honest shot at getting the Alpha working. Shouldn't be too hard.
> - finish the userland build stuff.
Peter to do this we need to put the rest of FreeBSD under P4
can you do this?
I'd like to get this done asap so we can start looking at what
we've broken and start fixing it.
> - carefully reread all of the key diffs for i386/i386/*, kern/*, vm/* etc.
I've spent the last few days going through this... I found only minor nits
and one major screwup.
> - take a look at ports impact and prepare them for the landing.
I'm tempted to try fix those in retrospect..
It's been almost 2 weeks since the KSe kernel struggled to life
and I'd like to concentrate on getting it checked in.
(plus of course moving house, but then you wouldn't want life to be TOO
easy would you?)
>
> Cheers,
> -Peter
> --
> Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> "All of this is for nothing if we don't go to the stars" - JMS/B5
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +-->x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Linuxulator: possible Giant pushdown victim
Marcel Moolenaar wrote: > > BTW: Do we have handy functions for use in the remote debugger, such > as show_proc, show_vm or whatever, that dump important information > in a readable form? Matt has a cool set of macros as does Grog. -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linuxulator: possible Giant pushdown victim
On Thu, Sep 06, 2001 at 11:55:19AM -0700, John Baldwin wrote: > > > Note that 3 of these are runnable (stat of 2 == SRUN). In top, see if they are > chewing up lots of time. Top doesn't update after the first mozilla process has started. Its trace is: mi_switch() cv_timedwait_sig() select() syscall() syscall_with_err_pushed() --- syscall(93, .., select) > > db> trace 517 > > mi_switch(0,cd193aa0,811f874,cd27cfa0,c02bead6) at mi_switch+0x1a0 > > _mtx_unlock_sleep(c039e860,0,c030b460,497) at _mtx_unlock_sleep+0x204 > > syscall(2f,2f,2f,811f874,1) at syscall+0x48a > > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b > > --- syscall (514), eip = 0x285a31a7, esp = 0x811f858, ebp = 0x811f9b4 --- > > Weird syscall number (514). This one was blocked on a mutex that was just > released. I'm betting that 0xc039e860 is Giant? Perhaps not though? Rien ne va plus! It is Giant. > > db> trace 520 > > mi_switch(cd193ee0) at mi_switch+0x1a0 > > userret(cd193ee0,cd257fa8,0,208,befffc00) at userret+0x395 > > syscall(2f,2f,2f,befffd24,befffc00) at syscall+0x3c9 > > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b > > --- syscall (0, Linux ELF, nosys), eip = 0x285b8bd4, esp = 0xbefffb24, ebp = > > 0xbefffbf4 --- > > Another instance of being preempted upon return to userland. Possible that the > regs in the trapframe are altered to hold return values and thus that the > syscall number is invalid. Hmm. That certainly would explain it (see above). > What locks do all these processes hold? No locks are hold by any of the processes. The question then is: what are they waiting for? I started playing with remote debugging let me look around for a bit. BTW: Do we have handy functions for use in the remote debugger, such as show_proc, show_vm or whatever, that dump important information in a readable form? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
