Re: devfs question
On Sat, 27 Oct 2001, Poul-Henning Kamp wrote: Oops, error on my part; /proc does need to exist. So, I guess the question is this: Can devfs's error handling in the case of /dev being non-existant be improved? Barely, because without /dev, how do you plan to open the console ? Mkdir(/dev) isn't an option because the rootfs is mounted R/O. About the only thing one could do is make init exit(bla) and get a diagnostic from the kernel. It may make sense to do that. An error message would be sufficient; my concern was that someone might run into this and spend hours trying to figure out which of X variables was the problem. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs question
In message [EMAIL PROTECTED], Mike Silbersack w rites: On Sat, 27 Oct 2001, Poul-Henning Kamp wrote: Oops, error on my part; /proc does need to exist. So, I guess the question is this: Can devfs's error handling in the case of /dev being non-existant be improved? Barely, because without /dev, how do you plan to open the console ? Mkdir(/dev) isn't an option because the rootfs is mounted R/O. About the only thing one could do is make init exit(bla) and get a diagnostic from the kernel. It may make sense to do that. An error message would be sufficient; my concern was that someone might run into this and spend hours trying to figure out which of X variables was the problem. Right, but the only way to get an error message is to let /sbin/init die and have the kernel print the message. /sbin/init cannot print the message when there is no /dev/console can it ? -- 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: devfs question
On Sat, 27 Oct 2001, Poul-Henning Kamp wrote: An error message would be sufficient; my concern was that someone might run into this and spend hours trying to figure out which of X variables was the problem. Right, but the only way to get an error message is to let /sbin/init die and have the kernel print the message. /sbin/init cannot print the message when there is no /dev/console can it ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 I'm in over my head on this one; I really don't know anything about the boot process. Having init die if there's no /dev sounds acceptable to me. After all, if there's no /dev, the system looks like it's in trouble. (If this does not make sense, reference above paragraph.) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT freeze under high load
On Fri, Oct 26, 2001 at 06:30:47PM +0100, David Malone wrote: Anyway, both ways I can trigger the bug (find . -type f | xargs mutt, and actually running fetchmail -a) do generate a LOT of work, so it's actually possible that your diagnosis (mbuf exhaustion) is correct; trouble is, this shouln't hurt the machine to the point I can't even enter DDB. Maybe I'll try installing qmail at home and reproducing the problem. I've installed qmail and managed to reproduce the problem. I've also managed to get a trace using a serial console and it was stuck in something like unp_scan after closing a pipe. I've got a fair idea of where the problem is now, so I should be able to track it down. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
XFmail and libc.so.3
To upgrade from xfree-3 to xfree-4 I removed all my installed ports but I lost mail program (I use XFMail, sorry for this :-) It compile and install fine but crashes with this message: The application crashed due to fatal error All unfinished messages were saved _: Report the bug with all the relevant information using the Bug report facility Missing or failed fl_initialize()--Invalid argument I tryed demos from xform and they works, so I examied source of xfmail and discovered that is use libc.so.3, seems that xforms crashes with original libc.so.3 and works with libc.so.5 I installed compat3x from ports and recompiled world three times (sigh) also with recent cvsup (last update this morning, GMT+1) with COMPAT3X=yes and COMPAT4X=yes in /etc/make.conf but it crashes the same. Finally I tryed this (HACK?) and it works for me. -8-[ before ]-8- # ldconfig -r | grep libc.so 33:-lc.5 = /usr/lib/libc.so.5 67:-lc.3 = /usr/lib/compat/libc.so.3 89:-lc.4 = /usr/lib/compat/libc.so.4 -8-[ hack ]-8- # cd /usr/lib # mv compat/libc.so.3 compat/libc.so.3-NO_THANKS # ln -s libc.so libc.so.3 -8-[ after ]-8- # ldconfig -r | grep libc.so 33:-lc.5 = /usr/lib/libc.so.5 66:-lc.3 = /usr/lib/libc.so.3 89:-lc.4 = /usr/lib/compat/libc.so.4 And now XFMail works :-) This is my first message after a week of blackout... Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT freeze under high load
On Fri, Oct 26, 2001 at 06:16:12PM +0200, Andrea Campi wrote:
Anybody has any idea how to properly fix?
Can you test the following patch?
David.
Index: uipc_usrreq.c
===
RCS file: /cvs/FreeBSD-CVS/src/sys/kern/uipc_usrreq.c,v
retrieving revision 1.74
diff -u -r1.74 uipc_usrreq.c
--- uipc_usrreq.c 9 Oct 2001 21:40:30 - 1.74
+++ uipc_usrreq.c 27 Oct 2001 18:30:56 -
@@ -1420,7 +1420,7 @@
while (m0) {
for (m = m0; m; m = m-m_next) {
- if (m-m_type == MT_CONTROL)
+ if (m-m_type != MT_CONTROL)
continue;
cm = mtod(m, struct cmsghdr *);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
kernel panic in getnewvnode
Kernel is from 20 Oct 2001 sources. I was running cvsup grabbing the latest sources into a clean /usr/src directory. Softupdate were enabled and vfs.vmiodirenable=1. -- Steve GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd... (no debugging symbols found)... IdlePTD 3719168 initial pcb at 296180 panicstr: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xac fault code = supervisor read, page not present instruction pointer = 0x8:0xc01b1959 stack pointer = 0x10:0xcea28924 frame pointer = 0x10:0xcea28948 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 = 461 (cvsup) panic: from debugger panic: from debugger Uptime: 26m27s (kgdb) bt #0 0xc017ce82 in dumpsys () #1 0xc017cc6f in boot () #2 0xc017d0a1 in panic () #3 0xc01307e1 in db_panic () #4 0xc013077f in db_command () #5 0xc013084b in db_command_loop () #6 0xc0132ae3 in db_trap () #7 0xc0212c4e in kdb_trap () #8 0xc021f5dc in trap_fatal () #9 0xc021f349 in trap_pfault () #10 0xc021eeec in trap () #11 0xc01b1959 in getnewvnode () #12 0xc01e8396 in ffs_vget () #13 0xc01d9dc1 in ffs_valloc () #14 0xc01ef56e in ufs_makeinode () #15 0xc01ece10 in ufs_create () #16 0xc01ef8d5 in ufs_vnoperate () #17 0xc01bab03 in vn_open () #17 0xc01bab03 in vn_open () #18 0xc01b60a2 in open () #19 0xc021f94f in syscall () #20 0xc0213cbd in syscall_with_err_pushed () #21 0x80a88b2 in ?? () #22 0x805f606 in ?? () #23 0x805cb7b in ?? () #24 0x805b8a4 in ?? () #25 0x805b443 in ?? () #26 0x80cf48d in ?? () #27 0x80cf346 in ?? () #28 0x80c6f70 in ?? () #29 0xe77efb39 in ?? () To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
hmm... (fwd)
Actually- not alpha. Happened under i386, so it seems like it might be more related to the general console changes.. -- Forwarded message -- Date: Sat, 27 Oct 2001 16:43:55 -0700 (PDT) From: Matthew Jacob [EMAIL PROTECTED] To: Jonathan Lemon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: hmm... Something from your changes or mine :-)? On a reboot: login: fatal kernel trap: trap entry = 0x2 (memory management fault) cpuid = 0 faulting va= 0xb8 type = access violation cause = load instructon pc = 0xfc3fd1d4 ra = 0xfc456720 sp = 0xfe000b4377f0 usp= 0x11ffe680 curproc= 0xfe000b1afe00 pid = 216, comm = syslogd Stopped at devsw+0x14: ldq t0,0xb8(a0) 0xb8 t0=0xfe000b17ec40,a0=0x0 db t devsw() at devsw+0x14 cn_devopen() at cn_devopen+0x40 cnopen() at cnopen+0x60 spec_open() at spec_open+0x1b4 spec_vnoperate() at spec_vnoperate+0x2c vn_open() at vn_open+0x410 open() at open+0xf0 syscall() at syscall+0x308 XentSys() at XentSys+0x64 --- syscall (5, FreeBSD ELF, open) --- --- user mode --- -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: device.hints PCI detection conflict
In article [EMAIL PROTECTED] Andrey A. Chernov [EMAIL PROTECTED] wrote: Bootverbose shows that second copy of devices appearse on ASUS CUSL2-C or TUSL2-C: atkbdc-: atkbdc0 already exists, using atkbdc1 instead sc-: sc0 already exists, using sc1 instead vga-: vga0 already exists, using vga1 instead vga-: line is especially dangerous since cause fake second VGA detection (as MDA) which cause panic with recent duplicate make_dev panics commit. It looks like conflict with /boot/device.hints here. If I remove this line hint.sc.0.at=isa from device.hints, no fake second VGA appearse (the bug is gone), BUT... I have absolutely NO console output. If I put this line back, console oputput appearse and bug too. Removing atkbdc vga hints from device.hints cause atkbdc- vga- lines gone, which indicates conflict too. But sc hint can't be removed because it results with no console output. Please fix it somehow. In my case (ABIT's BP6 motherboard) the problem disapear after switching on ACPI (there is the problem with the fdc0 - cannot reserve I/O port range (1 ports) but now I can some time live without floppies :-). N.Dudorov To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs question
On Sat, 27 Oct 2001 11:32:07 +0200, Poul-Henning Kamp [EMAIL PROTECTED] said: Right, but the only way to get an error message is to let /sbin/init die and have the kernel print the message. /sbin/init cannot print the message when there is no /dev/console can it ? Yes, it can, if the kernel does the right then when hand-crafting the `init' process to ensure that the console is already open rather than making `init' do it. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs question
In message [EMAIL PROTECTED], Garrett Wollman w rites: On Sat, 27 Oct 2001 11:32:07 +0200, Poul-Henning Kamp [EMAIL PROTECTED] said: Right, but the only way to get an error message is to let /sbin/init die and have the kernel print the message. /sbin/init cannot print the message when there is no /dev/console can it ? Yes, it can, if the kernel does the right then when hand-crafting the `init' process to ensure that the console is already open rather than making `init' do it. Not a bad idea, but currently not implemented. -- 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: device.hints PCI detection conflict
On Sun, Oct 28, 2001 at 07:14:13 +0600, Nickolay Dudorov wrote: In article [EMAIL PROTECTED] Andrey A. Chernov [EMAIL PROTECTED] wrote: Bootverbose shows that second copy of devices appearse on ASUS CUSL2-C or TUSL2-C: atkbdc-: atkbdc0 already exists, using atkbdc1 instead sc-: sc0 already exists, using sc1 instead vga-: vga0 already exists, using vga1 instead vga-: line is especially dangerous since cause fake second VGA detection (as MDA) which cause panic with recent duplicate make_dev panics commit. It looks like conflict with /boot/device.hints here. If I remove this line hint.sc.0.at=isa from device.hints, no fake second VGA appearse (the bug is gone), BUT... I have absolutely NO console output. If I put this line back, console oputput appearse and bug too. Removing atkbdc vga hints from device.hints cause atkbdc- vga- lines gone, which indicates conflict too. But sc hint can't be removed because it results with no console output. Please fix it somehow. In my case (ABIT's BP6 motherboard) the problem disapear after switching on ACPI (there is the problem with the fdc0 - cannot reserve I/O port range (1 ports) but now I can some time live without floppies :-). In my case APCI or no ACPI gives absolutely no difference... -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
device.hints PCI detection conflict
Bootverbose shows that second copy of devices appearse on ASUS CUSL2-C or TUSL2-C: atkbdc-: atkbdc0 already exists, using atkbdc1 instead sc-: sc0 already exists, using sc1 instead vga-: vga0 already exists, using vga1 instead vga-: line is especially dangerous since cause fake second VGA detection (as MDA) which cause panic with recent duplicate make_dev panics commit. It looks like conflict with /boot/device.hints here. If I remove this line hint.sc.0.at=isa from device.hints, no fake second VGA appearse (the bug is gone), BUT... I have absolutely NO console output. If I put this line back, console oputput appearse and bug too. Removing atkbdc vga hints from device.hints cause atkbdc- vga- lines gone, which indicates conflict too. But sc hint can't be removed because it results with no console output. Please fix it somehow. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
adding athlon xp to bsd.cpu.mk
Hi,
how about the following patch (untested) regarding the newer athlon xp
processor type ? if needed, I could submit a PR.
Index: bsd.cpu.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.cpu.mk,v
retrieving revision 1.2.2.4
diff -u -r1.2.2.4 bsd.cpu.mk
--- bsd.cpu.mk 2001/03/21 11:43:20 1.2.2.4
+++ bsd.cpu.mk 2001/10/27 19:56:42
@@ -17,6 +17,8 @@
CPUTYPE = i686
. elif ${CPUTYPE} == pentium
CPUTYPE = i586
+. elif ${CPUTYPE} == athlonxp
+CPUTYPE = xp
. elif ${CPUTYPE} == athlon
CPUTYPE = k7
. endif
@@ -28,8 +30,10 @@
.if !defined(NO_CPU_CFLAGS) || !defined(NO_CPU_COPTFLAGS)
. if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
+. if ${CPUTYPE} == xp
_CPUCFLAGS = -march=k6 # gcc doesn't support athlon yet, but it will
+. elif ${CPUTYPE} == k7
+_CPUCFLAGS = -march=k6 # gcc doesn't support athlon yet, but it will
. elif ${CPUTYPE} == k6-2
_CPUCFLAGS = -march=k6
. elif ${CPUTYPE} == k6
@@ -79,7 +83,9 @@
# presence of a CPU feature.
.if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
+. if ${CPUTYPE} == xp
+MACHINE_CPU = k7 3dnow sse mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == k7
MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6-2
MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
Cyrille.
--
Cyrille Lefevre mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: adding athlon xp to bsd.cpu.mk
On Sat, Oct 27, 2001 at 10:00:44PM +0200, Cyrille Lefevre wrote: : Hi, : : how about the following patch (untested) regarding the newer athlon xp : processor type ? if needed, I could submit a PR. Shouldn't Athlons and AthlonXPs be able to use i686 (pentiumpro) instruction set optimizations? Also, what about putting in a mention for TransMeta Crusoe processors? --Jerry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: adding athlon xp to bsd.cpu.mk
On Sat, Oct 27, 2001 at 04:23:13PM -0400, Jerry A! wrote: On Sat, Oct 27, 2001 at 10:00:44PM +0200, Cyrille Lefevre wrote: : Hi, : : how about the following patch (untested) regarding the newer athlon xp : processor type ? if needed, I could submit a PR. Shouldn't Athlons and AthlonXPs be able to use i686 (pentiumpro) instruction set optimizations? Yes, as in (e.g): CPU: AMD Athlon(tm) Processor (700.03-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x621 Stepping = 1 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc040AMIE,DSP,3DNow! real memory = 268353536 (262064K bytes) avail memory = 257609728 (251572K bytes) Preloaded elf kernel kernel at 0xc0392000. Preloaded elf module agp.ko at 0xc039209c. Pentium Pro MTRR support enabled -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: adding athlon xp to bsd.cpu.mk
Jerry A! wrote: On Sat, Oct 27, 2001 at 10:00:44PM +0200, Cyrille Lefevre wrote: : Hi, : : how about the following patch (untested) regarding the newer athlon xp : processor type ? if needed, I could submit a PR. Shouldn't Athlons and AthlonXPs be able to use i686 (pentiumpro) instruction set optimizations? No. They are different cpu cores that have different optimization strategies. The patch doesn't include the AthlonMP which has the same core with both SSE and MMX. Also, what about putting in a mention for TransMeta Crusoe processors? --Jerry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message 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: adding athlon xp to bsd.cpu.mk
Shouldn't Athlons and AthlonXPs be able to use i686 (pentiumpro) instruction set optimizations? No. They are different cpu cores that have different optimization strategies. Yes, all Athlons can use i686 code while the k6's can't. Further, without doing any scientific testing, I would think the Athlon would do better with ppro optimized code than k6 optimized code thanks to the available i686 instructions. When GCC 3.0 is used, tho, this won't be an issue since it supports optimizations for the Athlon. Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: adding athlon xp to bsd.cpu.mk
On Sun, 28 Oct 2001 02:30:40 +0200 (CEST), Cyrille Lefevre wrote: Peter Wemm wrote: Jerry A! wrote: On Sat, Oct 27, 2001 at 10:00:44PM +0200, Cyrille Lefevre wrote: : Hi, : : how about the following patch (untested) regarding the newer athlon xp : processor type ? if needed, I could submit a PR. Shouldn't Athlons and AthlonXPs be able to use i686 (pentiumpro) instruction set optimizations? No. They are different cpu cores that have different optimization strategies. The patch doesn't include the AthlonMP which has the same core with both SSE and MMX. Athlon XP (commercial name) == Athlon MP (core name) AFAIK, not quite. The core name is Palomino and there are three processors based on it: Athlon XP, Athlon MP and Duron. Athlon (alias k7) already has MMX. the objective of this patch was to add SSE to the set of XP (alias MP) processors. What about new Durons based on the Palomino core? The problem is that as far as I know they have nothing in their name (like XP in Athlon's case) that distinguishes them from older Durons based on the Thunderbird core, while they do support SSE in addition to 3DNow and MMX. Perhaps it would be better to introduce new variable CPUCORE, so the user could use something like the following: CPUTYPE=athlon CPUCORE=thunderbird or CPUTYPE=duron CPUCORE=palomino and so on. This looks quite ugly, but I do not have any better ideas. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
