Re: New Fatal trap in Current SMP (random.dev changes ??)
And the panic goes away Manfred I've got it fixed. The code is using TAILQ_REMOVE and TAILQ_FIRST to pull entries out of a tailq while it is walking it via TAILQ_FOREACH. Changing it to use a while(!TAILQ_EMPTY) instead of using TAILQ_FOREACH fixes it. I'll be committing the fix in just a sec.. Thanks, John! :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: page fault in sched_ithd
On Mon, 11 Sep 2000, Greg Lehey wrote: On Monday, 11 September 2000 at 13:18:37 +1100, Bruce Evans wrote: The stray interrupt handler needs to have a thread, or stray interrupts need to be handled as traps. Stray interrupts are more like NMIs than normal interrupts, and NMIs are already (mis)handled as traps. Independently of that, we need to be able to survive a spurious interrupt on any IRQ. Not really independent. Spurious interrupts on "any" IRQ can't happen, interrupts without a handler are masked. Spurious interrupts on irq7/irq15 can happen because normal masking by the irq7/irq15 bit in the ICU doesn't apply (I think they can happen even if all bits in the ICU mask are set). They are like an NMI in this respect. The old code accidentally had some defense against nested spurious interrupts. Masking in the ICU doesn't work, but masking in `cpl' happens to do the right thing (actually the same wrong thing as for non-nested spurious interrupts). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dirty buffers on reboot..
Bruce Evans wrote:
On Sun, 10 Sep 2000, John Baldwin wrote:
[EMAIL PROTECTED] wrote:
Ok, an update on the dirty buffers on reboot:
If you use the reboot command, you will get dirty buffers. If you use
'shutdown -r now' instead, you won't get dirty buffers. Thus, as a workaround
for now, use the shutdown command to reboot your box until we can track this
down.
I haven't noticed this yet. I normally use reboot.
It is probably a timing issue more than anything else. :-/
I suggest using some method to allow interrupt threads to run during
the shutdown. Perhaps the current process priority should be elevated
so it is guaranteed to be scheduled after the last interrupt thread
instead of some unrelated process.
I'm surprised they get stopped. At least writing buffers in sync()
depends on interrupts working. There is a problem for syncing in
panic(). Interrupts (and tsleep()) shouldn't work in panic(),
especially for panics in interrupt context. They used to sort of
work by doing splx(safepri). This corresponds to blowing open all
locks.
Hmm. By calling mi_switch() we end up giving up both shced_lock and Giant,
so that this is equivalent for the time being to "blowing open all the locks".
RCS file: /home/ncvs/src/sys/kern/kern_shutdown.c,v
retrieving revision 1.80
...
@@ -247,7 +248,18 @@
break;
printf("%d ", nbusy);
sync(proc0, NULL);
- DELAY(5 * iter);
+
+ if (curproc != NULL) {
curproc is never NULL anymore, so the if statement can be removed.
Can't it happen for panics while cold? The code "if (p p != idleproc ...)"
in uprintf() seems to be to handle this. We still have lots of (p == NULL)
checks where coldness probably isn't an issue.
H. At least on the x86, curproc is now set to proc0 before we probe
to see how much memory we have in init386(). In fact, we set curproc up
right after setting up the GDT, and before both the ldt and idt, so at least
on x86, we won't get a trap with curproc == NULL. :) On the alpha I'm not
as sure. Hmm, after looking, we set curproc in alpha_init(), but we do
it much later on. I'm not sure if we have enabled interrupts at that point
or not.
Bruce
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/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
Re: New Fatal trap in Current SMP (random.dev changes ??)
On Sun, 10 Sep 2000, John Baldwin wrote: Boris Popov wrote: Yes, after trap is occured ddb works. But it is impossible to continue from ddb because after typing 'center' machine becomes frozen. The same thing occur after any other panic (this is with SMP kernel). It only does this in cases when the sched_lock is held by the CPU that traps. If the trapping CPU does not hold sched_lock when it faults, then you can do continue and steps as normal. I _think_ that maybe having the debugger release sched_lock when it enters the debugger and acquire it on the way out would work, but I'm not sure, and I haven't explored all the interactions of that yet. ddb shouldn't (appear to) go anywhere normal locking (since it may be invoked on locking code). Similarly for the low-level console drivers. (they may be invoked by ddb or for debugging printfs or panics in locking code). Making things only appear not to go near locking code is too hard. You would have to release and reaquire not only locks, but partially-acquired locks. A special ddb lock is probably required for SMP. Booting with -d is also broken here (it hangs). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: page fault in sched_ithd
On Monday, 11 September 2000 at 17:44:43 +1100, Bruce Evans wrote: On Mon, 11 Sep 2000, Greg Lehey wrote: On Monday, 11 September 2000 at 13:18:37 +1100, Bruce Evans wrote: The stray interrupt handler needs to have a thread, or stray interrupts need to be handled as traps. Stray interrupts are more like NMIs than normal interrupts, and NMIs are already (mis)handled as traps. Independently of that, we need to be able to survive a spurious interrupt on any IRQ. Not really independent. Spurious interrupts on "any" IRQ can't happen, interrupts without a handler are masked. Right, I had forgotten that. But it's still defensive programming to DTRT if we get one, especially if it doesn't cost anything. Spurious interrupts on irq7/irq15 can happen because normal masking by the irq7/irq15 bit in the ICU doesn't apply (I think they can happen even if all bits in the ICU mask are set). They are like an NMI in this respect. Strange. Does this still happen on modern hardware? The old code accidentally had some defense against nested spurious interrupts. Masking in the ICU doesn't work, but masking in `cpl' happens to do the right thing (actually the same wrong thing as for non-nested spurious interrupts). We don't have a cpl any more. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New Fatal trap in Current SMP (random.dev changes ??)
On Sun, 10 Sep 2000, John Baldwin wrote: I've got it fixed. The code is using TAILQ_REMOVE and TAILQ_FIRST to pull entries out of a tailq while it is walking it via TAILQ_FOREACH. Changing it to use a while(!TAILQ_EMPTY) instead of using TAILQ_FOREACH fixes it. I'll be committing the fix in just a sec.. This is a good excuse for terminating the FOREACH obfuscations :). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: load average is 1 when no processes active; etc.
Just for the record, i here have a system cvsupped and built FreeBSD 5.0-CURRENT #0: Sat Sep 9 13:46:17 CEST 2000 which has a constant load average of 1.00 and higher in uptime, top, and systat. The load is already 1.00 or above when the first shell prompt after a boot appears. I've already tried to kill all processes in reach but the load never drops below 1.00 - even in single user mode. Other than this the machine is running fine. 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: make world libcrypto Undefined symbol RSA_PKCS1
On Sun, 10 Sep 2000, Mark Hittinger wrote: It may be because of something screwy that I did, I had been cvsup'ing from cvsup3. Saw the note about 3 not having a full crypto mirror so I tried a cvsup from 2 and make world completed, but when running ssh I get this: /usr/libexec/ld-elf.so.1: /usr/lib/libcrypto.so.1: Undefined symbol "RSA_PKCS1" Restoring a libcrypto.so.1 from an earlier backup gets things going again. Just blue skying for a minute here, but I wonder if it might be possible to make a short list of critical utilities that depend on some of these critical libraries. It would be quite helpful to test the libraries with the criticial utilities prior to installing them. How many times have we blown our libc.so and then we are really inconvenienced? This one is not as bad as a libc.so hose though. Every library is critical for something..the key is to not make mistakes, or to have a backup plan when you do :-) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: page fault in sched_ithd
On Mon, 11 Sep 2000, Greg Lehey wrote: On Monday, 11 September 2000 at 17:44:43 +1100, Bruce Evans wrote: On Mon, 11 Sep 2000, Greg Lehey wrote: Independently of that, we need to be able to survive a spurious interrupt on any IRQ. Not really independent. Spurious interrupts on "any" IRQ can't happen, interrupts without a handler are masked. Right, I had forgotten that. But it's still defensive programming to DTRT if we get one, especially if it doesn't cost anything. It's a waste of time to check your own args, and not free here. Spurious interrupts on irq7/irq15 can happen because normal masking by the irq7/irq15 bit in the ICU doesn't apply (I think they can happen even if all bits in the ICU mask are set). They are like an NMI in this respect. Strange. Does this still happen on modern hardware? Modern ICUs are hopefully bug for bug compatible with old ones. The old code accidentally had some defense against nested spurious interrupts. Masking in the ICU doesn't work, but masking in `cpl' happens to do the right thing (actually the same wrong thing as for non-nested spurious interrupts). We don't have a cpl any more. That's why I wrote "the old code ... had ...". Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dirty buffers on reboot..
On Sun, 10 Sep 2000, John Baldwin wrote: H. At least on the x86, curproc is now set to proc0 before we probe to see how much memory we have in init386(). In fact, we set curproc up right after setting up the GDT, and before both the ldt and idt, so at least on x86, we won't get a trap with curproc == NULL. :) On the alpha I'm not as sure. Hmm, after looking, we set curproc in alpha_init(), but we do it much later on. I'm not sure if we have enabled interrupts at that point or not. Interrupts are certainly not enabled in alpha_init() - this is the earliest part of the alpha boot sequence. After alpha_init() returns, we switch to using proc0's stack for the first time (alpha_init() runs on the bootstrap stack) and call mi_startup() to get the rest of the kernel going. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8348 3944 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: load average is 1 when no processes active; etc.
On Mon, 11 Sep 2000, Valentin Nechayev wrote:
`top -I' output:
==={
last pid: 811; load averages: 1.01, 0.97, 0.67up 0+00:16:12 23:26:26
This is because the idle process is always running (see "ps lax" outout).
Perhaps the bug is that top doesn't show the idle process or other interesting
kernel processes like the new interrupt processes.
top does nothing to determine LA except getting sysctl "vm.loadavg", isn't it?
("uptime" and "w" says the same avenrun/LA values.)
Imho, idle process should not be determined as always running,
and idle process state should be fixed.
Well, the kernel just doesn't treat it specially, so it gets counted in the
load average. I'm not sure if the interrupt and other kernel processes
are counted. Since they do useful work, they should be. The idle process
does the not so useful work of heating the cpu, since it no longer halts
or runs vm_page_zero_idle().
IP Filter: v3.4.9 initialized. Default = pass all, Logging = enabled
microuptime() went backwards (1.3891137 - 0.596214)
microuptime() went backwards (1.3891137 - 0.596655)
...
I get these at boot time on one machine but not on another very similar
machine, and often after messing around with ddb. TSC timecounter in
all cases. I think they are not a serious problem or related to old
timecounter bugs, but they may be related to old bugs setting `switchtime'.
What information of my hardware should be reported additionally?
None for this problem. It's a general problem.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
PAM in ftpd.c
I don't know around PAM coding, but below topic is there in Japanese
mailing list.
o After setting /etc/skey.access, cannot login to ftpd via UNIX
password.
There is a patch to fix this problem in that mailing list. Could
someone review and commit it?
(Submitted by: [EMAIL PROTECTED])
*** ftpd.c.orig Mon Jun 26 14:44:43 2000
--- ftpd.c Sat Sep 9 20:06:24 2000
***
*** 1109,1114
--- 1109,1126
syslog(LOG_ERR, "pam_start: %s", pam_strerror(pamh, e));
return -1;
}
+ e = pam_set_item( pamh, PAM_TTY, ttyname(0) );
+ if( e != PAM_SUCCESS )
+ {
+ syslog( LOG_ERR, "pam_set_item(PAM_TTY): %s", pam_strerror( pamh, e ) );
+ return -1;
+ }
+ e = pam_set_item( pamh, PAM_RHOST, remotehost );
+ if( e != PAM_SUCCESS )
+ {
+ syslog( LOG_ERR, "pam_set_item(PAM_RHOST): %s", pam_strerror( pamh, e ) );
+ return -1;
+ }
e = pam_authenticate(pamh, 0);
switch (e) {
--
Jun Kuriyama [EMAIL PROTECTED] // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: load average is 1 when no processes active; etc.
Bruce Evans wrote:
On Mon, 11 Sep 2000, Valentin Nechayev wrote:
`top -I' output:
==={
last pid: 811; load averages: 1.01, 0.97, 0.67up 0+00:16:12 23:26:26
This is because the idle process is always running (see "ps lax" outout).
Perhaps the bug is that top doesn't show the idle process or other interesting
kernel processes like the new interrupt processes.
top does nothing to determine LA except getting sysctl "vm.loadavg", isn't it?
("uptime" and "w" says the same avenrun/LA values.)
Imho, idle process should not be determined as always running,
and idle process state should be fixed.
Well, the kernel just doesn't treat it specially, so it gets counted in the
load average. I'm not sure if the interrupt and other kernel processes
are counted. Since they do useful work, they should be. The idle process
does the not so useful work of heating the cpu, since it no longer halts
or runs vm_page_zero_idle().
BTW, will it be fixed any time soon? Mobile users will certainly like to see idle
process
halting CPU as it was before.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fwd: [root: security check]
On Sat, 09 Sep 2000 12:25:28 EST, Steve Ames wrote: Any way this can show what actually changed? 'mount -p' (which /etc/security uses) doesn't show things such as soft-updates. In fact I don't see a single mount option that does show everything... I seem to recall that David Malone chose mount -p because mount without options displayed information about sync- and asyn-c reads and writes. Now, mount without options doesn't display this information. Therefore, I think that we can use mount without options for this check in /etc/security. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: netscape
You need to install the XFree86 a.out library package. It's not needed for the bsdi-netscape ports, because those versions of Netscape are statically linked. Most people don't need the a.out X libraries for anything else. -- Trevor Johnson http://jpj.net/~trevor/gpgkey.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM in ftpd.c
On Mon, 11 Sep 2000 18:57:45 +0900, Jun Kuriyama wrote: I don't know around PAM coding, but below topic is there in Japanese mailing list. o After setting /etc/skey.access, cannot login to ftpd via UNIX password. There is a patch to fix this problem in that mailing list. Could someone review and commit it? Could you check out PR 20333 at: http://www.freebsd.org/cgi/query-pr.cgi?pr=20333 Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: load average is 1 when no processes active; etc.
On Mon, 11 Sep 2000, Maxim Sobolev wrote:
Bruce Evans wrote:
Well, the kernel just doesn't treat it specially, so it gets counted in the
load average. I'm not sure if the interrupt and other kernel processes
are counted. Since they do useful work, they should be. The idle process
does the not so useful work of heating the cpu, since it no longer halts
or runs vm_page_zero_idle().
BTW, will it be fixed any time soon? Mobile users will certainly like to see idle
process
halting CPU as it was before.
Not sure. I use this quick fix:
---
diff -c2 kern_idle.c~ kern_idle.c
*** kern_idle.c~Thu Sep 7 12:32:51 2000
--- kern_idle.c Sun Sep 10 18:06:39 2000
***
*** 40,43
--- 50,55
#endif
+ extern void (*_hlt_vector)(void);
+
static void idle_setup(void *dummy);
SYSINIT(idle_setup, SI_SUB_SCHED_IDLE, SI_ORDER_FIRST, idle_setup, NULL)
***
*** 90,94
--- 102,116
count = 0;
+ #ifdef __i386__
+ disable_intr();
+ #endif
while (count = 0 procrunnable() == 0) {
+ #ifdef __i386__
+ if (vm_page_zero_idle() != 0)
+ continue;
+ (*_hlt_vector)();
+ disable_intr();
+ continue;
+ #endif
/*
* This is a good place to put things to be done in
***
*** 99,102
--- 121,127
" for a process");
}
+ #ifdef __i386__
+ enable_intr();
+ #endif
mtx_enter(sched_lock, MTX_SPIN);
---
Add a bogus #include of machine/md_var.h to fix a warning.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fwd: [root: security check]
I seem to recall that David Malone chose mount -p because mount without options displayed information about sync- and asyn-c reads and writes. Now, mount without options doesn't display this information. Wasn't me - I was doing seperate things with /etc/security and mount. Therefore, I think that we can use mount without options for this check in /etc/security. Sounds like a good idea - we should also consider sorting the output. On the positive side you don't get warned when you unmount and remount a filesystem and it moves to the bottom of the list. On the negative side you don't get warned when someone else unmounts and remounts a filesystem and it moves to the bottom of the list. ;-) David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel build error
... cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../i4b/driver/i4b_ctl.c cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../i4b/driver/i4b_isppp.c cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../net/if_spppsubr.c ../../net/if_spppsubr.c: In function `sppp_output': ../../net/if_spppsubr.c:755: warning: label `nosupport' defined but not used ../../net/if_spppsubr.c: In function `sppp_chap_scr': ../../net/if_spppsubr.c:3326: warning: passing arg 1 of `read_random' from incompatible pointer type ../../net/if_spppsubr.c:3326: warning: passing arg 2 of `read_random' makes pointer from integer without a cast ../../net/if_spppsubr.c:3326: too few arguments to function `read_random' *** Error code 1 Stop in /home/blaz/FreeBSD/src/sys/compile/GOLD. Seems to be related to randomdev. I have "device sppp" in my kernel config file for i4b. -current as of a couple of minutes ago. Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia E-mail: [EMAIL PROTECTED], Tel: +386-2-320-6320, Fax: +386-2-320-6325 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fwd: [root: security check]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 11 Sep 2000, David Malone wrote: Sounds like a good idea - we should also consider sorting the output. On the positive side you don't get warned when you unmount and remount a filesystem and it moves to the bottom of the list. On the negative side you don't get warned when someone else unmounts and remounts a filesystem and it moves to the bottom of the list. ;-) My $.02 would be not to sort it. I have found it very helpful a coupla times to see filesystems which were remounted appear in the daily mail. Visigoth Damieon Stark Sr. Unix Systems Administrator [EMAIL PROTECTED] PGP Public Key: www.telemere.net/~visigoth/visigoth.asc | M$ -Where do you want to go today? | Linux -Where do you want to go tomorrow?| FreeBSD - The POWER to serve Freebsd -Are you guys coming or what? | http://www.freebsd.org | | - -BEGIN PGP SIGNATURE- Version: PGP 6.5.1i iQA/AwUBObzygDnmC/+RTnGeEQKfJgCfYTJNjCVpy4VDVSOGhJ6OXlKrh4cAoJTa KdmZm9XPPQmWxJdaCk87Eh2q =X4nh -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Last build (5 hours ago)
After 5 hours the computer had totally locked itself... just a manual reboot again and doing the fsck on 46gig aint that fun :D I'll guess i'll do a new make world etc... output from top: last pid: 313; load averages: 1.03, 0.75, 0.37up 0+00:06:17 19:32:12 29 processes: 1 running, 28 sleeping CPU states: 0.0% user, 0.0% nice, 0.4% system, 0.4% interrupt, 99.2% idle After 3 minutes more the load average has locked itslef at 1.00 / 0.87 / 0.50 This seem pretty weird behaviour for a box that previously had 0.03 / 0.03 / 0.03 as an average load average... I also see a problem with the vr driver, at transfers beyond 10mbit it looks up from time to time, when i used 3.5.1-RELEASE i never had this problem, i also got higher speeds (7MB/s instead of the now 2.8MB/s) in 3.5.1-RELEASE i used wd0/wd1/wd2 instead of the ad0/ad1/ad2 but i think the ad device should be faster than the wd device shouldn't it? Anyway the vr locks up and completly fuck up _every_ session to it and leaves an "vr0: watchdog timeout" in the console every time. I have also noticed if i use the samba shares on the freebsd computer from my other windows 98 se computer i can get this too (but not as many). If i use ftp to transfer files and i use the samba network then i'm bound to get them all the time. dmesg output Copyright (c) 1992-2000 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 #8: Mon Sep 11 14:27:37 GMT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/worldclass Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 350795893 Hz CPU: AMD-K6(tm) 3D processor (350.80-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX AMD Features=0x8800SYSCALL,3DNow! real memory = 33554432 (32768K bytes) config di sn0 config di lnc0 config di le0 config di ie0 config di fe0 config di ed0 config di cs0 config di bt0 config di aic0 config di aha0 config di adv0 config q avail memory = 29614080 (28920K bytes) Preloaded elf kernel "kernel.ko" at 0xc032c000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc032c0a0. K6-family MTRR support enabled (2 registers) md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface pcib0: AcerLabs M1541 (Aladdin-V) PCI host bridge on motherboard pci0: PCI bus on pcib0 pcib1: AcerLabs M5243 PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: Intel i740 AGP SVGA controller at 0.0 irq 10 pci0: AcerLabs M5237 (Aladdin-V) USB controller at 2.0 irq 11 isab0: AcerLabs M1533 portable PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 vr0: VIA VT3043 Rhine I 10/100BaseTX port 0xdc00-0xdc7f mem 0xdfffef80-0xdfffefff irq 9 at device 14.0 on pci0 vr0: Ethernet address: 00:80:c8:f0:5f:9e miibus0: MII bus on vr0 amphy0: DM9101 10/100 media interface on miibus0 amphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci0: AcerLabs Aladdin ATA33 controller port 0xffa0-0xffaf irq 0 at device 15.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 xl0: 3Com 3c900-TPO Etherlink XL port 0xd880-0xd8bf irq 5 at device 18.0 on pci0 xl0: Ethernet address: 00:60:97:2a:29:c2 xl0: selecting 10baseT transceiver, half duplex pci0: unknown card (vendor=0x1274, dev=0x1371) at 20.0 irq 10 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/1 bytes threshold ppi0: Parallel I/O on ppbus0 plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: PNP0a03 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0f13 can't assign resources IP packet filtering initialized, divert disabled, rule-based forwarding disabled, default to deny, logging limited to 10 packets/entry by default microuptime() went backwards (1.4671896 - 1.376969) microuptime() went backwards (1.4671896 - 1.377542) ad0: 2503MB FUJITSU MPA3026ATU [5086/16/63] at ata0-master using UDMA33 microuptime() went backwards (1.4671896 -
No Subject
subscribe freebsd-current
Please review: New pkg_which version and bsd.port.mk patch.
Hi,
(Once again cross posted since -ports is the major consumer).
At http://people.freebsd.org/~reg/ there is a new patch for "pkg_which",
now implemented as two new options for pkg_info. Please review this for
style and silly things...
Also, if you download the bsd.port.mk patch from the page, you can see a
new package-depends target, and a check-plist-conflicts target.
The new package-depends target is not only about three times faster, but
it also doesn't require any Makefiles for depends (so you can just
build with the one port extracted, if you have already installed
depends). It also has the feature of registering with the correct
package (so you'll not see errors about missing +REQUIRED_BY for
ghostscript{5,55,6}). This can be used for the XFree86 3.3.6/4.0 and
for OpenMotif/LessTif, etc.
check-plist-conflicts could be inserted before pre-install to test if
you are going to overwrite files. It could also be used in reverse to
check for updates - if you have a new package (say gtk-1.2.8) and it's
PLIST conflicts with some installed port (say gtk-1.2.3), then this is a
good choice for what we want to upgrade.
Regards,
-Jeremy
--
FreeBSD - Because the best things in life are free...
http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
CVS, -STABLE and perl 5.6.0
I don't know where this discussion really belongs go, excuse the cross-post. Please be aware I'm not on either of these lists (I know it's against the doc :-), so be so kind as to cc any reply to my address. TIA. On a freshly installed 4.1 machine (bin-only installation), I CVSUPed /usr/src from RELENG_4, then removed the subtrees src/gnu/usr.bin/perl src/contrib/perl5 and last I CVSUPed the same subtrees with the tag HEAD. That should have brutally implanted perl5.6.0 in my 4.1-STABLE build tree. In that condition, buildworld fails with: === gnu/usr.bin/perl/perl Extracting config.h (with variable substitutions) Extracting cflags (with variable substitutions) Extracting writemain (with variable substitutions) Extracting myconfig (with variable substitutions) /usr/obj/usr/src/gnu/usr.bin/perl/perl/../miniperl/miniperl:No such file or directory *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/perl. Whereas (cd /usr/src/gnu/usr.bin/perl/perl; make) gave no errors, and allowed me to continue where I left with buildworld -DNOCLEAN. installworld failed too with: === gnu/usr.bin/perl/library install: /usr/libdata/perl/5.6.0/./CGI/Apache.pm: No such file or directory *** Error code 71 Stop in /usr/src/gnu/usr.bin/perl/library. which I worked around by creating /usr/libdata/perl/5.6.0 and all subdirs by hand. My question is: is there any plan to merge perl5.6.0 into RELENG_4 (it shouldn't be that difficult, as the only problem is at build/install time)? Do you have any hint for me to avoid the errors in my present case? I suppose the makefile should be changed slightly to avoid the build error, and that some entry should be added to the mtree control file to avoid the install failure: but where should I start? Thank you for any help. Angelo Turetta To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
