Re: Removing perl in make world
I think we should add a target to make world that checks for the
existence of an old base install of Perl and removes it if it exists.
I agree that we may need a tool to do this, but I don't agree that it
gets done automatically by make world.
As a general principle, if we do things like remove code during -current
development then make world needs to cater for that change. The idea of
make world is that what you get at the end of it is a pristine install
of a snapshot of FreeBSD from the current branch.
I disagree. This is force-feeding the user base too much.
The bootstrap target was originally added for this purpose, to deal with
issues during releases i.e. to bootstrap from one version of current to
another. It's got misunderstood along the way to mean bootstrapping
tools needed early in the build process.
I'd like to resurrect it's original meaning and add code to clean out
old versions of Perl.
Lots of things get deleted from current as time goes by; headers,
libraries, applets, etc. It is the responsibility of the CURRENT
builder/user to remove them as she sees fit. Our resposibility as
developers goes no further than to help provide removal tools/techniques
(I use find ${DIR} -type f -ctime +1 -delete -print), and guidance.
Of course, there are counterprecedents (libtelnet is one), but these
are the exception, and are unlikely to trample all over a user's
carefully crafted installation.
M
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ACPI woes again..
In message [EMAIL PROTECTED], Alex Zepeda wrote: On Fri, Jul 05, 2002 at 04:01:08PM +0900, Takanori Watanabe wrote: We already have a way to use your own bytecode without recompiling. Simply put your AML file to /boot/acpi_dsdt.aml and add 'acpi_dsdt_load=YES to your /boot/loader.conf (Other necessary setting exist in /boot/default/lo ader.conf) Cool! I can boot now!! When will this make it into the man page? Would you review this description? --- acpi.4 Fri Jul 5 17:41:29 2002 +++ acpi.4.new Fri Jul 5 18:37:27 2002 @@ -258,10 +258,33 @@ bus/children scan of the namespace. The ACPI CA code will still know about the avoided region. +.Sh OVERRIDING YOUR BIOS BYTECODE +ACPI interprets bytecode named AML, ACPI Machine Language, provided by BIOS +vendor as memory image at boot time. Sometimes, the AML code contains +problem that is not appeared in Microsoft implement. So we provide a way +to override it with your own AML code. +.Pp +In order to load your AML code, +you must edit +.Pa /boot/loader.conf +and +include the follwing lines. +.Bd -literal -offset indent +acpi_dsdt_load=YES +acpi_dsdt_name=/boot/acpi_dsdt.aml #You may change the name. +.Ed +.Pp +In order to prepare your AML code, you will require +.Xr acpidump 8 , +.Xr iasl 1 +in devel/acpicatools port, and some ACPI knowledge. + .Sh COMPATIBILITY ACPI is only found/supported on Intel platforms (i386/IA32 and IA64). .Sh SEE ALSO .Xr config 8 , +.Xr loader.conf 5 , +.Xr acpidump 8 , .Xr acpi 9 .Sh AUTHORS .An -nosplit To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI woes again..
On Fri, Jul 05, 2002 at 05:08:24AM -0700, Terry Lambert wrote: Takanori Watanabe wrote: +.Sh OVERRIDING YOUR BIOS BYTECODE +ACPI interprets bytecode named AML, ACPI Machine Language, provided by BIOS +vendor as memory image at boot time. Sometimes, the AML code contains +problem that is not appeared in Microsoft implement. So we provide a way +to override it with your own AML code. +.Pp How does Windows deal with hardware that has this problem? Do they use a rogues list, and replace the AML, too (only automatically)? Actually, their ACPI implementation suck, so that most of buggy AML work. For example, they don't check correctly if a they have the right to read/write to some Operational Region. If an AML declare incorrecly such regions, under FBSD (or other free OS with an ACPI-CA implementation), it can not work since the bound checking work as expected. But as a consequence, those regions can't be acceded. As an example, the status of the AC can not be reported correctly under a Satellite 3000-601 due to this kind of bug. -- Ducrot Bruno http://www.poupinou.orgPage profaissionelle http://toto.tu-me-saoules.com Haume page To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing perl in make world
On (2002/07/05 05:22), Terry Lambert wrote: This would not fit in with the rest of the world target, which doesn't clean out stale headers, stale libraries or stale binaries. Special-casing certain things will surprise people. Headers and libraries arguably should be removed, so as to avoid errors; not ports headers or libraries -- which aren't in the installation target paths in the first place -- but things like deprecated system headers, etc.. You and Paul are both pretty out there if you think -current users will graciously accept a new world order in which ports linked dymanically against system libraries won't work between a system upgrade and the next port reinstall. If you want to clean out crap left behind by `make world', just do this: make world rm -r /usr/include # Make world really should overwrite make installincludes# header files! find /bin /sbin /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/share \ -type f -mtime +1 -delete If you're just annoyed by the recent perl wobble, think about how important it is to do what Paul suggests, if it means annoying users who have very good reasons to prefer the way the `make world' upgrade method works. Then, if you still think it's important, figure out a way to do it _without_ annoying those users, as suggested by Terry. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing perl in make world
On Fri, 2002-07-05 at 16:24, Sheldon Hearn wrote: On (2002/07/05 05:22), Terry Lambert wrote: This would not fit in with the rest of the world target, which doesn't clean out stale headers, stale libraries or stale binaries. Special-casing certain things will surprise people. Headers and libraries arguably should be removed, so as to avoid errors; not ports headers or libraries -- which aren't in the installation target paths in the first place -- but things like deprecated system headers, etc.. You and Paul are both pretty out there if you think -current users will graciously accept a new world order in which ports linked dymanically against system libraries won't work between a system upgrade and the next port reinstall. I'm reluctant to suggest something that scares away -current developers, since I don't think enough people are really working on -current these days. However, if you are developing FreeBSD then you do need to make sure you're running -current and not -cruft. The old mantra of -current is for developers still holds and if the development environment becomes ineffective because people are relying on current as a work environment then maybe we should tighten the development environment so it's more suited to those people who are actually working on FreeBSD itself. On my -current box I usually rebuild ports quite regularly anyway because ports get updated pretty frequently. The only real issue with backwards compatibility is the libraries, there's nothing else that should severely impact existing installations. Libraries can easily be dealt with by just moving them to a compat dir. If you want to clean out crap left behind by `make world', just do this: make world rm -r /usr/include# Make world really should overwrite make installincludes # header files! find /bin /sbin /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/share \ -type f -mtime +1 -delete That is precisely what I do periodically (along those lines anyway), and it is often the case that when I do so I find that I've been running -cruft and not -current at all. -- Paul Richards| FreeBSD Services Ltd | Order 4.6 on DVD today! http://www.freebsd-services.com | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing perl in make world
At 11:16 AM +0100 7/5/02, Paul Richards wrote: On Fri, 2002-07-05 at 10:52, Sheldon Hearn wrote: On (2002/07/05 10:45), Paul Richards wrote: I'd like to resurrect it's original meaning and add code to clean out old versions of Perl. This would not fit in with the rest of the world target, which doesn't clean out stale headers, stale libraries or stale binaries. Special-casing certain things will surprise people. I recently cleaned out a load of stale libraries and I was quite surprised to find that what I thought was a version of current updated daily was not in fact that at all since a lot of my binaries were still linked to much older libraries so I was running a pseudo current, partly up to date and partly not. While I agree there should be some automatic way to get rid of old cruft (or at least to list it), I do not think that it should be part of installworld or installkernel. All that any such step can do is find things which it does not expect to be there, but it would have no way of knowing *why* the file is there. Maybe it's stale, *or* maybe someone build the port and explicitly pointed it at /usr instead of /usr/local. And if the process automatically removes some old library, and you have a lot of programs linked to that library, won't that be a bit disruptive? A plain installworld can be disruptive enough, without it also removing libraries that important programs might be linked to! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dump(8) is hosed
Am Mi, 2002-07-03 um 17.31 schrieb David O'Brien: On a 27-June-2002 23:02:00 UTC system (just before ipfw2 went in, pre-KSE3), dump will not complete dumping more than 5GB. At that point it stops responding properly to ^T, which should give DUMP: 47.52% done, finished in 1:19. At the 5GB mark, ^T gives: load: 0.00 cmd: dump 3981 [physstr] 2.11u 43.06s 0% 1536k and never changes. The user and system times never advance. Anybody have any ideas? For me it is broken in a different way. For a small FS like / it works, but dumping my /home, which is 4G, I get DUMP: read error from /dev/ad0s5e: Invalid argument: [sector -1054739789]: count=-1 DUMP: read error from /dev/ad0s5e: Invalid argument: [sector -1054739788]: count=-1 DUMP: read error from /dev/ad0s5e: Invalid argument: [sector -1054739787]: count=-1 DUMP: read error from /dev/ad0s5e: Invalid argument: [sector -1054739786]: count=-1 and on and on. Maybe a 32 bit -- 64 bit mismatch caused by UFS2? My -current is of date=2002.06.27.22.00.00. Using pax(1) for backup now :-( -- Regards, Georg. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recommended MP development machines...
On Thu, Jul 04, 2002 at 01:34:42PM -0400, Chuck Robey wrote: The K7 had a broken on-board usb (the AMD chipset had a PCI contention bug for the usb port, so the tin back panel of the board blocked out the usb, and the K7 came with a PCI usb card, which ate up one of your PCI slots. Hm. Do you have any details on this? I've had occasional strange USB-related things happen on this box. Of course, it runs -current which puts me into the USB danger-zone enough as it is.. but what happens when this bug is triggered? ... http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24472.pdf This is good to know. The above doc is for the AMD-768 Peripheral Bus Controller. Luckly the pre-production Thunder K7 mobos had AMD-766's in them. I don't know if Tyan switched to the 768 in later production. http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/23615.pdf In HTML format: http://www.google.com/search?q=cache:eipmgE1E_f4C:www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/23615.pdf+amd+766+revision+guidehl=enie=UTF-8 Is the revision guide for the AMD-766 south bridge. There are 2 USB nits, but nothing serious like for the AMD-768 rev B1. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dump(8) is hosed
On Fri, Jul 05, 2002 at 06:48:56PM +0200, Georg-W. Koltermann wrote: Am Mi, 2002-07-03 um 17.31 schrieb David O'Brien: On a 27-June-2002 23:02:00 UTC system (just before ipfw2 went in, pre-KSE3), dump will not complete dumping more than 5GB. At that point it stops responding properly to ^T, which should give DUMP: 47.52% done, finished in 1:19. At the 5GB mark, ^T gives: load: 0.00 cmd: dump 3981 [physstr] 2.11u 43.06s 0% 1536k and never changes. The user and system times never advance. Anybody have any ideas? For me it is broken in a different way. For a small FS like / it works, but dumping my /home, which is 4G, I get DUMP: read error from /dev/ad0s5e: Invalid argument: [sector -1054739789]: count=-1 DUMP: read error from /dev/ad0s5e: Invalid argument: [sector -1054739788]: count=-1 DUMP: read error from /dev/ad0s5e: Invalid argument: [sector -1054739787]: count=-1 DUMP: read error from /dev/ad0s5e: Invalid argument: [sector -1054739786]: count=-1 and on and on. Simular to what I get (now that I looked in /var/log/messages): kernel: ccd1: error 22 on component 2 block -431037296 (ccd block 7744633266) kernel: ccd1: error 22 on component 1 block -431037168 (ccd block 7744633266) kernel: ccd1: error 22 on component 2 block -431037168 (ccd block 7744633266) Maybe a 32 bit -- 64 bit mismatch caused by UFS2? My -current is of date=2002.06.27.22.00.00. Maybe. I'll forward this to someone that might know. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1661] Re: ASUS CUSL2 panic on acpi
On Thu, Jul 04, 2002 at 10:09:52PM +0900, Mitsuru IWASAKI wrote:
My analysis was finished. Please try this patch.
--- exfield.c-Thu Jul 4 21:54:24 2002
+++ exfield.c Thu Jul 4 21:55:02 2002
@@ -200,7 +200,7 @@
/* Handle both ACPI 1.0 and ACPI 2.0 Integer widths */
IntegerSize = sizeof (ACPI_INTEGER);
-if (WalkState-MethodNode-Flags ANOBJ_DATA_WIDTH_32)
+if (WalkState-MethodNode != NULL WalkState-MethodNode-Flags
ANOBJ_DATA_WIDTH_32)
{
/*
* We are running a method that exists in a 32-bit ACPI table.
The patch works fine, thanks.
- Christian
--
http://www.unixpages.org[EMAIL PROTECTED]
GPG Pub-Key: www.unixpages.org/cbrueffer.asc
GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185
GPG Key ID : DAD2B05D5F3C3185
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
process state problems
[ erdgeist@bauklotz:~/Coding ]
20:59:14 $ less test.c
int main( ) {
char a;
a = getchar();
return a;
}
[ erdgeist@bauklotz:~/Coding ]
20:59:19 $ ./test
^Z
[1]+ Stopped ./test
[ erdgeist@bauklotz:~/Coding ]
20:59:26 $ bg
bash: bg: bg background job?
[ erdgeist@bauklotz:~/Coding ]
20:59:27 $ uname -a
FreeBSD bauklotz.gate5.de 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Fri Jul 5 20:33:04 GMT
2002
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/bauklotz i386
[ erdgeist@bauklotz:~/Coding ]
20:59:59 $ bash --version
GNU bash, version 2.05a.0(1)-release (i386-portbld-freebsd5.0)
Copyright 2001 Free Software Foundation, Inc.
[ erdgeist@bauklotz:~/Coding ]
21:00:45 $ fg
./test
d
d
d
^C
I just made a fresh world, made a bash2
from current-ports, half an hour old
and this is, what happens.
On a 4.6 this effect does not appear.
Any suggestions?
Regards
erdgeist
-
fnord!
id 0x17B701E5 size 1024 | type rsa
11F8 8FF3 0508 09F9 DC6A 2AB3 AA67 C8CF
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: status of KSE merge
Julian Elischer wrote: At this time I have no information on any apps that fail to work (that did work before KSE). The signal flakiness is still present but at least people can get work done. I will work on this next (though signal experts are welcome to try their hand as well.. (in fact any beginners who want to jump inat the deep end of the pool can guarantee a near-drowning-experience by trying to understand signals). Some news: syscall restart after signals is broken. This is responsible for a lot of the ^Z/fg problems as well as some applications failing when their timer signals cause IO problems. Test case: peter@overcee[12:49pm]~-125 cat restart.sh #! /tmp/44sh echo -n Type something: read foo echo You typed: \$foo\ peter@overcee[12:49pm]~-126 ./restart.sh Type something: foo You typed: foo peter@overcee[12:49pm]~-127 ktrace ./restart.sh Type something: ^Z [1] + Suspended ktrace ./restart.sh peter@overcee[12:49pm]~-128 fg ktrace ./restart.sh You typed: peter@overcee[12:49pm]~-129 kdump -R [...] 1091 44sh 0.61 CALL write(0x1,0x80c4000,0x10) 1091 44sh 0.29 GIO fd 1 wrote 16 bytes Type something: 1091 44sh 0.000198 RET write 16/0x10 1091 44sh 0.000187 CALL read(0,0xbfbff2f3,0x1) 1091 44sh 3.054434 RET read -1 errno 4 Interrupted system call 1091 44sh 0.000695 CALL write(0x1,0x80c4000,0xe) 1091 44sh 0.25 GIO fd 1 wrote 14 bytes You typed: 1091 44sh 0.000254 RET write 14/0xe [..] The errno 4 - interrupted system call should not happen. read returns ERESTART internally on the signal catch, and the syscall() function in trap.c is supposed to back up the eip which causes the syscall to be rerun. I have not looked at the code yet. This is responsible for things like vipw failing after ^Z/fg (editor=vi), mergemaster failing on ^Z/fg etc. (it was mergemaster that tipped me off on this.) Applications that use interval timers would be suffering from this pretty badly. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: process state problems
this is a bug in the KSE signal handling..
peter and I are looking at it at the moemnt. it is a known problem.
On Fri, 5 Jul 2002, Dirk Engling wrote:
[ erdgeist@bauklotz:~/Coding ]
20:59:14 $ less test.c
int main( ) {
char a;
a = getchar();
return a;
}
[ erdgeist@bauklotz:~/Coding ]
20:59:19 $ ./test
^Z
[1]+ Stopped ./test
[ erdgeist@bauklotz:~/Coding ]
20:59:26 $ bg
bash: bg: bg background job?
[ erdgeist@bauklotz:~/Coding ]
20:59:27 $ uname -a
FreeBSD bauklotz.gate5.de 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Fri Jul 5 20:33:04
GMT 2002
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/bauklotz i386
[ erdgeist@bauklotz:~/Coding ]
20:59:59 $ bash --version
GNU bash, version 2.05a.0(1)-release (i386-portbld-freebsd5.0)
Copyright 2001 Free Software Foundation, Inc.
[ erdgeist@bauklotz:~/Coding ]
21:00:45 $ fg
./test
d
d
d
^C
I just made a fresh world, made a bash2
from current-ports, half an hour old
and this is, what happens.
On a 4.6 this effect does not appear.
Any suggestions?
Regards
erdgeist
-
fnord!
id 0x17B701E5 size 1024 | type rsa
11F8 8FF3 0508 09F9 DC6A 2AB3 AA67 C8CF
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: Removing perl in make world
Sheldon Hearn wrote: You and Paul are both pretty out there if you think -current users will graciously accept a new world order in which ports linked dymanically against system libraries won't work between a system upgrade and the next port reinstall. If you want to clean out crap left behind by `make world', just do this: make world rm -r /usr/include # Make world really should overwrite make installincludes# header files! find /bin /sbin /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/share \ -type f -mtime +1 -delete If you're just annoyed by the recent perl wobble, think about how important it is to do what Paul suggests, if it means annoying users who have very good reasons to prefer the way the `make world' upgrade method works. Then, if you still think it's important, figure out a way to do it _without_ annoying those users, as suggested by Terry. 1) It was Paul that suggested it. I merely stated that he had a reasonable argument, depending on his goals. 2) Right after you stopped quoting, implying that I was for the idea, I had said: | Note that this is really problematic, since there are optional | install components, such as binary backward compatability | libraries that are installed into system directories, such as | /usr/lib, that aren't technically the result of the build | process itself. | | Header files under /usr/include are pretty straight forward, as | far as that goes, though, unless they overlap components that | get installed for binary compatability (I don't think the tools | actually support building for this, though, because of crt, | manifest constant, and the a,out-ELF change). ... in other words: i. It's reasonable to want this ii. I don't think you can have this So... before you try to tar something with the Terry likes it, it must be bad brush, make sure you know which side of the issue I'm on. This time, I'm on your side. I guess that must mean you're wrong. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing perl in make world
Garance A Drosihn wrote: While I agree there should be some automatic way to get rid of old cruft (or at least to list it), I do not think that it should be part of installworld or installkernel. All that any such step can do is find things which it does not expect to be there, but it would have no way of knowing *why* the file is there. Maybe it's stale, *or* maybe someone build the port and explicitly pointed it at /usr instead of /usr/local. So, to summarize: o People with old cruft may have working -current systems that should not be working, but they can't see the problems because they have files that would not be there if they had done a fresh install. o People with old cruft may be reporting broken -current experiences (e.g. like some of the libc_r breakage recently), when *their personal system* is what is broken, because they have files that would not be there if they had done a fresh install. o Making make install remove everything which is not -current is a bad idea, because it could surprise people by moving them from the first category -- should not be working -- into the not working category. Just to play devil's advocate... Aren't the people who would be surprised in this case using -current in a way it is not intended to be used? Specifically, isn't -current there *solely* for testing, and not production work, and therefore shouldn't the *primary* purpose of -current -- testing for breakage in -current -- be the first and foremost result of running -current? -- I think that there are two contradictory assumptions in this dicussion... either you want -current to work because it's good code, or you want -current to just work, and you don't care if that doesn't mean that you can't build an identical, working system from the code in the source repository. Paul: I think the flaw in your idea is that when the source code goes from a working to a non-working condition, there would be no going back to correct the problem, short of a full reinstall or an emergency recovery disk. Others: I think the flaw in your idea is that you aren't really running -current, so why the heck aren't you just running -stable, instead of pretending to run -current? I think it comes down to this: Everyone is interested in having the most people possible running -current. Paul wants to attract new people, and Sheldon wants to not scare away old people. So back to my original suggestion (to Paul) of compromise: | I guess the best way for you to argue for this outcome is for | you to do the bsd.*.mk modifications to support your idea, and | to do all the Makfile modifications to provide the targets, | and to have it off by default. E.g. with a make installpristine or some other target. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing perl in make world
On Fri, Jul 05, 2002 at 03:33:08PM -0700, Terry Lambert wrote: Others: I think the flaw in your idea is that you aren't really running -current, so why the heck aren't you just running -stable, instead of pretending to run -current? Of course by this argument, we wouldn't be running -stable either... I agree there is a need to allow developers to clean up their systems to be as much like a clean install as possiable, but I definatly think installworld is the wrong place to do so. I'm also pretty convinced that a make target is the wrong place entierly. The problem is that if you just go nuking everything that's OBE, you will break development machines and that's unacceptable. I can't just rebuild kde on a whim, it takes 10-20 hours on my laptop (and since I last built it with gcc 2.x, it's presumably much worse now.) What would be useful to me, would be a way to list the files that are OBE so I can make a reasionable decision about removing them. Idealy, such a system would have some handy ldd scripts to tell me if libs are used or not. I think Paul's goal is fairly noble, but the suggest solution is unacceptable in my book. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg40503/pgp0.pgp Description: PGP signature
Re: Removing perl in make world
At 3:33 PM -0700 7/5/02, Terry Lambert wrote: So, to summarize: Let me summarize my own position. There are a number of files which installworld does install. After an installworld is done, there may be a number of files on a person's hard disk which were not put there by the most recent installworld. For each of those files, the issue is one of intent. 1) Is it there because the administrator explicitly wanted it to be there, for explicit reasons that may be perfectly valid even while testing the latest snapshot of current? 2) or is it left-over cruft from some previous install, and which is only getting in the way of proper testing? If you keep it that simple, instead of writing 200-line summaries of what is going on (and the possible motivations of everyone), then the solution is also simple. The above is just a slight variation from what happens with /etc config files during a new installworld. We should not have anything which automatically blows away those files. We should have an unmergemaster script, which will find those files, and **ASKS THE DEVELOPER** what they want to do for each of those files (or maybe for each set of files). No automatic process is going to be 100% right 100% of the time. Developers do not need to have installworld forcing some person's idea of what a pristine testing environment should look like. However, it would be very useful to have something which would just *tell* us what the difference is between our environment and this imaginary perfect testing environment, so we can decide what should (and what should not) be changed. While the solution may be conceptually simple, I will admit that I have no intention of working on it myself. I will therefore drop out of the debate in this thread at this time. Not that I'm upset about any of it, it's just that I don't think I have anything more to contribute. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing perl in make world
Garance A Drosihn wrote: At 3:33 PM -0700 7/5/02, Terry Lambert wrote: So, to summarize: Let me summarize my own position. I was summarizing both. It's not really necessary to summarize a position you've already taken... that's reiterating. 8-) 8-). You want a one sentence summary instead of a 200 line summary? Both sides want as many developers as possible using -current in order to advance things as quickly as possible, but they disagree on how that can be best accomplished and are too busy proving they are right to listen to each other and find a compromise. I think automatically removing perl -- or anything else that could result in a runtime error, if it were removed -- is a bad idea. It's asking make installworld to be better at component management than sysinstall upgrade. This is impossible, with the present tools for configuration management that FreeBSD has. I don't think there is *any* way you can turn a system that is a result of make installworld into the same system it would have been if you had installed a snapshot from a CDROM on a clean hard drive, and done minor system configuration. Removing old system header files is a possibility. Doing that will cause compile-time errors, but not runtime errors. If we are looking for a minimum valid set of things to remove automatically, then header files are a good candidate. Doing it, though, is a scary default, if you can't turn it off. How about leaving perl along, and starting with a proof-of-concept? Garance: Could you agree to let Paul add Makefile code *that is on by default* to zap /usr/include so that it contained only header files from the make installworld, after that command is run? Paul: Could you agree to add a knob that Garance and anyone else who is interested could set in their /etc/make.conf or somewhere else where it only has to be set once, so they could opt-out of participating in your experiment? Does this sound reasonable? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 trap code
Looking at i386/exception.s one sees: ### .globl alltraps .type alltraps,@function alltraps: pushal pushl %ds pushl %es pushl %fs alltraps_with_regs_pushed: mov $KDSEL,%ax mov %ax,%ds mov %ax,%es mov $KPSEL,%ax mov %ax,%fs FAKE_MCOUNT(13*4(%esp)) calltrap: FAKE_MCOUNT(btrap) /* init from btrap - calltrap */ calltrap /* * Return via doreti to handle ASTs. */ MEXITCOUNT jmp doreti ### but one has to look in isa/ipl.s to find: SUPERALIGN_TEXT .type doreti,@function doreti: FAKE_MCOUNT(bintr) /* init from bintr - doreti */ doreti_next: /* * Check if ASTs can be handled now. PSL_VM must be checked first * since segment registers only have an RPL in non-VM86 mode. */ testl $PSL_VM,TF_EFLAGS(%esp) /* are we in vm86 mode? */ jz doreti_notvm86 cmpl$1,in_vm86call /* are we in a vm86 call? */ jne doreti_ast /* can handle ASTs now if not */ jmp doreti_exit doreti_notvm86: testb $SEL_RPL_MASK,TF_CS(%esp) /* are we in user mode? */ jz doreti_exit /* can't handle ASTs now if not */ doreti_ast: /* * Check for ASTs atomically with returning. Disabling CPU * interrupts provides sufficient locking evein the SMP case, * since we will be informed of any new ASTs by an IPI. */ cli movlPCPU(CURTHREAD),%eax movlTD_KSE(%eax), %eax testl $KEF_ASTPENDING | KEF_NEEDRESCHED,KE_FLAGS(%eax) je doreti_exit sti pushl %esp/* pass a pointer to the trapframe */ callast add $4,%esp jmp doreti_ast /* * doreti_exit: pop registers, iret. * * The segment register pop is a special case, since it may * fault if (for example) a sigreturn specifies bad segment * registers. The fault is handled in trap.c. */ doreti_exit: MEXITCOUNT .globl doreti_popl_fs doreti_popl_fs: popl%fs .globl doreti_popl_es doreti_popl_es: popl%es .globl doreti_popl_ds doreti_popl_ds: popl%ds popal addl$8,%esp .globl doreti_iret doreti_iret: iret Now: would it not make a lot of sense to put doreti immediatly after calltrap: in the same file so that one could follow the entire picture without having to bounce back and forth between two files? (also gets rid of the jmp in the common case) Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 trap code
Apparently, On Fri, Jul 05, 2002 at 05:43:26PM -0700, Julian Elischer said words to the effect of; Looking at i386/exception.s one sees: [...] Now: would it not make a lot of sense to put doreti immediatly after calltrap: in the same file so that one could follow the entire picture without having to bounce back and forth between two files? I'd say so, yeah. Its probably there because it used to be alongside splz and unmasked pending isa interrupts. (also gets rid of the jmp in the common case) System calls are probably the common case. But I'd suggest just put it after the trap code at the end of the file and leave the jump. Its super aligned so there would probably be a bunch of nops to plow through anyway. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing perl in make world
On Sat, 2002-07-06 at 01:07, Garance A Drosihn wrote: At 3:33 PM -0700 7/5/02, Terry Lambert wrote: So, to summarize: Let me summarize my own position. There are a number of files which installworld does install. After an installworld is done, there may be a number of files on a person's hard disk which were not put there by the most recent installworld. For each of those files, the issue is one of intent. 1) Is it there because the administrator explicitly wanted it to be there, for explicit reasons that may be perfectly valid even while testing the latest snapshot of current? 2) or is it left-over cruft from some previous install, and which is only getting in the way of proper testing? If you keep it that simple, instead of writing 200-line summaries of what is going on (and the possible motivations of everyone), then the solution is also simple. The above is just a slight variation from what happens with /etc config files during a new installworld. We should not have anything which automatically blows away those files. We should have an unmergemaster script, which will find those files, and **ASKS THE DEVELOPER** what they want to do for each of those files (or maybe for each set of files). No automatic process is going to be 100% right 100% of the time. I think a -current system is something that should be assumed to be a semi-known environment though. Let's start with a premise: No-one running current is using it for anything other than developing FreeBSD. Given that premise, then there shouldn't be anything in /usr outside of /usr/local, that wasn't put there by make world. Likewise the same should be true of /sbin and /bin. Therefore running, find $listofdirs -newermt $date -delete should be perfectly OK since it's only going to clear out old files that are no longer part of FreeBSD (where $listofdirs is directories that should not be touched other than by make world, and $date is the date of the last install). The only tweak that is necessary is in the case of /usr/lib, where files should be moved to a compat dir and not deleted. I do this periodically on my dev box and it does show up issues. I think it's something we should build into our infrastructure as a step towards a better known environment for testing -current. -- Paul Richards | FreeBSD Services Ltd| Order 4.6 on DVD now. http://www.freebsd-services.com | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About DEVFS (was: Re: About GEOM...)
÷ Fri, 05.07.2002, × 06:39, Terry Lambert ÎÁÐÉÓÁÌ: Loader? ie on shutdown write a list of permissions etc into a file which the loader can slurp up next boot and shove into the kernel and be parsed. This really doesn't work very well. You end up with two sets of data. Having done something like this in practice, and had to live with the aftermath, I don't recommend it (at all). May be same mechanism as hints, like: hint.sio.0.mode=0622 why not ? Symantic very similar (there are some kernel-hardcoded values and some loader-supplied) But overall, it seems to be a move forward. agree. -- Terry -- Vladimir B. Grebenschikov [EMAIL PROTECTED], SWsoft, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd login problem
On Fri, Jul 05, 2002 at 03:29:13PM +0200, Dag-Erling Smorgrav wrote: Bernd Walter [EMAIL PROTECTED] writes: cicely10 is an alpha running -current from 3. Jul. The kernel is a day younger. What does 'ident /usr/sbin/sshd | grep monitor' say? [51]cicely10 ident /usr/sbin/sshd | grep monitor $OpenBSD: monitor_mm.c,v 1.6 2002/06/04 23:05:49 markus Exp $ $OpenBSD: monitor.c,v 1.18 2002/06/26 13:20:57 deraadt Exp $ $FreeBSD: src/crypto/openssh/monitor.c,v 1.7 2002/07/02 13:07:17 des Exp $ -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd login problem
Bernd Walter [EMAIL PROTECTED] writes: cicely10 is an alpha running -current from 3. Jul. The kernel is a day younger. What does 'ident /usr/sbin/sshd | grep monitor' say? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About DEVFS (was: Re: About GEOM...)
On 5 Jul 2002, Vladimir B. Grebenschikov wrote: May be same mechanism as hints, like: hint.sio.0.mode=0622 As long as we are throwing out ideas: Aside from the fact that it's broken and at the moment wouldn't exactly DTRT, I always figured a type of mount_unionfs() with the older filesystem /dev as the upper layer and devfs as the lower layer would be the way to go. -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing perl in make world
On Fri, Jul 05, 2002 at 11:29:30AM +0100, Mark Murray wrote: I think we should add a target to make world that checks for the existence of an old base install of Perl and removes it if it exists. I agree that we may need a tool to do this, but I don't agree that it gets done automatically by make world. Could we also make this tool mv /usr/include /usr/include.old so that it could be run before an installworld? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: status of KSE merge
the following patch can fix the bug, but for KSE programs, it may not be a
best solution, KSE programs signal handling is on going...
--- kern_synch.cWed Jul 3 17:15:20 2002
+++ kern_synch.c.newSat Jul 6 10:36:22 2002
@@ -537,8 +537,7 @@
PROC_LOCK(p);
sig = cursig(td);
if (thread_suspend_check(1)) {
- sig = EINTR;
- rval = EINTR;
+ sig = SIGSTOP;
}
mtx_lock_spin(sched_lock);
PROC_UNLOCK(p);
-David Xu
- Original Message -
From: Peter Wemm [EMAIL PROTECTED]
To: Julian Elischer [EMAIL PROTECTED]
Cc: FreeBSD current users [EMAIL PROTECTED]
Sent: Saturday, July 06, 2002 3:52 AM
Subject: Re: status of KSE merge
Julian Elischer wrote:
At this time I have no information on any apps that fail to work (that did
work before KSE).
The signal flakiness is still present but at least people can get work
done. I will work on this next (though signal experts are welcome to
try their hand as well.. (in fact any beginners who want to jump inat the
deep end of the pool can guarantee a near-drowning-experience by trying
to understand signals).
Some news: syscall restart after signals is broken. This is responsible
for a lot of the ^Z/fg problems as well as some applications failing when
their timer signals cause IO problems.
Test case:
peter@overcee[12:49pm]~-125 cat restart.sh
#! /tmp/44sh
echo -n Type something:
read foo
echo You typed: \$foo\
peter@overcee[12:49pm]~-126 ./restart.sh
Type something: foo
You typed: foo
peter@overcee[12:49pm]~-127 ktrace ./restart.sh
Type something: ^Z
[1] + Suspended ktrace ./restart.sh
peter@overcee[12:49pm]~-128 fg
ktrace ./restart.sh
You typed:
peter@overcee[12:49pm]~-129 kdump -R
[...]
1091 44sh 0.61 CALL write(0x1,0x80c4000,0x10)
1091 44sh 0.29 GIO fd 1 wrote 16 bytes
Type something:
1091 44sh 0.000198 RET write 16/0x10
1091 44sh 0.000187 CALL read(0,0xbfbff2f3,0x1)
1091 44sh 3.054434 RET read -1 errno 4 Interrupted system call
1091 44sh 0.000695 CALL write(0x1,0x80c4000,0xe)
1091 44sh 0.25 GIO fd 1 wrote 14 bytes
You typed:
1091 44sh 0.000254 RET write 14/0xe
[..]
The errno 4 - interrupted system call should not happen. read returns
ERESTART internally on the signal catch, and the syscall() function in trap.c
is supposed to back up the eip which causes the syscall to be rerun.
I have not looked at the code yet. This is responsible for things like
vipw failing after ^Z/fg (editor=vi), mergemaster failing on ^Z/fg etc.
(it was mergemaster that tipped me off on this.)
Applications that use interval timers would be suffering from this pretty
badly.
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
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Removing perl in make world
At 3:05 AM +0100 7/6/02, Paul Richards wrote: Let's start with a premise: No-one running current is using it for anything other than developing FreeBSD. This is assumption is too limiting. People running -current are doing it to test the latest builds. What they *do* to test it is their business. Ie, if I want to install some port in /usr instead of /usr/local, that is something I should be able to do. Given that premise, then there shouldn't be anything in /usr outside of usr/local, that wasn't put there by make world. Likewise the same should be true of /sbin and /bin. Therefore running, find $listofdirs -newermt $date -delete should be perfectly OK since it's only going to clear out old files that are no longer part of FreeBSD Wrong. It will delete files which were not installed by the FreeBSD install process, but that is *not* necessarily the same thing as old files. The fact that installworld did not install the file does not mean that *I* do not want that file to be right where it is. How you test your -current system is your own business. There should be no command as part of 'installworld' which assumes how I am going to test my system, or what things I am testing on my system. No blind 'find' command should be automatically deleting any files on my system. The perplexing part of this debate is that I do see what problem you are trying to solve, and I *do* think it would be valuable to address that issue. I do not see what is so perplexing about having a separate script, just like mergemaster, which a person could run WHEN THEY WANT TO, and which would *LIST* what files are in their system that would not be in a pristine install of -current. It could even go thru, just like mergemaster, and ask What do you want to do about this file? (Remove, LeaveIt). People reporting a problem could even be told to run this script, so any other person who is debugging that problem can realize exactly what is different about the first person's system. I can see that someone might say Ah, you have some old perl installed, and therefore I will ignore your bug report for now. What would be the PROBLEM with THAT solution? Please answer that question, instead of just reinterating how you would like to add find command which will blindly delete files from the system of every developer who is on current. If 'installworld' starts erasing files on me, then I am going to have to reserve a larger block of time to cvsup/buildworld. I will react to that by building world less often, and that isn't going to help any wish for valuable debugging. As it is, I have spent more than 60 hours in the last month just trying to do a buildworld of current, only to be foiled by one problem or another. (nothing dramatic, it's mainly been a matter of picking the wrong times to cvsup...). And here I am on a friday night, doing a new buildworld while running a -current system from April 23rd, because all of those attempts have failed. 60 hours of my free time in the past month with not a damn thing to show for it, and you're going to make installworlds on -current even more of a hassle. Pardon me if I don't signup for it. I will simply drop back to using stable and I won't bother to help out one bit with testing -current. If you think that -current needs FEWER people trying to run it, then feel free to screw up the installworld target. That's just my 2 cents worth. I see the problem you're trying to address, and if most developers of -current see this as a major problem, then maybe it's better to solve the problem and drive away a few other developers. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
- Original Message - From: Julian Elischer [EMAIL PROTECTED] To: Peter Wemm [EMAIL PROTECTED] Cc: FreeBSD current users [EMAIL PROTECTED] Sent: Saturday, July 06, 2002 8:43 AM Subject: i386 trap code Looking at i386/exception.s one sees: ### .globl alltraps .type alltraps,@function alltraps: pushal pushl %ds pushl %es pushl %fs alltraps_with_regs_pushed: mov $KDSEL,%ax mov %ax,%ds mov %ax,%es mov $KPSEL,%ax mov %ax,%fs FAKE_MCOUNT(13*4(%esp)) calltrap: FAKE_MCOUNT(btrap) /* init from btrap - calltrap */ calltrap /* * Return via doreti to handle ASTs. */ MEXITCOUNT jmp doreti ### but one has to look in isa/ipl.s to find: SUPERALIGN_TEXT .type doreti,@function doreti: FAKE_MCOUNT(bintr) /* init from bintr - doreti */ doreti_next: /* * Check if ASTs can be handled now. PSL_VM must be checked first * since segment registers only have an RPL in non-VM86 mode. */ testl $PSL_VM,TF_EFLAGS(%esp) /* are we in vm86 mode? */ jz doreti_notvm86 cmpl$1,in_vm86call /* are we in a vm86 call? */ sorry for a bit OT, does anyone see this in_vm86call crazy global variable? it prevents two CPUs to trap into VM86 model :( if you have interest in fixing this problem, please have a look at PR : http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/38223 I have also fixed the problem that VM86 call is preempted by interrupt threads and causes system crash. newest patch can always be gotten from : http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz -David Xu __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 trap code
- Original Message - From: Julian Elischer [EMAIL PROTECTED] To: Peter Wemm [EMAIL PROTECTED] Cc: FreeBSD current users [EMAIL PROTECTED] Sent: Saturday, July 06, 2002 8:43 AM Subject: i386 trap code Looking at i386/exception.s one sees: ### .globl alltraps .type alltraps,@function alltraps: pushal pushl %ds pushl %es pushl %fs alltraps_with_regs_pushed: mov $KDSEL,%ax mov %ax,%ds mov %ax,%es mov $KPSEL,%ax mov %ax,%fs FAKE_MCOUNT(13*4(%esp)) calltrap: FAKE_MCOUNT(btrap) /* init from btrap - calltrap */ calltrap /* * Return via doreti to handle ASTs. */ MEXITCOUNT jmp doreti ### but one has to look in isa/ipl.s to find: SUPERALIGN_TEXT .type doreti,@function doreti: FAKE_MCOUNT(bintr) /* init from bintr - doreti */ doreti_next: /* * Check if ASTs can be handled now. PSL_VM must be checked first * since segment registers only have an RPL in non-VM86 mode. */ testl $PSL_VM,TF_EFLAGS(%esp) /* are we in vm86 mode? */ jz doreti_notvm86 cmpl$1,in_vm86call /* are we in a vm86 call? */ sorry for a bit OT, does anyone see this in_vm86call crazy global variable? it prevents two CPUs to trap into VM86 model :( if you have interest in fixing this problem, please have a look at PR : http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/38223 I have also fixed the problem that VM86 call is preempted by interrupt threads and causes system crash. newest patch can always be gotten from : http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz -David Xu __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing perl in make world
NetBSD has a mtree.obsolete. Seems like that might not be a bad way to solve this generically. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic broken on alpha or scsi or up
Hi Julian, When I panic an alpha these days, I end up with the random_kthread spinning on the cpu stuck in msleep, and I never get the disks sync'ed (or, if I disable sync'ing, I never get through a dump): panic: vm_page_wakeup: page not busy!!! panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 db c syncing disks... 3 3 hang, break into debugger Stopped at siointr1+0x198: br zero,siointr1+0x330 zero=0x0 db tr siointr1() at siointr1+0x198 siointr() at siointr+0x40 isa_handle_fast_intr() at isa_handle_fast_intr+0x24 alpha_dispatch_intr() at alpha_dispatch_intr+0xd0 interrupt() at interrupt+0x110 XentInt() at XentInt+0x28 --- interrupt (from ipl 0) --- msleep() at msleep+0x20 random_kthread() at random_kthread+0xb4 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- db c wait some more, get a coke, break into debugger again Stopped at siointr1+0x198: br zero,siointr1+0x330 zero=0x0 db where No such command db tr siointr1() at siointr1+0x198 siointr() at siointr+0x40 isa_handle_fast_intr() at isa_handle_fast_intr+0x24 alpha_dispatch_intr() at alpha_dispatch_intr+0xd0 interrupt() at interrupt+0x110 XentInt() at XentInt+0x28 --- interrupt (from ipl 0) --- critical_exit() at critical_exit+0x20 _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0x94 msleep() at msleep+0x290 random_kthread() at random_kthread+0xb4 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- db reboot If I disable the randomness thing, I end up getting stuck in another kernel process: db tr siointr1() at siointr1+0x198 siointr() at siointr+0x40 isa_handle_fast_intr() at isa_handle_fast_intr+0x24 alpha_dispatch_intr() at alpha_dispatch_intr+0xd0 interrupt() at interrupt+0x110 XentInt() at XentInt+0x28 --- interrupt (from ipl 0) --- critical_exit() at critical_exit+0x20 _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0x94 msleep() at msleep+0x290 buf_daemon() at buf_daemon+0x1f4 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- I don't have this problem on my x86 testbox, but it has an IDE disk and is SMP. The alpha with the problem is UP, and uses a SCSI disk (isp controller). Any ideas? Are people able to get crashdumps on UP SCSI x86s? Thanks, Drew PS: I was going to make the subject can't take a dump, but I thought the better of it ;) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI woes again..
On Fri, Jul 05, 2002 at 06:46:05PM +0900, Takanori Watanabe wrote: Would you review this description? How about: --- acpi.4.orig Thu Jun 13 02:50:06 2002 +++ acpi.4 Fri Jul 5 21:16:59 2002 @@ -258,10 +258,35 @@ bus/children scan of the namespace. The ACPI CA code will still know about the avoided region. +.Sh OVERRIDING YOUR BIOS BYTECODE +ACPI interprets bytecode named AML, ACPI Machine Language, provided by BIOS +vendor as memory image at boot time. Sometimes, the AML code contains +incorrect bytecode that does not wreak havoc with the Microsoft implementations +of ACPI. Such bugs can often times prevent FreeBSD from booting. In case of +such issues, we provide a way to override buggy AML with your own AML +code. +.Pp +In order to load your AML code, +you must edit +.Pa /boot/loader.conf +and +include the follwing lines. +.Bd -literal -offset indent +acpi_dsdt_load=YES +acpi_dsdt_name=/boot/acpi_dsdt.aml #You may change the name. +.Ed +.Pp +In order to prepare your AML code, you will require +.Xr acpidump 8 , +.Xr iasl 1 +in devel/acpicatools port, and some ACPI knowledge. + .Sh COMPATIBILITY ACPI is only found/supported on Intel platforms (i386/IA32 and IA64). .Sh SEE ALSO .Xr config 8 , +.Xr loader.conf 5 , +.Xr acpidump 8 , .Xr acpi 9 .Sh AUTHORS .An -nosplit - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic broken on alpha or scsi or up
Steve Kargl writes: On Fri, Jul 05, 2002 at 11:43:59PM -0400, Andrew Gallatin wrote: Any ideas? Are people able to get crashdumps on UP SCSI x86s? Yes. I can get dumps on an ahc (adaptec 2940) on a UP x86 box. Kernel was built with July 4th current sources. OK, thanks.. It must be alpha specific then. Thanks! Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
more on dumping
OK, current is really confusing me. When we are panic'ing and syncing disks, how are we supposed to come back to the current thread which caused the dump after we do an mi_switch() to allow an interrupt thread to run? The alpha seems to get stuck running various sorts of kernel processes, but it never comes back to the one that caused the dump. How is this supposed to work? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing perl in make world
On 6 Jul, Paul Richards wrote: Let's start with a premise: No-one running current is using it for anything other than developing FreeBSD. Given that premise, then there shouldn't be anything in /usr outside of /usr/local, that wasn't put there by make world. Likewise the same should be true of /sbin and /bin. The X11 ports install stuff under /usr/X11R6 ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 trap code
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: sorry for a bit OT, does anyone see this in_vm86call crazy global variable? it prevents two CPUs to trap into VM86 model :( Um, unfortunately, this is by design. Most (all?) BIOSen code are single threaded, and the vm86 code shares the entire ISA hole, including the read/write BIOS data area. Allowing more than one CPU to execute BIOS code at once is asking for trouble, since there is no way to know what memory locations are being shared. Now that vm86_lock serves the same function, we could check that lock instead of of the global flag. I have also fixed the problem that VM86 call is preempted by interrupt threads and causes system crash. newest patch can always be gotten from : http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz I haven't looked at vm86 for a long time, but the original code worked by preventing any ASTs from being taken until the BIOS returned. It's likely that this needs to be reworked for -current. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more on dumping
On Sat, 6 Jul 2002, Andrew Gallatin wrote: OK, current is really confusing me. When we are panic'ing and syncing disks, how are we supposed to come back to the current thread which caused the dump after we do an mi_switch() to allow an interrupt thread to run? It depends. the previous thread should have been put back onto the run queue before the interrupt thread was scheduled. The alpha seems to get stuck running various sorts of kernel processes, but it never comes back to the one that caused the dump. How is this supposed to work? Thanks, Drew 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: panic broken on alpha or scsi or up
put a breakpoint at msleep+0x290 then continue.. sprinkle a few breakpoints at locations you think other processes ahould be hitting if they were to be running.. On Fri, 5 Jul 2002, Andrew Gallatin wrote: Hi Julian, When I panic an alpha these days, I end up with the random_kthread spinning on the cpu stuck in msleep, and I never get the disks sync'ed (or, if I disable sync'ing, I never get through a dump): panic: vm_page_wakeup: page not busy!!! panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 db c syncing disks... 3 3 hang, break into debugger Stopped at siointr1+0x198: br zero,siointr1+0x330 zero=0x0 db tr siointr1() at siointr1+0x198 siointr() at siointr+0x40 isa_handle_fast_intr() at isa_handle_fast_intr+0x24 alpha_dispatch_intr() at alpha_dispatch_intr+0xd0 interrupt() at interrupt+0x110 XentInt() at XentInt+0x28 --- interrupt (from ipl 0) --- msleep() at msleep+0x20 random_kthread() at random_kthread+0xb4 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- db c wait some more, get a coke, break into debugger again Stopped at siointr1+0x198: br zero,siointr1+0x330 zero=0x0 db where No such command db tr siointr1() at siointr1+0x198 siointr() at siointr+0x40 isa_handle_fast_intr() at isa_handle_fast_intr+0x24 alpha_dispatch_intr() at alpha_dispatch_intr+0xd0 interrupt() at interrupt+0x110 XentInt() at XentInt+0x28 --- interrupt (from ipl 0) --- critical_exit() at critical_exit+0x20 _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0x94 msleep() at msleep+0x290 random_kthread() at random_kthread+0xb4 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- db reboot If I disable the randomness thing, I end up getting stuck in another kernel process: db tr siointr1() at siointr1+0x198 siointr() at siointr+0x40 isa_handle_fast_intr() at isa_handle_fast_intr+0x24 alpha_dispatch_intr() at alpha_dispatch_intr+0xd0 interrupt() at interrupt+0x110 XentInt() at XentInt+0x28 --- interrupt (from ipl 0) --- critical_exit() at critical_exit+0x20 _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0x94 msleep() at msleep+0x290 buf_daemon() at buf_daemon+0x1f4 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- I don't have this problem on my x86 testbox, but it has an IDE disk and is SMP. The alpha with the problem is UP, and uses a SCSI disk (isp controller). Any ideas? Are people able to get crashdumps on UP SCSI x86s? Thanks, Drew PS: I was going to make the subject can't take a dump, but I thought the better of it ;) 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
