Re: Recent kernels won't boot
That was it. Is the 4MB kernel size limit documented anywhere? I don't know :-) I luckily noticed this by a lot of trials. I'm not aware of any 4MB limit on kernel size (and I ought to be if there is one 8). Can you run the details past me? (I've regularly booted much larger kernels in the past...) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: src/sys/dev/syscons/scvesactl.c broken
Are you sure your tree is entirely in sync ? I can't reproduce your problem here with the NOTES/LINT kernel... Version 1.16 of src/sys/dev/syscons/scvesactl.c, removing machine/console.h broke the kernel build for me. Attached is the relevant log, and my kernel file. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: src/sys/dev/syscons/scvesactl.c broken
Poul-Henning Kamp wrote: Are you sure your tree is entirely in sync ? Yes... I've checked it several times. I can't reproduce your problem here with the NOTES/LINT kernel... The following patch got my kernel compiled and running, although I can't say it's the right thing to do. I'll cvsup again and do a cvs update -A just to double check, but I'm pretty sure that this is a good tree, and it's happening for me on two different machines with similar kernel confs. Doug Index: scvesactl.c === RCS file: /usr/ncvs/src/sys/dev/syscons/scvesactl.c,v retrieving revision 1.16 diff -u -r1.16 scvesactl.c --- scvesactl.c 2000/10/08 21:33:54 1.16 +++ scvesactl.c 2000/10/09 06:37:05 @@ -35,6 +35,8 @@ #include sys/conf.h #include sys/tty.h #include sys/kernel.h +#include sys/fbio.h +#include sys/consio.h #include machine/pc/vesa.h Version 1.16 of src/sys/dev/syscons/scvesactl.c, removing machine/console.h broke the kernel build for me. Attached is the relevant log, and my kernel file. -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernels won't boot
I'm not aware of any 4MB limit on kernel size (and I ought to be if there is one 8). Can you run the details past me? (I've regularly booted much larger kernels in the past...) OK, I built 5 kernels based on the same kerne config file giving some modifications. Here is the result. boot? kernel size description ( (+)Add (-)Delete ) ---+---+-- OK 4007152(+)device acpica NG 4182845(+)device acpica (+)options ACPI_DEBUG OK 4011963(+)device acpica (+)options ACPI_DEBUG (-)USB stuff OK 3470869GENERIC OK 1600config -g GENERIC Mysteriously, kernel.debug (16MB) does boot... Ah, probably section size limitation? % size ACPICA/kernel* GENERIC/kernel* textdata bss dec hex filename 3176366 370104 172152 3718622 38bdde ACPICA/kernel.big 3058264 346724 165848 3570836 367c94 ACPICA/kernel.normal 3009909 368024 169688 3547621 3621e5 ACPICA/kernel.small 2745241 206872 152184 3104297 2f5e29 GENERIC/kernel 2745241 206872 152184 3104297 2f5e29 GENERIC/kernel.debug Maybe /boot/ stuff is reltated with this too. % ls -ltR /boot total 908 drwxr-xr-x 2 root wheel3072 10/ 8 15:50 kernel -r-xr-xr-x 1 root wheel 159744 10/ 8 15:49 liloboot -r-xr-xr-x 1 root wheel 157696 10/ 8 15:49 pxeboot -r-xr-xr-x 1 root wheel 157696 10/ 8 15:49 cdboot drwxr-xr-x 2 root wheel 512 10/ 8 15:49 defaults -r-xr-xr-x 1 root wheel 155648 10/ 8 15:49 loader -r--r--r-- 1 root wheel7680 10/ 8 15:49 boot2 -r--r--r-- 1 root wheel 512 10/ 8 15:49 boot1 -r--r--r-- 1 root wheel 512 10/ 8 15:49 boot0 -r--r--r-- 1 root wheel 512 10/ 8 15:49 mbr drwxr-xr-x 2 root wheel 512 10/ 7 11:29 kernel.old -rw-r--r-- 1 root wheel7816 10/ 6 02:08 loader.conf -rw-r--r-- 1 root wheel1440 10/ 4 19:23 device.hints -r-xr-xr-x 1 root wheel 155648 10/ 2 16:35 loader.old -r--r--r-- 1 root wheel7577 9/27 10:57 loader.4th -r--r--r-- 1 root wheel 35170 9/27 10:57 support.4th drwxr-xr-x 2 root wheel 512 9/16 18:33 modules -rw-r--r-- 1 root wheel 24 8/ 4 23:58 kernel.conf -r--r--r-- 1 root wheel 12064 4/17 16:33 loader.help -r--r--r-- 1 root wheel 338 1/31 2000 loader.rc /boot/kernel: total 8536 -r-xr-xr-x 1 root wheel20741 10/ 8 15:50 if_wi.ko : -r-xr-xr-x 1 root wheel15097 10/ 8 15:49 3dfx.ko -r-xr-xr-x 1 root wheel 3891459 10/ 8 15:40 kernel /boot/defaults: total 8 -r--r--r-- 1 root wheel 7979 9/19 04:38 loader.conf /boot/kernel.old: total 3768 -r-xr-xr-x 1 root wheel 3844898 10/ 7 11:29 kernel /boot/modules: Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: src/sys/dev/syscons/scvesactl.c broken
In message [EMAIL PROTECTED], Doug Barton writes: Poul-Henning Kamp wrote: Are you sure your tree is entirely in sync ? Yes... I've checked it several times. I can't reproduce your problem here with the NOTES/LINT kernel... OK, found it, two negative options in NOTES/LINT prevented a lot of syscons code from being covered by NOTES/LINT. I'll commit in a sec... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | 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: src/sys/dev/syscons/scvesactl.c broken
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Doug Barton writes: Poul-Henning Kamp wrote: Are you sure your tree is entirely in sync ? Yes... I've checked it several times. I can't reproduce your problem here with the NOTES/LINT kernel... OK, found it, two negative options in NOTES/LINT prevented a lot of syscons code from being covered by NOTES/LINT. I'll commit in a sec... Cool... you da man. :) Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernels won't boot
I'm not aware of any 4MB limit on kernel size (and I ought to be if there is one 8). Can you run the details past me? (I've regularly booted much larger kernels in the past...) Alpha? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernels won't boot
Mike Smith wrote: That was it. Is the 4MB kernel size limit documented anywhere? I don't know :-) I luckily noticed this by a lot of trials. I'm not aware of any 4MB limit on kernel size (and I ought to be if there is one 8). Can you run the details past me? (I've regularly booted much larger kernels in the past...) Uhh, are you sure? Ignore the size of the file, what does 'size(1)' say about these large kernels? Does text+data+bss excede 4MB? I have a nagging suspicion that we only set up 4MB of page tables during the early part of the bootstrap process in locore.s. (forgive me for not looking, I have a most evil headache and locore.s is no way to improve it :-). Thinking about it some more, there may be a 3MB limit as we load above 1MB. I recall some heavy magic with the SMP bootstrap where we only use one PTD slot for 0-4MB in early boot 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: Recent kernels won't boot
Hi, At 01:04 -0700 9/10/00, Peter Wemm wrote: Mike Smith wrote: That was it. Is the 4MB kernel size limit documented anywhere? I don't know :-) I luckily noticed this by a lot of trials. I'm not aware of any 4MB limit on kernel size (and I ought to be if there is one 8). Can you run the details past me? (I've regularly booted much larger kernels in the past...) Uhh, are you sure? Ignore the size of the file, what does 'size(1)' say about these large kernels? Does text+data+bss excede 4MB? I have a nagging suspicion that we only set up 4MB of page tables during the early part of the bootstrap process in locore.s. (forgive me for not looking, I have a most evil headache and locore.s is no way to improve it :-). Thinking about it some more, there may be a 3MB limit as we load above 1MB. I recall some heavy magic with the SMP bootstrap where we only use one PTD slot for 0-4MB in early boot Example: % size kernel*/kernel textdata bss dec hex filename 3302182 206816 2265368 5774366 581c1e kernel.old/kernel 2947194 207168 168152 3322514 32b292 kernel/kernel Same kernel config except that top one includes KTR options and won't boot, bottom one has no KTR and boots OK. I've been running with SMP_DEBUG, KTR and the rest for a while, this trouble started a few days ago. -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: POSTFIX-- Wietse: tweak and go! --pkg port: both duds
On Mon, Oct 09, 2000 at 12:37:30AM +, attila! wrote: -BEGIN PGP SIGNED MESSAGE- on Sun, 8 Oct 2000 11:46:47 +0200, Peter van Dijk [EMAIL PROTECTED] said: Actually, mailwrapper (I don't know about this mailcap thing, I'm only running STABLE right now for lack of machines) does this job. Have you looked at /etc/mail/mailer.conf? The sendmail binary in /usr/sbin has no relation to sendmail - it's the mailwrapper, which is a good concept. What needs to be considered, in maintaining postfix for the 'conventional' interface of sendmail (as of 8.10) is: /usr/bin/mailq - /usr/sbin/sendmail /usr/bin/newaliases - /usr/sbin/sendmail /usr/sbin/sendmail - /usr/sbin/mailwrapper and, given that Wietse's /usr/bin/sendmail does essentially the same thing as sendmail's /usr/sbin/mailwrapper except Stop that. Don't touch mailwrapper. Leave it in. We like it. Greetz, Peter -- dataloss networks '/ignore-ance is bliss' - me To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FW: problem w/ new pcm feeder + emu10k1 in 4.1.1-stable
-Original Message- From: Glendon Gross [SMTP:[EMAIL PROTECTED]] Sent: Sunday, October 08, 2000 6:23 AM To: Bjoern Fischer Cc: Cameron Grant; [EMAIL PROTECTED] Subject:Re: problem w/ new pcm feeder + emu10k1 in 4.1.1-stable I wonder if this has anything to do with why my Soundwave 128 PCI is not recognized. It shows up as an "unknown card" during boot: Script started on Sun Oct 8 06:12:35 2000 % dmesg | grep unknown pci0: unknown card (vendor=0x1073, dev=0x000d) at 9.0 irq 11 % exit % exit Script done on Sun Oct 8 06:12:50 2000 I have another FreeBSD box which is working fine with the SB AWE-64 card, so I was hoping there might be a way to get this card to work. The card professes Soundblaster Pro/16 and OPL3 compatibility. On Sun, 8 Oct 2000, Bjoern Fischer wrote: Hello Cameron, I was curious about your new pcm feeder, so I cvsuped to 4.1.1-STABLE (Sun Oct 8 00:22:45 CEST 2000) and made world and new kernel. The SNDCTL_DSP_SETFMT ioctl *always* returns EINVAL :-( Hardware: SB Live! 1024 / EMU10K1 I turned on some debug switches and got this while trying to start esd (esound). I have chosen esound because esd tries many different formats for SNDCTL_DSP_SETFMT before giving up: installing feeder: 8to16le installing feeder: 16leto8 installing feeder: monotostereo8 installing feeder: monotostereo16 installing feeder: stereotomono8 installing feeder: stereotomono16 installing feeder: endian installing feeder: sign8 installing feeder: sign16le installing feeder: ulawtou8 installing feeder: u8toulaw open snd0 subdev 0 flags 0x0003 mode 0x2000 close snd0 subdev 0 open snd0 subdev 3 flags 0x0006 mode 0x2000 want format 8 not mapped, flags 0, want speed 8000, try speed 48000, got speed 48000, not mapped, flags 8, find feeder type 3, got 0 r = 22 FIOASYNC SNDCTL_DSP_SETFRAGMENT 0x0108 SNDCTL_DSP_SETFRAGMENT 256 frags, 256 sz want format 16 not mapped, flags 8, find feeder type 3, got 0 close snd0 subdev 3 chn_flush c-flags 0x3000 open snd0 subdev 3 flags 0x0006 mode 0x2000 want format 8 not mapped, flags 8, find feeder type 3, got 0 FIOASYNC SNDCTL_DSP_SETFRAGMENT 0x0108 SNDCTL_DSP_SETFRAGMENT 256 frags, 256 sz want format 8 not mapped, flags 8, find feeder type 3, got 0 close snd0 subdev 3 chn_flush c-flags 0x3000 open snd0 subdev 3 flags 0x0006 mode 0x2000 want format 8 not mapped, flags 8, find feeder type 3, got 0 FIOASYNC SNDCTL_DSP_SETFRAGMENT 0x0108 SNDCTL_DSP_SETFRAGMENT 256 frags, 256 sz want format 16 not mapped, flags 8, find feeder type 3, got 0 close snd0 subdev 3 chn_flush c-flags 0x3000 open snd0 subdev 3 flags 0x0006 mode 0x2000 want format 8 not mapped, flags 8, find feeder type 3, got 0 FIOASYNC SNDCTL_DSP_SETFRAGMENT 0x0108 SNDCTL_DSP_SETFRAGMENT 256 frags, 256 sz want format 8 not mapped, flags 8, find feeder type 3, got 0 close snd0 subdev 3 chn_flush c-flags 0x3000 open snd0 subdev 3 flags 0x0006 mode 0x2000 want format 8 not mapped, flags 8, find feeder type 3, got 0 FIOASYNC SNDCTL_DSP_SETFRAGMENT 0x0108 SNDCTL_DSP_SETFRAGMENT 256 frags, 256 sz want format 16 not mapped, flags 8, find feeder type 3, got 0 close snd0 subdev 3 chn_flush c-flags 0x3000 open snd0 subdev 3 flags 0x0006 mode 0x2000 want format 8 not mapped, flags 8, find feeder type 3, got 0 FIOASYNC SNDCTL_DSP_SETFRAGMENT 0x0108 SNDCTL_DSP_SETFRAGMENT 256 frags, 256 sz want format 8 not mapped, flags 8, find feeder type 3, got 0 close snd0 subdev 3 chn_flush c-flags 0x3000 open snd0 subdev 3 flags 0x0006 mode 0x2000 want format 8 not mapped, flags 8, find feeder type 3, got 0 FIOASYNC SNDCTL_DSP_SETFRAGMENT 0x0108 SNDCTL_DSP_SETFRAGMENT 256 frags, 256 sz want format 8 not mapped, flags 8, find feeder type 3, got 0 close snd0 subdev 3 chn_flush c-flags 0x3000 open snd0 subdev 3 flags 0x0006 mode 0x2000 want format 8 not mapped, flags 8, find feeder type 3, got 0 ... Any idea what's causing this? Bjoern -- -BEGIN GEEK CODE BLOCK- GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L---(++) !E W- N+ o+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: POSTFIX-- Wietse: tweak and go! --pkg port: both duds
At 9:22 PM + 2000/10/8, attila! wrote: I look at 'snapshots' philosophically; if I willingly track FreeBSD-5.0-current, I am obviously accustomed to the risks therein. Understood. I just wanted to point out the philosophical differences from the postfix perspective, and thought that it was important that this be made explicit. 20001001 is the most current which Wietse is now running and stating that it is 'production quality'. Obviously, I will port 20001001 this afternoon! No, 20001005 is the latest snapshot I know of, and appears to be what Wietse is running himself: $ telnet spike.porcupine.org. 25 Trying 168.100.189.2... Connected to spike.porcupine.org. Escape character is '^]'. 220 spike.porcupine.org ESMTP Postfix (Snapshot-20001005) quit 221 Bye Connection closed by foreign host. However, I would not be too surprised if what he was running is actually slightly later than this (i.e., another snapshot in progress), and it just identifies itself as Snapshot-20001005. Why not consider the use of the mysql interface which provides dynamic aliasing? The machines where I run this code don't strictly need a MySQL interface for aliases. Although we do keep our internal aliases in a MySQL database, I do not believe that it is in a format that would be suitable for use with postfix, and therefore I'd have to create yet another MySQL database that *was* in the proper format. This would likely lead to synchronization problems, etc -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
today's panic
Today's current (buildworld+build kernel), check out at ~10.00 GMT.
I have this problem during 6-7 days, the stable version for me:
FreeBSD newsfeed.gamma.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Oct 2 21:56:00 MSD
2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEWSFEED i386
I haven't any problems till this date.
Server: P2B-DS, BIOS rev. 1012.
kgdb:
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /news/crash/kernel.0
(kgdb) core-file /news/crash/vmcore.0
SMP 2 cpus
IdlePTD 2813952
initial pcb at 23e720
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id =
fault virtual address = 0xc
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc015d616
stack pointer = 0x10:0xe2312da4
frame pointer = 0x10:0xe2312dd4
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 = 388 (innd)
trap number = 12
panic: page fault
cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
giving up on 20 buffers
Uptime: 1m46s
dumping to dev #da/25, offset 80572
dump 1023 1022 1021 1020 1019 1018 1017 1016 1015 1014 1013 1012 1011 1010 1009 [...]
6 5 4 3 2 1 0
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:476
476 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:476
#1 0xc014a52f in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:317
#2 0xc014a954 in poweroff_wait (junk=0xc0217b6f, howto=-611008192)
at /usr/src/sys/kern/kern_shutdown.c:569
#3 0xc01eb544 in trap_fatal (frame=0xe2312d64, eva=12)
at /usr/src/sys/i386/i386/trap.c:939
#4 0xc01eb2a5 in trap_pfault (frame=0xe2312d64, usermode=0, eva=12)
at /usr/src/sys/i386/i386/trap.c:853
#5 0xc01eae03 in trap (frame={tf_fs = -500105192, tf_es = -500105200,
tf_ds = -1072300016, tf_edi = 49, tf_esi = 64, tf_ebp = -500093484,
tf_isp = -500093552, tf_ebx = -1015227740, tf_edx = 0,
tf_ecx = -611008192, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1072310762, tf_cs = 8, tf_eflags = 66050,
tf_esp = -1015227740, tf_ss = 64}) at /usr/src/sys/i386/i386/trap.c:436
#6 0xc015d616 in selscan (p=0xdb94c140, ibits=0xe2312e28, obits=0xe2312e1c,
nfd=62) at /usr/src/sys/sys/file.h:187
182 struct proc *p;
183 {
184 int error;
185
186 fhold(fp);
187 error = (*fp-f_ops-fo_poll)(fp, events, cred, p);
188 fdrop(fp, p);
189 return (error);
190 }
191
(kgdb) print *fp
$1 = {f_list = {le_next = 0x0, le_prev = 0x0}, f_flag = 0, f_type = 0,
f_count = 0, f_msgcount = 0, f_cred = 0x0, f_ops = 0x0, f_seqcount = 0,
^^^
f_nextoff = 0, f_offset = 0, f_data = 0x0}
#7 0xc015d371 in select (p=0xdb94c140, uap=0xe2312f80)
at /usr/src/sys/kern/sys_generic.c:709
#8 0xc01eb960 in syscall2 (frame={tf_fs = 47, tf_es = 47,
tf_ds = -1078001617, tf_edi = 300, tf_esi = 134660576,
tf_ebp = -1077937204, tf_isp = -500092972, tf_ebx = -1077937332,
tf_edx = 246, tf_ecx = -1, tf_eax = 93, tf_trapno = 7, tf_err = 2,
tf_eip = 672214604, tf_cs = 31, tf_eflags = 515, tf_esp = -1077937568,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1139
---Type return to continue, or q return to quit---
#9 0xc01dc294 in Xint0x80_syscall ()
#10 0x805707d in ?? ()
#11 0x804a671 in ?? ()
dmesg -v:
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 #0: Mon Oct 9 16:11:26 MSD 2000
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEWSFEED
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (451.03-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x673 Stepping = 3
Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE
real memory = 1073729536 (1048564K bytes)
avail memory = 1042202624 (1017776K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 - irq 0
FreeBSD/SMP: Multiprocessor motherboard
cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0
cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0
Preloaded elf kernel "kernel" at 0xc029d000.
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at
device 1.0 on pci0
pci1: PCI bus on pcib1
isab0: Intel
Re: today's panic
Today's current (buildworld+build kernel), check out at ~10.00 GMT. I have this problem during 6-7 days, the stable version for me: FreeBSD newsfeed.gamma.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Oct 2 21:56:00 MSD 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEWSFEED i386 I haven't any problems till this date. The same proble on another server (no crash dump). IP: c01502d8 nm /boot/kernel/kernel | grep c0150 | sort c015025c t pollscan c015031c T openbsd_poll c015032c T seltrue c0150338 T selrecord c0150378 T selwakeup c0150400 T pipe c0150588 t pipespace c01505f0 t pipeinit c0150690 t pipe_read c015098c t pipe_build_write_buffer c0150b44 t pipe_destroy_write_buffer c0150bc8 t pipe_clone_write_buffer c0150c04 t pipe_direct_write c0150edc t pipe_write dmesg: 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 #0: Mon Oct 9 14:41:38 MSD 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MAIL Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 300682964 Hz CPU: Pentium II/Pentium II Xeon/Celeron (300.68-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping = 3 Features=0x80f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 134217728 (131072K bytes) avail memory = 127950848 (124952K bytes) Preloaded elf kernel "kernel" at 0xc0292000. Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443LX (440 LX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443LX (440 LX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: Intel 82371AB PCI to ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xd800-0xd80f at device 4.1 on pci0 atapci0: Busmastering DMA enabled ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: Intel 82371AB/EB (PIIX4) USB controller at 4.2 pci0: Intel 82371AB Power management controller at 4.3 pci0: unknown card (vendor=0x9004, dev=0x8078) at 6.0 irq 9 de0: Digital 21140A Fast Ethernet port 0xb800-0xb87f mem 0xe280-0xe280007f irq 9 at device 9.0 on pci0 de0: 21140A [10-100Mb/s] pass 2.2 de0: address 00:40:33:a2:ae:fe de1: Digital 21140A Fast Ethernet port 0xb400-0xb47f mem 0xe200-0xe27f irq 12 at device 10.0 on pci0 de1: 21140A [10-100Mb/s] pass 2.2 de1: address 00:40:33:a2:af:01 ed0: NE2000 PCI Ethernet (RealTek 8029) port 0xb000-0xb01f irq 10 at device 11.0 on pci0 ed0: address 00:00:1c:3a:3a:39, type NE2000 (16 bit) pci0: S3 Trio graphics accelerator at 12.0 irq 11 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 ed1 at port 0x240-0x25f iomem 0xd8000 irq 5 on isa0 ed1: address 00:c0:6c:54:12:37, type NE2000 (16 bit) 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 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: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0303 can't assign resources DUMMYNET initialized (000608) IP packet filtering initialized, divert disabled, rule-based forwarding enabled, default to deny, logging disabled ad0: 7339MB QUANTUM FIREBALL EL7.6A [15907/15/63] at ata0-master UDMA33 ad2: 7339MB QUANTUM FIREBALL EL7.6A [15907/15/63] at ata1-master UDMA33 Mounting root from ufs:/dev/ad0a WARNING: / was not properly dismounted de0: enabling 100baseTX port de1: enabling 100baseTX port vinum: loaded vinum: reading configuration from /dev/ad2s1d vinum: updating configuration from /dev/ad0s1d de1: link down: cable problem? de1: enabling 10baseT port de1: enabling Full Duplex 10baseT port link_elf: symbol card_set_res_flags_desc undefined To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org
On Sun, Oct 08, 2000 at 10:32:53PM -0700, Jordan Hubbard wrote: We've also been forced by the silicon valley personnel crunch to hire a new system administrator who's a little strange (he refers to himself as "Elvis Preston" and makes odd little hip-thrusts at the system rack when he thinks nobody is looking) and frequently missing, Huh? Sounds like unfurl to me. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
port tree clean?
Hi there, is port tree back for cvsup? -- // Donny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: port tree clean?
On Tue, Oct 10, 2000 at 02:52:37AM +0800, Donny Lee wrote: Hi there, is port tree back for cvsup? Yes. Greetz, Peter -- dataloss networks '/ignore-ance is bliss' - me To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: port tree clean?
Peter wrote: Hi there, is port tree back for cvsup? Yes. Thanks, Peter. -- // Donny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sio patch to add mutexes..
Hey gang,
I have some patches to add per-softc spin mutexes to the sio code
in place of the old COM_LOCK. Since spin mutexes already dink with
interrupts, this also allows all the *_intr() cruft to go away.
Unfortunately, I can't get the current sio to work on any of the boxes
here because DCD is never raised, so I don't know if this breaks
anything, though it doesn't seem to fix my bxoes. :-/ The patch is
availabe at http://www.FreeBSD.org/~jhb/patches/sio.patch, and included
inline here for those w/o web access:
Index: sio.c
===
RCS file: /home/ncvs/src/sys/isa/sio.c,v
retrieving revision 1.316
diff -u -r1.316 sio.c
--- sio.c 2000/10/05 23:09:54 1.316
+++ sio.c 2000/10/06 06:11:29
@@ -96,12 +96,6 @@
#endif
#include isa/ic/ns16550.h
-/* XXX - this is ok because we only do sio fast interrupts on i386 */
-#ifndef __i386__
-#define disable_intr()
-#define enable_intr()
-#endif
-
#defineLOTS_OF_EVENTS 64 /* helps separate urgent events from
input */
#defineCALLOUT_MASK0x80
@@ -284,6 +278,8 @@
*/
u_char obuf1[256];
u_char obuf2[256];
+
+ struct mtx intrlock; /* spin mutex used in the interrupt handler */
};
#ifdef COM_ESP
@@ -759,7 +755,6 @@
u_int flags = device_get_flags(dev);
int rid;
struct resource *port;
- int intrsave;
rid = xrid;
port = bus_alloc_resource(dev, SYS_RES_IOPORT, rid,
@@ -771,6 +766,7 @@
com-bst = rman_get_bustag(port);
com-bsh = rman_get_bushandle(port);
+ mtx_init(com-intrlock, "sio interrupt lock", MTX_SPIN);
#if 0
/*
* XXX this is broken - when we are first called, there are no
@@ -856,9 +852,7 @@
* but mask them in the processor as well in case there are some
* (misconfigured) shared interrupts.
*/
- intrsave = save_intr();
- disable_intr();
- COM_LOCK();
+ mtx_enter(com-intrlock, MTX_SPIN);
/* EXTRA DELAY? */
/*
@@ -955,9 +949,9 @@
CLR_FLAG(dev, COM_C_IIR_TXRDYBUG);
}
sio_setreg(com, com_cfcr, CFCR_8BITS);
- COM_UNLOCK();
- restore_intr(intrsave);
+ mtx_exit(com-intrlock, MTX_SPIN);
bus_release_resource(dev, SYS_RES_IOPORT, rid, port);
+ mtx_destroy(com-intrlock);
return (iobase == siocniobase ? 0 : result);
}
@@ -996,8 +990,7 @@
irqmap[3] = isa_irq_pending();
failures[9] = (sio_getreg(com, com_iir) IIR_IMASK) - IIR_NOPEND;
- COM_UNLOCK();
- restore_intr(intrsave);
+ mtx_exit(com-intrlock, MTX_SPIN);
irqs = irqmap[1] ~irqmap[0];
if (bus_get_resource(idev, SYS_RES_IRQ, 0, xirq, NULL) == 0
@@ -1026,6 +1019,7 @@
break;
}
bus_release_resource(dev, SYS_RES_IOPORT, rid, port);
+ mtx_destroy(com-intrlock);
return (iobase == siocniobase ? 0 : result);
}
@@ -1116,7 +1110,6 @@
int rid;
struct resource *port;
int ret;
- int intrstate;
rid = xrid;
port = bus_alloc_resource(dev, SYS_RES_IOPORT, rid,
@@ -1155,6 +1148,7 @@
com-tx_fifo_size = 1;
com-obufs[0].l_head = com-obuf1;
com-obufs[1].l_head = com-obuf2;
+ mtx_init(com-intrlock, "sio interrupt lock", MTX_SPIN);
com-data_port = iobase + com_data;
com-int_id_port = iobase + com_iir;
@@ -1185,10 +1179,8 @@
com-it_in.c_ispeed = com-it_in.c_ospeed = comdefaultrate;
} else
com-it_in.c_ispeed = com-it_in.c_ospeed = TTYDEF_SPEED;
- intrstate = save_intr();
if (siosetwater(com, com-it_in.c_ispeed) != 0) {
- COM_UNLOCK();
- restore_intr(intrstate);
+ mtx_exit(com-intrlock, MTX_SPIN);
/*
* Leave i/o resources allocated if this is a `cn'-level
* console, so that other devices can't snarf them.
@@ -1197,8 +1189,7 @@
bus_release_resource(dev, SYS_RES_IOPORT, rid, port);
return (ENOMEM);
}
- COM_UNLOCK();
- restore_intr(intrstate);
+ mtx_exit(com-intrlock, MTX_SPIN);
termioschars(com-it_in);
com-it_out = com-it_in;
@@ -1432,8 +1423,6 @@
goto out;
}
} else {
- int intrsave;
-
/*
* The device isn't open, so there are no conflicts.
* Initialize it. Initialization is done twice in many
@@ -1493,9 +1482,7 @@
}
}
- intrsave = save_intr();
- disable_intr();
- COM_LOCK();
+
FREE COMPUTER
Visithttp://www.afrocencheck.com and Enter to Win: FREE COMPUTER $1000.00 FREE AFROCENCHECKS Sign the Guestbook and you are automatically entered to WIN! Also everyone who signs the guestbook recieves a FREE GIFT! Please remember to mention " campaign EM" in the comments section and your FREE gift is on the way! Bonus - Send this email to 5 friends and we will automatically give you five additional entries to win the cash and prizes. Send this email to 10 friends and recieve ten additional entries to win the cash and prizes. More entries equals greater chances to WIN Extra Bonus - During the month of October we are awarding the individual with the most referrals $250.00 cash!!! Good Luck :) AfrocenCheck strongly supports anti-spamming laws. We truly believe in your right to privacy. To unsubscribe, simply press reply - type unsubscribe in the title and your name will be removed immediately. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: port tree clean?
In message [EMAIL PROTECTED] Donny Lee writes: : is port tree back for cvsup? Yes. UPDATING even has been updated saying so :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernels won't boot
On 09-Oct-00 Mike Smith wrote: That was it. Is the 4MB kernel size limit documented anywhere? I don't know :-) I luckily noticed this by a lot of trials. I'm not aware of any 4MB limit on kernel size (and I ought to be if there is one 8). Can you run the details past me? (I've regularly booted much larger kernels in the past...) I think the PSE optimization may limit us to a 4mb kernel size? Perhaps options DISABLE_PSE would work around it then? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: very high CPU time demand from process #10 ('idle')
On Sunday, 8 October 2000 at 7:51:20 +, attila! wrote: -- ps -ax -- 0 ?? DLs0:00.40 (swapper) 1 ?? ILs0:00.07 /sbin/init -- 2 ?? DL 0:04.23 (pagedaemon) 3 ?? DL 0:00.65 (vmdaemon) 4 ?? DL 0:00.70 (bufdaemon) 5 ?? DL 0:44.85 (syncer) 10 ?? RL 4986:29.70 (idle) 11 ?? WL 5:43.86 (softinterrupt) 12 ?? DL24:58.44 (random) 13 ?? WL 0:05.88 (irq10: ahc0) 14 ?? WL 0:00.00 (irq11: dc0) 15 ?? WL 0:14.91 (irq1: atkbd0) 16 ?? WL 0:46.60 (irq12: psm0) 17 ?? WL 0:00.00 (irq6: fdc0) 18 ?? WL 0:00.08 (irq7: ppc0) 19 ?? WL 3:19.82 (irq0: clk) 20 ?? RL 5:43.47 (irq8: rtc) What is process 10? It's the idle process. Is this literally a representation of the CPU idle time accumulation for the 85 hours since boot? Yes. Despite the enormous time burn on 'idle' it does not show on 'top'. Yes, that didn't seem to make sense. 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
can't get into single user mode - panic: ffs_valloc: dup alloc
morning all ...
Well, I swear I have to be missing something here that is going to
make me slap my forehead, but I can't get into single user mode :(
I hit the space bar, type in 'boot -s' and it goes through all the
normal start up procedures, sets up the networking, etc ...
The reason I'm trying to get into single user mode is cause I
can't get into multi-user without it doing:
=
Recovering vi editor sessions
mode = 0100600, inum = 729, fs = /tmp
panic: ffs_valloc: dup alloc
cpuid = 0; lapic.id =
Debugger("panic")
CPU0 stopping CPUs: 0x0002... stopped
and a trace of:
Debugger() @ +0x38
panic() @ +0xa0
ffs_valloc()@ +0xf5
ufs_makeinode() @ +0x5a
ufs_create()@ +0x28
ufs_vnoperate() @ +0x15
Marc G. Fournier [EMAIL PROTECTED]
Systems Administrator @ hub.org
scrappy@{postgresql|isc}.org ICQ#7615664
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: a.out binaries die in -current recently
On Sun, Oct 08, 2000 at 03:41:07PM -0500, Mark Hittinger wrote: For the past couple of days the old style binaries don't work under -current, they simply core. Well, my attitude would be "so what?". But others may find a valid need for a.out binaries *shrug*. -- Will Andrews [EMAIL PROTECTED] - Physics Computer Network wench The Universal Answer to All Problems - "It has something to do with physics." -- Comic on door of Room 240, Physics Building, Purdue University To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Compaq wl100 driver?
Hi, Has anyone ported the prism2 driver from linux to FreeBSD to run the Compaq/Samsung etc wl100 wireless ethernet cards? Anyone writing a new driver for it? Thanks, Lars To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't get into single user mode - panic: ffs_valloc: dup alloc
On Mon, 9 Oct 2000, Marc G. Fournier wrote: Well, I swear I have to be missing something here that is going to make me slap my forehead, but I can't get into single user mode :( I hit the space bar, type in 'boot -s' and it goes through all the normal start up procedures, sets up the networking, etc ... The reason I'm trying to get into single user mode is cause I can't get into multi-user without it doing: That's interesting -- this morning, I hit a ffs_valloc: dup alloc panic following a buildworld. I assumed it was to do with my local ACL patches, although I have been unable to find a bug that could trigger it. I'm wondering if this isn't some sort of locking issue in VFS. I managed to trigger it in ufs_mkdir(), as I introduced a potentially location for blocking where previously none existed, suggesting that perhaps some UFS code is playing fast and loose with vnode locks. This panic is generated when FFS tries to recycle a vnode, but discovers it has a non-zero mode, indicating that it is in use elsewhere in the system, which should never happen. BTW, do you have FFS_EXTATTR enabled? Anyhow, I'm going to see if I can get it to be reproduceable here. Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't get into single user mode - panic: ffs_valloc: dup alloc
On Mon, 9 Oct 2000, Robert Watson wrote: On Mon, 9 Oct 2000, Marc G. Fournier wrote: Well, I swear I have to be missing something here that is going to make me slap my forehead, but I can't get into single user mode :( I hit the space bar, type in 'boot -s' and it goes through all the normal start up procedures, sets up the networking, etc ... The reason I'm trying to get into single user mode is cause I can't get into multi-user without it doing: That's interesting -- this morning, I hit a ffs_valloc: dup alloc panic following a buildworld. I assumed it was to do with my local ACL patches, although I have been unable to find a bug that could trigger it. I'm wondering if this isn't some sort of locking issue in VFS. I managed to trigger it in ufs_mkdir(), as I introduced a potentially location for blocking where previously none existed, suggesting that perhaps some UFS code is playing fast and loose with vnode locks. This panic is generated when FFS tries to recycle a vnode, but discovers it has a non-zero mode, indicating that it is in use elsewhere in the system, which should never happen. BTW, do you have FFS_EXTATTR enabled? not that I've enabled ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs servers load
At 7 Oct 2000 14:59:27 GMT, Dennis Glatting [EMAIL PROTECTED] wrote: Any running load information on the CVS servers available? I'd like to adjust my pointers to help spread the load. My current pointers, for myself and two clients, is cvsup3. Most of servers in Japan have load statistics. But of course, servers in US are prefered... http://home.jp.freebsd.org/stats/mrtg/cvsup/index.en.html This statistics built with ucd-snmp and mrtg toolchain. If many US servers provide stats like this, users can select low-load server. -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a.out binaries die in -current recently
In message [EMAIL PROTECTED] Will Andrews writes: : On Sun, Oct 08, 2000 at 03:41:07PM -0500, Mark Hittinger wrote: : For the past couple of days the old style binaries don't work under -current, : they simply core. : : Well, my attitude would be "so what?". But others may find a valid need : for a.out binaries *shrug*. netscape. % file /usr/local/lib/netscape/navigator-4.72.us.bin /usr/local/lib/netscape/navigator-4.72.us.bin: FreeBSD/i386 compact demand paged dynamically linked executable % Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a.out binaries die in -current recently
On Mon, Oct 09, 2000 at 11:40:09PM -0600, Warner Losh wrote: netscape. Nope. BSDI Netscape bins don't require a.out libs. -- Will Andrews [EMAIL PROTECTED] - Physics Computer Network wench The Universal Answer to All Problems - "It has something to do with physics." -- Comic on door of Room 240, Physics Building, Purdue University To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
