Recent current misreports scsi disk size
Hello I just cvsupped the src-all, built the world, kernel and noticed that: changing root device to da0s1a da0 at ncr0 bus 0 target 5 lun 0 da0: QUANTUM VIKING II 4.5WSE 5520 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) da1 at ncr0 bus 0 target 6 lun 0 da1: QUANTUM VIKING II 4.5WSE 5520 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) ^ Actually the size is around 4GB. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Can't open /dev/vinum/Control: Operation not supported by device
Hello Something broke the vinum roughly between 18-21 July. Vinum refuses to get up my striped volume with message: Can't open /dev/vinum/Control: Operation not supported by device This is output from command: vinum read /dev/wd0 /dev/wd1 All subsequent commands fail with same message. The debug control device is in place, as are all others. The older kernel and module from July 16 work well. I've just built the world and kernel from fresh sources. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world builds but doesn't install
On Sat, Jul 24, 1999 at 11:11:51AM +0930, Greg Lehey [EMAIL PROTECTED] wrote: Whats more interesting, the July 19 sources which built and installed fine before now doesn't install anymore. Exactly same message. I've downloaded the fresh sources just to be sure I haven't screwed something. No difference. I don't understand for what the .ph suffix stands for and what the install procedure does in this phase, it seems doing some perl stuff. What's happening? Good question. I just did a make world, and it went fine. And the UDMA brokenness is gone again. Oh well, I screwed up my system so badly finally, swapper dumped core and I got crashes everytime the fsck hope to fix my filesystems, seems that I mixed different versions of binaries and kernel. I went with binary upgrade route and so far all works again, thought I haven't tried to do make world yet. Thanks for your reply, it's really my system which is screwed up. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird syscons keyboard behaviour
On Fri, Sep 17, 1999 at 02:45:08PM +0200, Soren Schmidt [EMAIL PROTECTED] wrote: prompt or during the kernel is probing devices) or while the keyboard driver is being initialized, you may see the problem. Hmm I've seen the problem where on "loose" the input at the loader prompt but it has always come back when syscons probes the keyboard. But I have also seen the other problem exactly two times, and the keyboard hasn't been touched at all those two times... I had written it of as a fluke in my screen/keyboard/mouse switchbox... I always get such behavior when I touch keyboard just before the autoboot begins countdown. It's reliably repeatable, but nothing I care much about. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ccd build failure
On Thu, Sep 23, 1999 at 09:19:18AM -0700, Matthew Dillon [EMAIL PROTECTED] wrote: : :[Insert semi-nasty message about how people should really be testing :their changes before they commit, how it is a blatant disregard for :basic human rigths not to do so etc etc etc] : :Poul-Henning I just forgot to commit a header file. Sorry about that. I test all of my code, unlike you Poul. Insert nasty message about how people shouldn't post idiotic comments. It's very unfortunate to see you both often opposite. Two hard millstones doesn't do good flour. It's a very old proverb. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Repeatable panic in current, cause Netscape
promisc 0
Script started on Wed Sep 29 11:07:23 1999
myhakas# gdb -k /sys/compile/Myhakas/kernel.debug vmcore.1
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"...
SMP 2 cpus
IdlePTD 3211264
initial pcb at 298e00
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0102; cpuid = 1; lapic.id = 0100
fault virtual address = 0x17
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc017ad2c
stack pointer = 0x10:0xc8e5fca0
frame pointer = 0x10:0xc8e5fcf0
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 = 666 (netscape)
interrupt mask = none - SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0102; cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks... 19 5 1 done
dumping to dev #da/0x20001, offset 0
dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109
108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83
82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54
53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25
24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:281
281 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:281
#1 0xc0155349 in panic (fmt=0xc026de2f "page fault")
at ../../kern/kern_shutdown.c:531
#2 0xc0236400 in trap_fatal (frame=0xc8e5fc60, eva=23)
at ../../i386/i386/trap.c:907
#3 0xc0236071 in trap_pfault (frame=0xc8e5fc60, usermode=0, eva=23)
at ../../i386/i386/trap.c:800
#4 0xc0235ce7 in trap (frame={tf_fs = 1048600, tf_es = 16, tf_ds = 16,
tf_edi = -924451276, tf_esi = -924451236, tf_ebp = -924451600,
tf_isp = -924451700, tf_ebx = -1061078179, tf_edx = -924572480,
tf_ecx = 7, tf_eax = 7, tf_trapno = 12, tf_err = 0,
tf_eip = -1072190164, tf_cs = 8, tf_eflags = 66198,
tf_esp = -1061078179, tf_ss = 0}) at ../../i386/i386/trap.c:426
#5 0xc017ad2c in namei (ndp=0xc8e5fe34) at ../../kern/vfs_lookup.c:91
#6 0xc0c12eb5 in ?? ()
#7 0xc0c11c55 in ?? ()
#8 0xc0236642 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 677678720, tf_esi = 677674201, tf_ebp = -1077946400,
tf_isp = -924450860, tf_ebx = 677674201, tf_edx = -1077946464,
tf_ecx = -1077946464, tf_eax = 106, tf_trapno = 12, tf_err = 2,
tf_eip = 677666503, tf_cs = 31, tf_eflags = 582, tf_esp = -1077946504,
tf_ss = 47}) at ../../i386/i386/trap.c:1056
#9 0xc02241b1 in Xint0x80_syscall ()
#10 0x28644564 in ?? ()
(kgdb) quit
myhakas# exit
exit
The same Netscape and X did work for last 3 weeks. The same Netscape did
work for at least last 2 months. I see it's a known problem accordingly
to lists.
Thanks
--
Vallo Kallaste
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Repeatable panic in current, cause Netscape
\nosfMenu:ShiftKeyF10\nosfMenuBar:KeyF10", ni_loopcnt = 0,
ni_cnd = {cn_nameiop = 64, cn_flags = 3370394816,
cn_proc = 0x7, cn_cred = 0xc8e5ff00, cn_pnbuf = 0x0,
cn_nameptr = 0xc8e8076c "\034læÈ4\bèÈ\b\aèÈ\030\aèÈ",
cn_namelen = -1071400512, cn_hash = 3224050208, cn_consume = -924450988}}
(kgdb) print cnp
$3 = (struct componentname *) 0xc8e5fe5c
(kgdb) print *cnp
$4 = {cn_nameiop = 64, cn_flags = 3370394816, cn_proc = 0x7,
cn_cred = 0xc8e5ff00, cn_pnbuf = 0x0,
cn_nameptr = 0xc8e8076c "\034læÈ4\bèÈ\b\aèÈ\030\aèÈ",
cn_namelen = -1071400512, cn_hash = 3224050208, cn_consume = -924450988}
(kgdb) print namei_zone
$5 = (struct vm_zone *) 0xc0b3ed80
(kgdb) print *namei_zone
$6 = {zlock = {lock_data = 0}, zitems = 0xc8df3000, zfreecnt = 16,
zfreemin = 4, znalloc = 19713, zkva = 0, zpagecount = 0, zpagemax = 0,
zmax = 0, ztotal = 16, zsize = 1024, zalloc = 2, zflags = 0, zallocflag = 2,
zobj = 0x0, zname = 0xc025801f "NAMEI", znext = 0xc0756980}
(kgdb) print auio
$7 = {uio_iov = 0xc8e5ff80, uio_iovcnt = -1062066432, uio_offset = 3235033088,
uio_resid = -1059934208, uio_segflg = 677674201, uio_rw = 3233885669,
uio_procp = 0x28647cd9}
(kgdb) quit
myhakas# exit
exit
Thanks
--
Vallo Kallaste
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Repeatable panic in current, cause Netscape
On Wed, Sep 29, 1999 at 07:42:50PM +0200, Marcel Moolenaar [EMAIL PROTECTED] wrote: The latest -current system crashes while starting up Netscape, mine version is 4.61, Linux one. It's fully repeatable in my case. I got crash dump and here's my dmesg and gdb trace: Make sure that the linux module is as uptodate as the kernel is. As a rule of thumb: rebuild the modules you use when you rebuild the kernel. If that doesn't help in this case, continue debugging :-) Thankyou for tip, discovered that my modules are from Sept 17 and I know I've compiled the kernel several times in between 17 to date. Quick look at /usr/sup/src-all/checkouts.cvs:. gives me the 26'th. I must have done cvsup for src-all by accident. Sorry for false alert, my Netscape works now as usual. Thanks -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup core dumps
On Tue, Oct 05, 1999 at 08:33:54AM +0200, Mark Murray [EMAIL PROTECTED] wrote: I've seen a few reports that CVSup has suddenly started dumping core on a segmentation violation under -current, but I need more information. For starters, I would like to know whether the static binary (ports/net/cvsup-bin) works or not under the very latest -current on the i386. Could somebody please check that and report back to the list? I can't sacrifice my i386 -current machine to the cause right now. The static binary seems to be OK an a 3-day-old CURRENT. And as opposite, the cvsup 16.0 static a.out binary, downloaded a day ago from ftp.freebsd.org dumps reliably core for me. I'm sorry, can't provide any info yet because it's my home machine. The machine runs also 3 day old -current, perhaps with deviation of some 12 hours or so, can't remember. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-19991012-CURRENT
On Tue, Oct 19, 1999 at 09:56:49AM +1000, Brett White [EMAIL PROTECTED] wrote: Has anyone tried using the 4.0-19991012-CURRENT snapshot? I need to confirm that this snapshot is a "good one" before I update my 3.3R installation to it in a last ditch effort to compile USB modem support into the kernel. I have our mp3 machine running this snapshot, doing quite heavy NFS serving and of course runs Samba. The machine has one 37GB IBM ide disk and 32MB of memory, processor is good old 150Mhz PPro. No problems so far. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (vinum?) lockups in strategy routines?
On Fri, Oct 29, 1999 at 07:22:58AM -0700, Alfred Perlstein [EMAIL PROTECTED] wrote: On Fri, 29 Oct 1999, #Michael Class wrote: Hello, just another datapoint. I just installed two new IBM DPTA-343740 discs into my System at home. They are configured with striping in vinum. Within a day I got two solid lockups with the new ata-drivers. After that I switchied to the old wd-driver. Everythings works fine since then. Same here, I just compiled a new system with the old wd driver instead of ata and i'm happily crunching along. Sometime between now and october 6th something went wrong? I'm using one same IBM disk for our mp3 machine with new ata driver. The machine is an old PPro 150 with 440FX chipset and PIIX3 controller, runs 19991012 snapshot. No need for special setting for harddisk and mostly no problems, except some "disk contact lost" messages. Heh, I just considered to upgrade the OS a bit to get rid of these "disk contact lost" errors, but now I'm warned :) -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: calcru() warnings...
On Thu, Nov 25, 1999 at 10:38:56AM +1030, Daniel O'Connor [EMAIL PROTECTED] wrote: On 24-Nov-99 Poul-Henning Kamp wrote: I still hear reports of sporadic calcru() warnings. If any of you see these, could you try to see if they correlate to the uptime of the machine in question ? I have had them for Seti@Home occasionally. The system hadn't been up for more than 24 hours. Its a dual PII-350. Same here, running setiathome means that I can find such processes after a day or so: 4 ?? DL -2341043:-35.26 (bufdaemon) The ``calcru'' messages aren't strictly necessary, such things happen without them also. Dual PIII-500, two seti processes. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: imake-4 build broken
On Sat, Oct 12, 2002 at 08:31:52PM -0400, Mike Barcroft [EMAIL PROTECTED] wrote: I don't really understand how this is happening. The uses of NSIG are also conditionalized. If _POSIX_SOURCE is defined, line 46 should not be visible. What rev is your /usr/include/sys/cdefs.h and /usr/include/signal.h? /usr/include/sys/cdefs.h: $FreeBSD: src/sys/sys/cdefs.h,v 1.67 2002/10/07 02:50:44 mike Exp $ $FreeBSD: src/sys/sys/cdefs.h,v 1.67 2002/10/07 02:50:44 mike Exp $ /usr/include/signal.h: $FreeBSD: src/include/signal.h,v 1.19 2002/10/06 21:54:08 mike Exp $ The same error happens several times down the road of XFree86-4 port compilation and all the problematic source files contain #include signal.h surrounded by _POSIX_SOURCE. Removing this _POSIX_SOURCE thing got the XFree86-4 port compile to me. I've just committed the rest of my signal.h-related patches, can you update your system and let me know if I've fixed the problem. Yes it's fixed now, I've restarted the ports building from scratch and it did over imake-4 just minutes ago. No info for the whole XFree86-4 yet, but it's the same I guess. Thanks for your hard work -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Crash upon exit from X
Hi
Yesterday I had crash just after exit from X and KDE3. Sources and
kernel are from 24 Oct. ~9:30 GMT.
Script started on Thu Oct 31 09:45:34 2002
bash-2.05b# gdb -k /usr/src/sys/i386/compile/Myhakas-5.0-SMP/kernel.debug /usr/c
rash/vmcore.1
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0239d18
stack pointer = 0x10:0xd6710c20
frame pointer = 0x10:0xd6710c58
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 = 13 (swi6: tty:sio clock)
trap number = 12
panic: page fault
cpuid = 0; lapic.id =
boot() called on cpu#0
syncing disks... panic: bwrite: buffer is not busy???
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 5d3h47m33s
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at ../../../kern/kern_shutdown.c:223
223 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:223
#1 0xc0236e8a in boot (howto=260) at ../../../kern/kern_shutdown.c:355
#2 0xc0237147 in panic () at ../../../kern/kern_shutdown.c:508
#3 0xc027e982 in bwrite (bp=0xce4b8680) at ../../../kern/vfs_bio.c:796
#4 0xc027f039 in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1085
#5 0xc033b1bf in ffs_fsync (ap=0xd6710a20) at ../../../ufs/ffs/ffs_vnops.c:236
#6 0xc033a4e9 in ffs_sync (mp=0xc4067200, waitfor=2, cred=0xc13c4e80,
td=0xc0436d40) at vnode_if.h:612
#7 0xc02939e8 in sync (td=0xc0436d40, uap=0x0)
at ../../../kern/vfs_syscalls.c:130
#8 0xc0236a6b in boot (howto=256) at ../../../kern/kern_shutdown.c:264
#9 0xc0237147 in panic () at ../../../kern/kern_shutdown.c:508
#10 0xc03a89a2 in trap_fatal (frame=0xd6710be0, eva=0)
at ../../../i386/i386/trap.c:846
#11 0xc03a8652 in trap_pfault (frame=0xd6710be0, usermode=0, eva=0)
at ../../../i386/i386/trap.c:760
#12 0xc03a80c2 in trap (frame=
{tf_fs = -697237480, tf_es = -1071382512, tf_ds = -1069088752, tf_edi =
-1005778304, tf_esi = 1, tf_ebp = -697234344, tf_isp = -697234420, tf_ebx = 0, tf_edx
= 0, tf_ecx = 8192, tf_eax = 8192, tf_trapno = 12, tf_err = 0, tf_eip = -1071407848,
tf_cs = 8, tf_eflags = 66054, tf_esp = -1005778060, tf_ss = 134217742}) at
../../../i386/i386/trap.c:446
#13 0xc0391328 in calltrap () at {standard input}:99
#14 0xc0243ffc in realitexpire (arg=0xc40d0a80)
at ../../../kern/kern_time.c:531
#15 0xc0244655 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:195
#16 0xc0223f54 in ithread_loop (arg=0xc13c6600)
at ../../../kern/kern_intr.c:535
#17 0xc0222e14 in fork_exit (callout=0xc0223d80 ithread_loop, arg=0x0,
frame=0x0) at ../../../kern/kern_fork.c:860
(kgdb) quit
bash-2.05b# exit
exit
Script done on Thu Oct 31 09:46:04 2002
--
Vallo Kallaste
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
sparc64 bootable snapshot iso availability?
Hi I have opportunity to test sparc64 installer and if time permits, OS itself for upcoming weekend. The boxes are Netra T1's with two different ethernet interfaces (2 eri and 4 qfe) and as usual SCSI disks and ATAPI cdrom. I did short sweep over sparc64 documents available online and found that ata(pi) and sysinstall aren't supported, but those times are over now I guess? From where I can download ISO image and give it a try? I don't mean to use 5.0-20021031-SNAP, sysinstall has been reworked extensively in the last days, that's it. Thanks -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
DISABLE_PSE DISABLE_PG_G still needed?
Hi The kernel compiled from yesterday sources and with the abovementioned options disabled will not finish make -j2 buildworld on P4. Dies with bus error: /usr/src/lib/libc/gen/termios.c: In function `tcgetpgrp': /usr/src/lib/libc/gen/termios.c:104: internal error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. Are those options still needed? They are commented out in NOTES and shouldn't be necessary, right? -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /dev/acd*t* no longer available in -current?
On Fri, Nov 15, 2002 at 04:29:50AM -0800, Kris Kennaway [EMAIL PROTECTED] wrote: Don't you think it makes more sense for the kernel to start off with more restrictive permissions, and have the administrator determine whether more restrictive permissions are appropriate? Actually no I dont. The security aware admin will know (or should that be should know :) ) what to do to make a system secure. That's a particularly uncompelling argument. Yes. For what it's worth, I think that system should be airtight out of the box and the consequences for average desktop user (as I am) clearly documented in handbook. Users who will not read the fine documentation fully deserve the pain. Moreover, they probably will not make a way as fine FreeBSD user in a long run. Be sure you read the following line: IMHO -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing /boot/modules from BSD.root.dist
On Fri, Nov 15, 2002 at 03:35:18PM +0200, Ruslan Ermilov [EMAIL PROTECTED] wrote: Anyone objects to this patch? Yes - this is the only place to put modules which are not built as part of the kernel, for example /usr/ports/comms/ltmdm. This port puts it under /usr/local/share/ltmdm/ltmdm.ko. This is bad practice. The /boot/modules directory was discussed long time ago and meant to third-party modules as I remember. That's why I haven't discarded it locally. Even if ports have rules to install everything under ports-dir they should install kernel modules into /boot/modules. Otherwise it's a sphagetti to manage. The IMHO thing applies to this message also quite well. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DISABLE_PSE DISABLE_PG_G still needed?
On Fri, Nov 15, 2002 at 02:59:32AM -0800, Terry Lambert [EMAIL PROTECTED] wrote: The kernel compiled from yesterday sources and with the abovementioned options disabled will not finish make -j2 buildworld on P4. Dies with bus error: /usr/src/lib/libc/gen/termios.c: In function `tcgetpgrp': /usr/src/lib/libc/gen/termios.c:104: internal error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. Are those options still needed? They are commented out in NOTES and shouldn't be necessary, right? What happens if you add those options? Does it still crash? Just finished '-j2 buildworld' and it did well with kernel which had the options enabled. Therefore I suppose that those options are still absolutely necessary to make use of -current system. These options should be uncommented in NOTES and added to GENERIC otherwise new users will be trapped. All old -current users have those options probably enabled for a while, that's because there are no complaints. Actually, I'm not complaining, just testing out the bad things I have encountered in the near past. This darn 5.0-RELEASE is nearing way too fast considering the state of -current today. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DISABLE_PSE DISABLE_PG_G still needed?
On Fri, Nov 15, 2002 at 09:55:52AM -0500, Wesley Morgan [EMAIL PROTECTED] wrote: On Fri, 15 Nov 2002, Vallo Kallaste wrote: Just finished '-j2 buildworld' and it did well with kernel which had the options enabled. Therefore I suppose that those options are still absolutely necessary to make use of -current system. These This may be a bit overstated. I removed those options from my kernel a few weeks ago and have no problems at all. Are you certain the problem is not specific to a particular CPU? Sorry, this can be CPU specific, but I'm not sure. I'll try to reproduce it on my home P2 system and P3-SMP lying under my desk at work. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DISABLE_PSE DISABLE_PG_G still needed?
console at flags 0x100 on isa0 sc0: VGA 5 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 1.000 msec acpi_cpu: CPU throttling enabled, 8 steps from 100% to 12.5% ata1-slave: timeout waiting for interrupt ata1-slave: ATAPI identify failed ad0: 19541MB Maxtor 2B020H1 [39703/16/63] at ata0-master UDMA100 acd0: CDROM CD-540E at ata1-master UDMA33 Mounting root from ufs:/dev/ad0s3a ports/misc/cpuid: eax ineax ebx ecx edx 0002 756e6547 6c65746e 49656e69 0001 0f13 0001080a 3febfbff 0002 665b5001 00397040 8000 8004 8001 8002 20202020 20202020 20202020 20202020 8003 65746e49 2952286c 6c654320 6e6f7265 8004 20295228 20555043 30372e31 007a4847 Vendor ID: GenuineIntel; CPUID level 2 Intel-specific functions: Version 0f13: Type 0 - Original OEM Family 15 - Pentium 4 Extended family 0 Model 1 - Stepping 3 Reserved 0 Brand index: 10 [not in table] Extended brand string: Intel(R) Celeron(R) CPU 1.70GHz CLFLUSH instruction cache line size: 8 Hyper threading siblings: 1 Feature flags 3febfbff: FPUFloating Point Unit VMEVirtual 8086 Mode Enhancements DE Debugging Extensions PSEPage Size Extensions TSCTime Stamp Counter MSRModel Specific Registers PAEPhysical Address Extension MCEMachine Check Exception CX8COMPXCHG8B Instruction APIC On-chip Advanced Programmable Interrupt Controller present and enabled SEPFast System Call MTRR Memory Type Range Registers PGEPTE Global Flag MCAMachine Check Architecture CMOV Conditional Move and Compare Instructions FGPAT Page Attribute Table PSE-36 36-bit Page Size Extension CLFSH CFLUSH instruction DS Debug store ACPI Thermal Monitor and Clock Ctrl MMXMMX instruction set FXSR Fast FP/MMX Streaming SIMD Extensions save/restore SSEStreaming SIMD Extensions instruction set SSE2 SSE2 extensions SS Self Snoop HT Hyper Threading TM Thermal monitor TLB and cache info: 50: Instruction TLB: 4KB and 2MB or 4MB pages, 64 entries 5b: Data TLB: 4KB and 4MB pages, 64 entries 66: 1st-level data cache: 8KB, 4-way set assoc, 64 byte line size 40: No 2nd-level cache, or if 2nd-level cache exists, no 3rd-level cache 70: Trace cache: 12K-micro-op, 4-way set assoc 39: unknown TLB/cache descriptor -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DISABLE_PSE DISABLE_PG_G still needed?
On Fri, Nov 15, 2002 at 03:50:47PM -0800, Terry Lambert [EMAIL PROTECTED] wrote: Sorry, this can be CPU specific, but I'm not sure. I'll try to reproduce it on my home P2 system and P3-SMP lying under my desk at work. How much memory do these systems have? The P4 system has 128MB, P3-SMP has 512MB and P2 has 380MB. As you can guess, the P4 system has been given by my employer, hehe ;-) -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DISABLE_PSE DISABLE_PG_G still needed?
On Fri, Nov 15, 2002 at 11:45:16AM -0500, Robert Watson [EMAIL PROTECTED] wrote: Does this apply generally to all P4's, or just a subset? If all, it may be we want to add a P4-workaround to GENERIC so that P4's work better ouf of the box. If it's a select few, I wonder if there's some way to test for the problem early in the boot... One of the recurring themes here has (a) been P4 processors, and (b) been a fear that because of timing changes introduced by the DISABLE_FOO flags, the real bug is still there, but less visible in the tests people are running. Certainly doesn't happen on my P3-500 SMP system. I've finished two buildworlds without any problems. As everyone seems to think that it happens only on P4's, I'm not going to try it on old P2-400. That's all I can provide, happens reliably (for months now) on my P4 and doesn't happen with P3. 5.0-RELEASE definitely needs a fix. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Warning messages emitted by disklabel -r
Hi Just did the following: dd if=/dev/zero of=/dev/da1 bs=1k count=512 #remove old stuff fdisk -I da1#cover the entire disk with one da1s1 slice fdisk da1 #check what's put there disklabel -rw da1s1 auto#install virgin disklabel disklabel -e da1s1 #add partition e:, copied over from c: disklabel da1s1 #all is ok disklabel -r da1s1 #spits out 4 lines of warnings?? Why disklabel complains when using the -r switch? It didn't before. Yes I haven't used fdisk(8) and disklabel(8) for a long time. Possibly related to GEOM, as far as I understand. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Warning messages emitted by disklabel -r
On Mon, Nov 18, 2002 at 11:23:14AM -0800, Julian Elischer [EMAIL PROTECTED] wrote: what are the warnings? what version of disklabel.c? Here's script output: Script started on Mon Nov 18 21:46:07 2002 bash-2.05b# dd if=/dev/zero of=/dev/da1 bs=1k count=512 512+0 records in 512+0 records out 524288 bytes transferred in 0.532715 secs (984181 bytes/sec) bash-2.05b# fdisk -I da1 *** Working on device /dev/da1 *** fdisk: invalid fdisk partition table found bash-2.05b# fdisk da1 *** Working on device /dev/da1 *** parameters extracted from in-core disklabel are: cylinders=554 heads=255 sectors/track=63 (16065 blks/cyl) parameters to be used for BIOS calculations are: cylinders=554 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 8899947 (4345 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 553/ head 254/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED bash-2.05b# disklabel -rw da1s1 auto bash-2.05b# disklabel -e da1s1 [output stripped intentionally] bash-2.05b# disklabel da1s1 # /dev/da1s1c: type: SCSI disk: da1s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 553 sectors/unit: 8899947 rpm: 7200 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 88999470unused0 0 # (Cyl.0 - 553*) e: 889994704.2BSD0 0 0 # (Cyl.0 - 553*) bash-2.05b# disklabel -r da1s1 # /dev/da1s1c: type: SCSI disk: da1s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 553 sectors/unit: 8899947 rpm: 7200 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 8899947 63unused0 0 # (Cyl.0*- 553*) e: 8899947 634.2BSD0 0 0 # (Cyl.0*- 553*) partition c: partition extends past end of unit Warning, partition c doesn't start at 0! Warning, An incorrect partition c may cause problems for standard system utilities partition e: partition extends past end of unit bash-2.05b# ident /usr/src/lib/libc/gen/disklabel.c /usr/src/lib/libc/gen/disklabel.c: $FreeBSD: src/lib/libc/gen/disklabel.c,v 1.16 2002/08/16 15:33:20 bmilekic Exp $ bash-2.05b# ident /usr/src/sbin/disklabel/disklabel.c /usr/src/sbin/disklabel/disklabel.c: $NetBSD: disksubr.c,v 1.13 2000/12/17 22:39:18 pk $ $FreeBSD: src/sbin/disklabel/disklabel.c,v 1.63 2002/11/18 04:58:11 julian Exp $ bash-2.05b# exit exit Script done on Mon Nov 18 21:49:08 2002 -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Warning messages emitted by disklabel -r
On Mon, Nov 18, 2002 at 01:00:37PM -0800, Julian Elischer [EMAIL PROTECTED] wrote: [snip] In pre-geom days we had a realhack (TM) that would fiddle the label if you read it direct from the disk. In other words it fixed it to always look (u relative I think) even if you read it from the raw disk, even if it was in absolute form on the disk. Geom (quite correctly) declared this to be a gross hack that it would not perpetuate. As a result, when you read the raw label you see the uncorrected version. It's possible that disklabel itself should be extended to figure out if the label is absolute of relative and DTRT. Ok, seems not to be over my head. It's confusing to users, that's the only thing I have to say now. Thank you for explanation.0 -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Weird ACPI related problem
Hi Get the live-5.0-CURRENT-20021119-JPSNAP.iso from current.freebsd.org and burn it. Boot from it (P4), watch it complaining about unable to load acpi.ko module at bootup. Exit from fixit mode and get fully up and running. Change to /boot/kernel and kldload acpi.ko... BOOM Total hang, interrupts doesn't work (numlock is not responsive) and which is most weird, loading acpi.ko triggers following on the console: swap_pager_getswapspace: failed Is it intended behaviour or what I'm missing here? -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Upgrade to DP2 went smooth on old P133
Hi I'm quite excited after upgrading my old P133 adsl gateway running -stable to DP2. Because the machine has cdrom which doesn't grok CD-RW and floppy interface is broken :), certainly there isn't anything to report about sysinstall, floppies et al. But it had spare IDE disk and I did fully manual install to it by untarring base and crypto sets. After recovering the original configuration from backups, installing bootstrap and setting right disk to boot via boot0cfg (all under -stable), it did come up as nothing has changed. PPPoE works, firewall (ipfw) works, everything is as cool as it can be. Thank you all for your hard work! -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
smbfs problems
Hi Some info about failures I see: root:vallo# kldstat Id Refs AddressSize Name 13 0xc010 3be9e0 kernel 21 0xc04bf000 480d4acpi.ko root:vallo# smbutil view //vallo@poweredge smbutil: smb_lib_init: can't find kernel module It means kernel module will not be loaded upon first use of smbfs. This can and can not be considered as bug. root:vallo# cd /boot/kernel root:vallo# kldload smbfs.ko root:vallo# kldstat Id Refs AddressSize Name 18 0xc010 3be9e0 kernel 21 0xc04bf000 480d4acpi.ko 31 0xc17dc000 2smbfs.ko root:vallo# smbutil view //vallo@poweredge Password: ShareType Comment --- IPC$ pipe Remote IPC work disk toolsdisk usersdisk private disk test disk Now the writing part: After creating 5MB file using /dev/urandom, I'm trying to copy it over to users/vallo smb share mounted at /mnt, which fails. The copy is interruptible using Ctrl-C. Examination at NT4 server shows 0 byte file. Umount of /mnt fails with device busy. Umount -f /mnt fails to return prompt, but after interrupting the smbfs is unmounted. There is no kernel messages or something in syslog. The copy operation returns failure ~3 seconds after start. root:vallo# mount /dev/ad0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ad0s1d on /usr (ufs, NFS exported, local, soft-updates) procfs on /proc (procfs, local) myhakas:/opt/src-current/src on /usr/src (nfs) myhakas:/opt/src-current/ports on /usr/ports (nfs, read-only) //VALLO@POWEREDGE/USERS on /mnt (smbfs) root:vallo# cd /home/vallo/ root:vallo# dd if=/dev/urandom of=testfile bs=1m count=5 5+0 records in 5+0 records out 5242880 bytes transferred in 0.518492 secs (10111784 bytes/sec) root:vallo# cp testfile /mnt/vallo/ cp: /mnt/vallo/testfile: Operation timed out ^C root:vallo# root:vallo# ls -la /mnt/vallo ^C root:vallo# root:vallo# umount /mnt umount: unmount of /mnt failed: Device busy root:vallo# umount -f /mnt ^C root:vallo# mount /dev/ad0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ad0s1d on /usr (ufs, NFS exported, local, soft-updates) procfs on /proc (procfs, local) myhakas:/opt/src-current/src on /usr/src (nfs) myhakas:/opt/src-current/ports on /usr/ports (nfs, read-only) root:vallo# -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs problems
[snip] After creating 5MB file using /dev/urandom, I'm trying to copy it over to users/vallo smb share mounted at /mnt, which fails. The copy is interruptible using Ctrl-C. Examination at NT4 server shows 0 byte file. Umount of /mnt fails with device busy. Umount -f /mnt fails to return prompt, but after interrupting the smbfs is unmounted. There is no kernel messages or something in syslog. The copy operation returns failure ~3 seconds after start. [snip] Sorry forgot to add one detail. Althought dd'ing the same file to smbfs mount works, it'll sometimes modify the file being copied (size is different). It doesn't happen reliably, sometimes the file is copied fine, sometimes not. At the times the file isn't copied right there's an error message: root:vallo# dd if=testfile of=/mnt/vallo/test1 dd: /mnt/vallo/test1: Bad address 9356+0 records in 9355+0 records out 4789760 bytes transferred in 20.350003 secs (235369 bytes/sec) root:vallo# ls -la /mnt/vallo/ total 4710 drwxr-xr-x 1 root wheel16384 Nov 21 15:10 . drwxr-xr-x 1 root wheel16384 Jan 1 1970 .. -rwxr-xr-x 1 root wheel 4789760 Nov 21 15:10 test1 -rwxr-xr-x 1 root wheel0 Nov 21 14:52 testfile root:vallo# ls -la /home/vallo/testfile -rw-r--r-- 1 root wheel 5242880 Nov 21 14:52 /home/vallo/testfile It seems to me that adding conv=sync flag to dd removes the abovementioned failure case. 10 tries of dd with this flag added did fine. root:vallo# dd if=testfile of=/mnt/vallo/test1 conv=sync 10240+0 records in 10240+0 records out 5242880 bytes transferred in 24.295283 secs (215798 bytes/sec) root:vallo# ls -la /mnt/vallo/ total 5152 drwxr-xr-x 1 root wheel16384 Nov 21 15:13 . drwxr-xr-x 1 root wheel16384 Jan 1 1970 .. -rwxr-xr-x 1 root wheel 5242880 Nov 21 15:13 test1 -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/geom geom_slice.c
On Wed, Nov 20, 2002 at 09:19:01PM +0100, Poul-Henning Kamp [EMAIL PROTECTED] wrote: This should fix a large part of the disklabel -e bogosity people have been seeing. In message [EMAIL PROTECTED], Poul-Henning Kamp writes: phk 2002/11/20 12:12:52 PST Modified files: sys/geom geom_slice.c Log: Remember to update the providers idea of its size when we reconfigure a slice child. Approved by:re Revision ChangesPath 1.27 +1 -0 src/sys/geom/geom_slice.c root:vallo# ident /usr/src/sys/geom/geom_slice.c /usr/src/sys/geom/geom_slice.c: $FreeBSD: src/sys/geom/geom_slice.c,v 1.27 2002/11/20 20:12:52 phk Exp $ root:vallo# fdisk ad0 *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=39703 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=39703 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 16382961 (7999 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 15/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 16383024, size 16383024 (7999 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 15/ sector 63 The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED root:vallo# disklabel ad0s1 # /dev/ad0s1c: type: ESDI disk: ad0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 39703 sectors/unit: 40020624 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 52428804.2BSD 2048 16384 32776 # (Cyl.0 - 520*) b: 524288 524288unused0 0 # (Cyl. 520*- 1040*) c: 163829610unused0 0 # (Cyl.0 - 16252*) d: 15334385 10485764.2BSD 2048 16384 28552 # (Cyl. 1040*- 16252*) Warning, partition c doesn't cover the whole unit! Warning, An incorrect partition c may cause problems for standard system utilities root:vallo# disklabel -r ad0s1 # /dev/ad0s1c: type: ESDI disk: ad0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 39703 sectors/unit: 40020624 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 524288 634.2BSD 2048 16384 32776 # (Cyl.0*- 520*) b: 524288 524351unused0 0 # (Cyl. 520*- 1040*) c: 16382961 63unused0 0 # (Cyl.0*- 16252*) d: 15334385 10486394.2BSD 2048 16384 28552 # (Cyl. 1040*- 16252*) Warning, partition c doesn't start at 0! Warning, partition c doesn't cover the whole unit! Warning, An incorrect partition c may cause problems for standard system utilities root:vallo# -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On Thu, Nov 21, 2002 at 03:03:48PM -0500, John Baldwin [EMAIL PROTECTED] wrote: It's the PSE and PGE, John. Are you sure you won't agree to not disclose, so I can tell you what's happening? Bosko has a patch which he will give you if you ask him for it that (mostly) works around the problem. DP2 shipped with DISABLE_PSE and DISABLE_PG_G in GENERIC. I know because I put them there. Is it any help to know that my problems on P4 stopped after enabling DISABLE_PSE? Initially I had both of these enabled, but seems that one is enough. Just FYI. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On Fri, Nov 22, 2002 at 10:57:42AM -0500, John Baldwin [EMAIL PROTECTED] wrote: It has an effect: writing CR3 or a TSS resulting in a changed CR3 will not invalidate TLB entries with the G flag set, if PGE is set in CR4. I know what PG_G does, Terry. My question is that if DISABLE_PG_G has no effect on the _problems_ people are having. I have now definitive answer for _my_ case and environment. Just finished full package build for my workstation bundle port (92 ports), including XFree-4, KDE3, mozilla-devel and whatnot. It all went very well running kernel which had: DISABLE_PSE enabled DISABLE_PG_Gdisabled Are you interested of the reverse? Can it be that enabling DISABLE_PSE incorporates DISABLE_PG_G somehow? -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On Fri, Nov 22, 2002 at 03:25:15PM -0800, Terry Lambert [EMAIL PROTECTED] wrote: I have now definitive answer for _my_ case and environment. Just finished full package build for my workstation bundle port (92 ports), including XFree-4, KDE3, mozilla-devel and whatnot. It all went very well running kernel which had: DISABLE_PSE enabled DISABLE_PG_Gdisabled Are you interested of the reverse? Can it be that enabling DISABLE_PSE incorporates DISABLE_PG_G somehow? I give up. You guys obviously still think it's a software problem that you can characterize and fix using binary elimination to find the offending code. It's not. You got me wrong. I'm user and do not know and don't want to know about any CPU architecture and bugs. But I've got problems and simply trying to provide any data possible to gather by myself. Either CPU hardware or software bug, fine. You're claiming to know the bug and possible fix, but don't want to publish it, fine. I don't want to think about it because with my knowledge this is going to nowhere and only wasting my time. Things you see above are my results using consistent testing environment, take it or leave it. I'll stick with DISABLE_PSE enabled and DISABLE_PG_G disabled for the time being. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 Fatal Trap
On Sat, Nov 23, 2002 at 02:50:36AM -0800, Terry Lambert [EMAIL PROTECTED] wrote: Either CPU hardware or software bug, fine. You're claiming to know the bug and possible fix, but don't want to publish it, fine. I do not object to publication of code that embodies a workaroun to the poblem, so long as that workaround doesn;t specifically disclose the root cause problem itself. Yes I know it from your previous posts. For some reason you don't want that description and analysis of (possible) hardware bug comes public (at this time). Whatever your reasons are, you certainly have your rights for it, no problem from my viewpoint. I don't want to think about it because with my knowledge this is going to nowhere and only wasting my time. Things you see above are my results using consistent testing environment, take it or leave it. I'll stick with DISABLE_PSE enabled and DISABLE_PG_G disabled for the time being. I'll make the same offer of a fixed kernel binary, for testing purposes, if you are willing to test two: one to be sure that there is no serendipity involved, and one with the patch. We can skip the first one if you can give me a CVS date or tag to checkout to get code identical to code you have locally, which has the problem. E.g. if you have a local copy of the CVS tree, and you check out with a date tag of, say, last Wednesday, and the kernel you build from that coe ha he problem, then I can check out identical code, patch it, and give you a binary to try. I'll take this route, at least it can prove something objective (for me). Of course I have to trust you to not send me kernel binary with simply those damned options enabled... or with something interesting in it... The sources the kernel is built are checked out from freebsd.dk.freebsd.org at: *default date=2002.11.21.13.56.00 -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 release import?
On Fri, Nov 22, 2002 at 10:03:50AM -0800, David O'Brien [EMAIL PROTECTED] wrote: I would like to see GCC 3.2.1 release be our 5.0-R compiler. However, the GCC 3.2.1 release date kept slipping and in fact was nebulous for a while. The same for our 5.0-R. So this has made it hard to decided what to do. I suspect GCC 3.2.1-R wouldn't cause us much or any problems. But the question is does the project as a whole have the resources to deal with any problems that do creap up? It is a hard judgement call. Somebody with knowledge and time should generate patches, so it's possible to at least test and report problems (or success). Given that enough people give it a try and report, there's possibility for import, IMHO. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 release import?
On Sat, Nov 23, 2002 at 02:52:27PM -0800, Terry Lambert [EMAIL PROTECTED] wrote: Somebody with knowledge and time should generate patches, so it's possible to at least test and report problems (or success). Given that enough people give it a try and report, there's possibility for import, IMHO. But who will bell the cat? I vote for Snuffles. Don't understand. Some inside joke or something based on US centric TV? What are you trying to tell me? Remember I'm not native. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 release import?
On Sat, Nov 23, 2002 at 10:06:52PM -0800, Terry Lambert [EMAIL PROTECTED] wrote: But who will bell the cat? I vote for Snuffles. Don't understand. Some inside joke or something based on US centric TV? What are you trying to tell me? Remember I'm not native. 1930's/1940's cartoon character, Snuffles, the mouse. Was in a lot of cartoons. Played the Why? game that children play, to the annoyance of his chosen victim, and the amusement of the people. One story was a script based on the Aesop's Fable about belling the cat. Here is a short reprise: 1)All of the mice decided that Something Needs To Be Done About The Cat(tm) 2)They had a big meeting 3)Finally, one mouse, who no one listened to very often, suggests that they put a bell around its neck, so they will be able to tell whic it's coming, and escape, to live in peace, in their mousey ways 4)No one wants to bell the cat; it's a perfect idea, which lacks for implementation, and there are no potential implementors to take the risk on behalf of the group In the cartoon version, at this point, the mouse who made the suggestion is volunteered by his comrades for the deadly duty (Snuffles). Heh, OK :-) I'm also quite sure that gcc3.2.1 release will not find it's way to 5.0 and understand the technical points taken to guard this position. That's why I put possibility and IMHO at the end of my sentence. A patch will be good to have nevertheless, so we can test things out even if it's not going to 5.0-RELEASE. So this boils down to simple question of time, necessity and willingness to do the patch. Let's end this thread. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Harry Potter and the Disappearing Disklabel
On Fri, Nov 29, 2002 at 06:45:48PM +0200, Vallo Kallaste [EMAIL PROTECTED] wrote: I've seen one post similar to this, but not much else. I think maybe the UFS2 problem had to do with Kirk's recent changes, but the disklabel issue... I'm wary to reboot my machine! What in the hell could be causing this? I'm tempted to point the finger at GEOM, but hate to say anything like that. Same here today. I had system from Nov 21, both world and kernel. Did buildworld, installworld and then rebooted with old 21Nov kernel. At boot fsck whined about /usr (ad0s1d) partition and died with incorrect superblock message leaving the system in single user. The /usr partition has UFS2 filesystem. Why the partition had to be fsck'ed? The system went down cleanly after build-installworld. I tried to fsck_ffs -b 32 /usr but it didn't like it either and died with signal 8. Floating point exception. I know the next alternate superblock _is_ there at 32, because I converted /usr to UFS2 only few days ago and remember the newfs command exactly. After the failed attempt of fsck_ffs -b 32 suddenly some fragment of recent -current talk popped in my mind and I remember there was talk about mount command doing some trickery. So I went with mount -t ufs -f /dev/ad0s1d /usr and voila the data was there. I'm almost sure that I can reproduce it, because I have the / and /usr dumps from the time I did UFS2 converting and the live-current cd burnt for this purpose (JPSNAP). It's possible to go back in time and fully restore the system as it were before. One thought about the initial fsck issue. The system uptime was 8 days and almost all the time it did compilation/clearing up of my workstation bundle port (~100 individual port). I did it because of stability issues before, to control the kernel with only DISABLE_PSE enabled. Because space in /usr is limited on this system, the /usr/ports is mounted over ro NFS, but WRKDIRPREFIX, DISTDIR and PACKAGES are set to local filesystem, so /usr periodically filled up to ~95% and drained quickly (several concurrent rm -rf's) to 30%. This is quite a stress to softupdates and filesystem in general, so if there's a bug this explains the need for fsck after boot. Just a thought. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Harry Potter and the Disappearing Disklabel
On Fri, Nov 29, 2002 at 09:41:56AM -0500, Wesley Morgan [EMAIL PROTECTED] wrote: Yesterday morning I was having some trouble with XFree consuming much more cpu time than necessary... A truss showed that some kind of shared memory issue going on, but also froze my system hard. After rebooting (kernel was from Nov 26 or 27) fsck could not check my one dirty UFS2 partition. Had to newfs and mtree to recreate /var. No big deal, and I saved an image of it beforehand. After rebooting, there was... NOTHING. GRUB errored out and wouldn't boot. Nothing could see my partitions. After a minimal 4.7-R install (DP2 disklabel whined about offsets and some other STRANGE error messages, so I went with 4.7) on a small fat32 partition, I discovered that the disklabel was empty. Had to edit it by hand... Booted up fine, made a backup, rebooted, and nothing. Not only was there NOTHING, but the disklabel on the new 4.7 install had vanished as well. This time the disklabel had to be recreated with -w -r AND the boot blocks had to be reinstalled. I've seen one post similar to this, but not much else. I think maybe the UFS2 problem had to do with Kirk's recent changes, but the disklabel issue... I'm wary to reboot my machine! What in the hell could be causing this? I'm tempted to point the finger at GEOM, but hate to say anything like that. Same here today. I had system from Nov 21, both world and kernel. Did buildworld, installworld and then rebooted with old 21Nov kernel. At boot fsck whined about /usr (ad0s1d) partition and died with incorrect superblock message leaving the system in single user. The /usr partition has UFS2 filesystem. Why the partition had to be fsck'ed? The system went down cleanly after build-installworld. I tried to fsck_ffs -b 32 /usr but it didn't like it either and died with signal 8. Floating point exception. I know the next alternate superblock _is_ there at 32, because I converted /usr to UFS2 only few days ago and remember the newfs command exactly. After the failed attempt of fsck_ffs -b 32 suddenly some fragment of recent -current talk popped in my mind and I remember there was talk about mount command doing some trickery. So I went with mount -t ufs -f /dev/ad0s1d /usr and voila the data was there. I'm almost sure that I can reproduce it, because I have the / and /usr dumps from the time I did UFS2 converting and the live-current cd burnt for this purpose (JPSNAP). It's possible to go back in time and fully restore the system as it were before. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: console problem
On Sun, Dec 01, 2002 at 04:07:32PM -0500, Chuck Robey [EMAIL PROTECTED] wrote: I've been on vacation for the last week, so I haven't been watching -current like a good boy should, but I've suddenly been seeing a serious problem, and it *might* not have been reported, and seeing as code freeze is almost here, it's worth risking a bit of embarrassment, I guess. Anyhow, it's the console, it's been locking up. I just retried it with a kernel cvsupped not 2 hours ago, and it's still here. All the vty's lock up, and once even froze the PC speaker (beeping annoyingly at me). There don't seem to be any hung processes. I can use X, and I can also ssh into the box, so it's the console only. Can't switch to different vty's, and the one i'm on is frozen, no response to any keys. It seems to come on more quickly if I do something serious, like a buildkernel. Happened once on startup, but even though rc hadn't finished, I WAS able to ssh into the box and shut it down (indicating to me that rc had finished, just no response from the console). Machine is a 2 processor Tyan Thunder, 1G memory, two Athlons, scsi disks and eide both. It's interesting that you seem to have almost same machine as I have. Tyan Thunder with SCSI and ATA disks, SMP and the only difference seems to be memory size, 1GB vs. 512MB. Not counting network interfaces and such. I've also lost console after rebuild yesterday. The kernel from Nov. 29 works. Mine (console) not locks up but is simply missing from the start. Otherwise system is up and running. I don't think it's coincidence, something is broken and related to the Tyan mobos we have. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: console problem
On Mon, Dec 02, 2002 at 09:04:22AM -0500, Chuck Robey [EMAIL PROTECTED] wrote: Machine is a 2 processor Tyan Thunder, 1G memory, two Athlons, scsi disks and eide both. It's interesting that you seem to have almost same machine as I have. Tyan Thunder with SCSI and ATA disks, SMP and the only difference seems to be memory size, 1GB vs. 512MB. Not counting network interfaces and such. I've also lost console after rebuild yesterday. The kernel from Nov. 29 works. Mine (console) not locks up but is simply missing from the start. Otherwise system is up and running. I don't think it's coincidence, something is broken and related to the Tyan mobos we have. Are you using the on-board video? I have an extra video card, and had to reflash the board because before reflash, I used to have this problem. It went away after reflash, and your references to the mobo reminded me. Tonight, I'll see if the video just goes back to the onboard card. I'm not aware of any Tyan Thunder mobos which have onboard integrated video. I have addon AGP video card, Matrox G400 with 32MB of memory and single head. Umm, I made mistake identifying your board as similar to mine, sorry. I _had_ Tyan Thunder (S1836 variety), but it's been replaced long ago with Tyan Thunderbolt, S1837UANG. The original burned down because of faulty current regulator on the mb and took one of my processors together in the process. I'll not forget it, even after the current mb has been working fine for two and half years. Sorry about confusion. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: console problem
On Mon, Dec 02, 2002 at 10:33:55AM -0800, David O'Brien [EMAIL PROTECTED] wrote: On Mon, Dec 02, 2002 at 04:33:27PM +0200, Vallo Kallaste wrote: I'm not aware of any Tyan Thunder mobos which have onboard integrated video. They *all* do. (meaning all the Tyan dual-K7 Thunders) Sorry about confusion, I was so bound to my Thunder(bolt). The S183[67] are Slot1 boards. Seems that marketing buzzword thunder got the water turbid once again. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
unable to use boot0cfg
Hi I'm using both -current and -stable on the same machine, very common. Boot0cfg has -s [12345] flag to set the slice to boot on and it has been working so far. Beginning from Dec 1, I'm unable to set the slice: root:vallo# boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5 1023: 15:63 63 16382961 2 0x00 1023:255:63 0xa5 1023: 15:63 16383024 16383024 version=1.0 drive=0x80 mask=0xf ticks=182 options=packet,update,nosetdrv default_selection=F1 (Slice 1) root:vallo# boot0cfg -v -s 2 ad0 boot0cfg: /dev/ad0: Operation not permitted root:vallo# disklabel -W ad0 disklabel: /dev/ad0: Operation not permitted This is probably related to recent (re)work to protect disk labels, but I'm not authoritative. This is not a fair way to stick me to -current :-) -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
success report of gcc3.2.1
-1.2b_3,1The open source, standards compliant web browser mpg123-0.59r_8 Command-line player for mpeg layer 1, 2 and 3 audio mplayer-gtk-0.90.0.10_1 High performance media player that supports many formats nasm-0.98.33,1 General-purpose multi-platform x86 assembler nmap-3.00 Port scanning utility for large networks open-motif-2.2.2_1 Motif X11 Toolkit (industry standard GUI (IEEE 1295)) pango-1.0.5 An open-source framework for the layout and rendering of i1 pcre-3.9Perl Compatible Regular Expressions library perl-5.6.1_11 Practical Extraction and Report Language perl-5.8.0_3Practical Extraction and Report Language pkgconfig-0.13.0An utility used to retrieve information about installed lib png-1.2.5 Library for manipulating PNG images procmail-3.22_1 A local mail delivery agent python-2.2.2_2 An interpreted object-oriented programming language qt-3.0.5_5 A C++ X GUI toolkit sdl-1.2.4_1 Cross-platform multi-media development API (developm. vers. t1lib-1.3.1 A Type 1 Rasterizer Library for UNIX/X11 tiff-3.5.7 Tools and library routines for working with TIFF images unclutter-8 Remove idle cursor image from screen unzip-5.50 List, test and extract compressed files in a ZIP archive urlview-0.9_1 URL extractor/launcher utf8locale-1.4 UTF-8 locales support videogen-0.21 A tool for calculating XFree86 modelines vim-6.1.262 Vi workalike, with many additional features vnc-3.3.5 Display X and Win32 desktops on remote X/Win32/Java display w3m-m17n-0.3.2.1+20021107 A pager/text-based WWW browser with multilingualization sup wget-1.8.2_1Retrieve files from the 'net via HTTP and FTP win32-codecs-011002.0.0.90pre7 Huge compilation of Win32 binary codecs, including MPEG-4(D wrapper-1.0_2 Wrapper for XFree86-4 server xanim-2.80.2Play most popular animation formats and show pictures xmms-1.2.7_3X Multimedia System --- An audio player with a Winamp GUI xpaint-2.6.6A simple paint program xpdf-2.00 Display PDF files, and convert them to other formats zip-2.3_1 Create/update ZIP files compatible with pkzip -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla-devel port on current
On Fri, Dec 06, 2002 at 10:19:23AM -0800, James Satterfield [EMAIL PROTECTED] wrote: mozilla-devel port fails to build on current. I would imagine this is already known, but I haven't seen any posts on the mailing list. I've built it yesterday together with a lots of other stuff. Using other -march values than i686 is unofficially claimed to be unsupported (kan@freebsd). As others I'll bet the -march=p4 is causing problems, i686 works for me. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla-devel port on current
On Fri, Dec 06, 2002 at 10:26:24PM -0500, Alexander Kabaev [EMAIL PROTECTED] wrote: On Fri, 6 Dec 2002 23:26:52 +0200 Vallo Kallaste [EMAIL PROTECTED] wrote: I've built it yesterday together with a lots of other stuff. Using other -march values than i686 is unofficially claimed to be unsupported (kan@freebsd). As others I'll bet the -march=p4 is causing problems, i686 works for me. The only thing I claimed was that using -march=p4 and other options which imply SSE2 with gcc 3.2.x is asking for trouble. Judging by the number of bugfixes that were committed to GCC mainline for SSE2 related problems, I am not that far off base. AFAIK, none of those bugfixes made it back to GCC 3.2.x branch. Ok, this is a good claim and making it public will be even better. The p4 optimisation is known to be problematic and users should be notified before they'll shoot the foot off. IMO it will be a good idea to add some logic into appropriate global makefile, to notify users. It's long time problem now and comes up periodically in the lists. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Crash upon exit from X
Hi
This is at least third crash I've had in the last months. It's
related to exiting from X, after switching back to text console,
there's usual message waiting for X server to shut down or
somesuch and then crash follows. Sources and kernel are from Dec 5
08:19 GMT. All ports are very recently rebuilt, including
XFree86-4.
Script started on Mon Dec 9 10:25:27 2002
bash-2.05b# gdb -k /usr/src/sys/i386/compile/Myhakas-5.0-SMP/kernel.debug /usr/
crash/vmcore.3
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02424e8
stack pointer = 0x10:0xd68b6c20
frame pointer = 0x10:0xd68b6c58
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 = 13 (swi6: tty:sio clock)
trap number = 12
panic: page fault
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 2d19h32m5s
Dumping 511 MB
[CTRL-C to abort] [CTRL-C to abort] 16 32 48 64 80 96 112 128 144 160 176 192 208 224
240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496
---
#0 doadump () at ../../../kern/kern_shutdown.c:232
232 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc023f4da in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc023f797 in panic () at ../../../kern/kern_shutdown.c:517
#3 0xc0289562 in bwrite (bp=0xce598490) at ../../../kern/vfs_bio.c:796
#4 0xc0289c19 in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1085
#5 0xc03506af in ffs_fsync (ap=0xd68b6a20) at ../../../ufs/ffs/ffs_vnops.c:236
#6 0xc034f8f9 in ffs_sync (mp=0xc41b1e00, waitfor=2, cred=0xc1514e80,
td=0xc0440140) at vnode_if.h:612
#7 0xc029e80b in sync (td=0xc0440140, uap=0x0)
at ../../../kern/vfs_syscalls.c:138
#8 0xc023f0bb in boot (howto=256) at ../../../kern/kern_shutdown.c:273
#9 0xc023f797 in panic () at ../../../kern/kern_shutdown.c:517
#10 0xc03befb2 in trap_fatal (frame=0xd68b6be0, eva=0)
at ../../../i386/i386/trap.c:844
#11 0xc03bec62 in trap_pfault (frame=0xd68b6be0, usermode=0, eva=0)
at ../../../i386/i386/trap.c:758
#12 0xc03be752 in trap (frame=
{tf_fs = -1071579112, tf_es = -1003159536, tf_ds = -695533552, tf_edi =
-1000705576, tf_esi = 1, tf_ebp = -695505832, tf_isp = -695505908, tf_ebx = 0, tf_edx
= 0, tf_ecx = 8192, tf_eax = 8192, tf_trapno = 12, tf_err = 0, tf_eip = -1071373080,
tf_cs = 8, tf_eflags = 66054, tf_esp = -1000705332, tf_ss = 134217742}) at
../../../i386/i386/trap.c:445
#13 0xc03a7398 in calltrap () at {standard input}:99
#14 0xc024df7c in realitexpire (arg=0xc45a71d8)
at ../../../kern/kern_time.c:544
#15 0xc024e5d5 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:195
#16 0xc022ca74 in ithread_loop (arg=0xc1516600)
at ../../../kern/kern_intr.c:535
#17 0xc022b934 in fork_exit (callout=0xc022c8a0 ithread_loop, arg=0x0,
---Type return to continue, or q return to quit---
frame=0x0) at ../../../kern/kern_fork.c:866
(kgdb) quit
bash-2.05b# exit
exit
Script done on Mon Dec 9 10:25:49 2002
--
Vallo Kallaste
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
another crash in series
Hi
I see it's been discussed in the -current list.. This is with kernel
and sources from Dec 9 09:09 GMT. Happens _only_ after leaving KDE
and shutting down X. Considering the fact that I'm starting and
shutting down X/KDE once a day (startx), it's quite easy to
reproduce. Kernel and vmcore available on request.
Script started on Thu Dec 12 10:24:27 2002
bash-2.05b# gdb -k /sys/i386/compile/Myhakas-5.0-SMP/kernel.debug vmcore.5
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0242508
stack pointer = 0x10:0xd68b6c20
frame pointer = 0x10:0xd68b6c58
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 = 13 (swi6: tty:sio clock)
trap number = 12
panic: page fault
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 2d5h21m2s
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at ../../../kern/kern_shutdown.c:232
232 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc023f4fa in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc023f7b7 in panic () at ../../../kern/kern_shutdown.c:517
#3 0xc0289582 in bwrite (bp=0xce5d3278) at ../../../kern/vfs_bio.c:796
#4 0xc028ac76 in vfs_bio_awrite (bp=0xce5d3278)
at ../../../kern/vfs_bio.c:1643
#5 0xc035073a in ffs_fsync (ap=0xd68b6a20) at ../../../ufs/ffs/ffs_vnops.c:258
#6 0xc034f919 in ffs_sync (mp=0xc41b1a00, waitfor=2, cred=0xc1514e80,
td=0xc0440100) at vnode_if.h:612
#7 0xc029e83b in sync (td=0xc0440100, uap=0x0)
at ../../../kern/vfs_syscalls.c:138
#8 0xc023f0db in boot (howto=256) at ../../../kern/kern_shutdown.c:273
#9 0xc023f7b7 in panic () at ../../../kern/kern_shutdown.c:517
#10 0xc03bef92 in trap_fatal (frame=0xd68b6be0, eva=0)
at ../../../i386/i386/trap.c:844
#11 0xc03bec42 in trap_pfault (frame=0xd68b6be0, usermode=0, eva=0)
at ../../../i386/i386/trap.c:758
#12 0xc03be732 in trap (frame=
{tf_fs = -1071579112, tf_es = -1001914352, tf_ds = -695533552, tf_edi =
-64200, tf_esi = 1, tf_ebp = -695505832, tf_isp = -695505908, tf_ebx = 0, tf_edx =
0, tf_ecx = 8192, tf_eax = 8192, tf_trapno = 12, tf_err = 0, tf_eip = -1071373048,
tf_cs = 8, tf_eflags = 66054, tf_esp = -63956, tf_ss = 134217742})
at ../../../i386/i386/trap.c:445
#13 0xc03a7378 in calltrap () at {standard input}:99
#14 0xc024df9c in realitexpire (arg=0xc465c1d8)
at ../../../kern/kern_time.c:544
#15 0xc024e5f5 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:195
#16 0xc022ca94 in ithread_loop (arg=0xc1516600)
at ../../../kern/kern_intr.c:535
#17 0xc022b954 in fork_exit (callout=0xc022c8c0 ithread_loop, arg=0x0,
frame=0x0) at ../../../kern/kern_fork.c:866
(kgdb) quit
bash-2.05b# exit
exit
Script done on Thu Dec 12 10:24:41 2002
--
Vallo Kallaste
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: VAX tinderbox failure
This is cross-compiled, isn't it? Or you guys have too much patience otherwise. On Tue, Dec 17, 2002 at 09:47:52AM -0800, Matt Dillon [EMAIL PROTECTED] wrote: -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/vax/obj/home/tinderbox/vax/src/vax/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Dec 15 10:07:13 PST 2002 -- === xe /home/tinderbox/vax/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/vax/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/vax/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /home/tinderbox/vax/obj/home/tinderbox/vax/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/vax/src. *** Error code 1 Stop in /home/tinderbox/vax/src. _ For the best comics, toys, movies, and more, please visit http://www.tfaw.com/?qt=wmf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
On Thu, Dec 19, 2002 at 08:46:44PM -0800, Sam Leffler [EMAIL PROTECTED] wrote: #ifndef PFIL_HOOKS #error You must specify PFIL_HOOKS when using ipfilter #endif Unfortunately there's no way that I know to express this if ipfilter is loaded as a module. Duh, there'll probably be unresolved symbols if you try to load ipl.ko w/o PFIL_HOOKS defined in the kernel. Yes, and this undefined symbols message will make no sense from user perspective. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ssh authentification broken, only public keys work
On Fri, Dec 20, 2002 at 08:27:53AM +0100, Martin Blapp [EMAIL PROTECTED] wrote: Since yesterday I cannot login to my CURRENT machine anymore after a world and reboot ... I really hope this doesn't got MFC'd to RELENG_5_0 ... debug1: Calling cleanup 0x8061180(0x0) debug1: PAM: cleanup debug3: mm_pam_query: waiting for MONITOR_ANS_PAM_QUERY debug3: mm_request_receive_expect entering: type 45 debug3: mm_request_receive entering Then the connection times just out. The ssh_msg_send: write message appears without debug mode. Note that I did run mergemaster ... pam files are all on their place. Somthing is completly screwed up. Disable ChallengeResponseAuthentication, set it to no and you'll have ssh again. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
On Fri, Dec 20, 2002 at 08:30:42AM -0800, Terry Lambert [EMAIL PROTECTED] wrote: Vallo Kallaste wrote: On Thu, Dec 19, 2002 at 08:46:44PM -0800, Sam Leffler [EMAIL PROTECTED] wrote: #ifndef PFIL_HOOKS #error You must specify PFIL_HOOKS when using ipfilter #endif Unfortunately there's no way that I know to express this if ipfilter is loaded as a module. Duh, there'll probably be unresolved symbols if you try to load ipl.ko w/o PFIL_HOOKS defined in the kernel. Yes, and this undefined symbols message will make no sense from user perspective. Then fix it. The fix is trivial: [description of possible fix snipped] As I've stated several times and as you most certainly know I'm not developer. What are you trying to accomplish by the phrase then fix it? Put me down, eh? I have encountered this problem several times and for the first time the message about unresolved symbol(s) made no sense and forced me to do time consuming searches over the 'Net to get a clue what's going on. Will we want to get possible users using FreeBSD or will we want argue about it to death? The users get bored and move on, that's it. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
On Fri, Dec 20, 2002 at 11:29:19PM +0200, Vallo Kallaste vallo wrote: Yes, and this undefined symbols message will make no sense from user perspective. Then fix it. The fix is trivial: [description of possible fix snipped] As I've stated several times and as you most certainly know I'm not developer. What are you trying to accomplish by the phrase then fix it? Put me down, eh? I have encountered this problem several times and for the first time the message about unresolved symbol(s) made no sense and forced me to do time consuming searches over the 'Net to get a clue what's going on. Will we want to get possible users using FreeBSD or will we want argue about it to death? The users get bored and move on, that's it. Uh, sorry Terry. I was lightly drunk (just got back from party) yesterday when I wrote this. Althought the writing has some right points (from my side of view), the overall tone is rude. I'm so sorry. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current lockups
On Mon, Mar 06, 2000 at 08:27:18PM +0100, Dave Boers [EMAIL PROTECTED] wrote: I'm interested in the fix, of course :-) But where to start looking? I've had three lockups so far (none before january 2000) but I didn't find anything that reliably triggered it. I had a lockup yesterday while stress-testing new SMP machine. Tyan motherboard with Intel GX chipset, 256MB of memory, one 20GB IBM UDMA66 disk, but running at UDMA33. All power management disabled completely in the BIOS. I was doing massive parallel compiling of GENERIC kernels. Let the machine doing this overnight and on the morning the console had about 20 'microuptime() went backwards' messages, I was able to switch vty's but not login, machine responded to pings, no disk activity. I'm using ata driver and only one unusual kernel option HZ=1000. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kde2pre: is it FreeBSD or Kde fault?
Hello Donn Miller suggested to look at the development KDE, because of my need for small but still usable graphical browser. I got the sources by CVSup, bare minimum only, then compiled with standard system compiler. It wasn't smooth but finally it works, well, the main reason I compiled it was Konqueror and this app just doesn't work with www. Call it bad luck or whatever but that's what I see: kio (KIOConnection): read cmd 100 kio (KIOConnection): finished reading cmd 100 kio (KIOJob): dispatch 100 konqueror: SLOT_DATA 6487 konqueror: BEGIN... KHTMLWidget::begin() kio (Scheduler): Scheduler has now 1 jobs 0x8136000 konqueror: BROWSER JOB http://www.matti.ee/img/taust.gif /usr/libexec/ld-elf.so.1: /usr/local/kde/lib/libkhtml.so.3: Undefined symbol "__eh_rtime_match" So I have question, is it Kde or FreeBSD fault, nm on the libkhtml.so.3 library shows me the "undefined symbol" is there: myhakas:vallo$ nm /usr/local/kde/lib/libkhtml.so.3 | grep eh_rtime_match U __eh_rtime_match Thanks -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kde2pre: is it FreeBSD or Kde fault?
On Thu, Mar 02, 2000 at 03:03:33PM +0100, Theo van Klaveren [EMAIL PROTECTED] wrote: You actually get as far as kdebase? My builds quit in kdelibs in arts/flow/stereofftscope.cpp with the following message (verbatim): stereofftscope.cpp:~80: sorry, not implemented. (something about symbol to big for symbol table). Recompile all your sources with -fhuge-objects. I finished the build with make -k, but I have no arts :( I suspect this to be a FreeBSD problem, as the Linux guys don't seem to have this (or it would have been fixed in the previous two/three weeks). I noticed the same problem with libkhtml, b.t.w. Yes, I had the same problem with arts. I'm not particularly interested about arts, only Konqueror. As I understand the gcc info one needs to recompile all c++ libraries with -fhuge-objects, then all applications which depend on them. Too much to me, don't have needed knowledge. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Crash in currtprio, after dumping no operating system..
Hello Just about a hour ago cvsupped the latest sources and built world because of fixes in vinum. I have /usr mounted to striped volume over three disks. After reboot I had crash just a moment after the setiathome processes started, the crash was in currtprio, I have two seti processes sheduled to start with idprio 31. I did dump and rebooted, then found myself sitting behind my desk and watching No Operating System Found prompt. Boot blocks are there, my machine BIOS reports it. Sorry can't provide more information as I need to recover first. Anyway, this is very strange and I want to warn anybody first. My system is SMP, three identical SCSI disks hooked up to the onboard AIC-7896. Three 256MB swap partitions, separate root on the first disk and /usr on the striped volume. Thanks -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crash in currtprio, after dumping no operating system..
On Fri, 3 Mar 2000, Vallo Kallaste wrote: sheduled to start with idprio 31. I did dump and rebooted, then found myself sitting behind my desk and watching No Operating System Found prompt. Boot blocks are there, my machine BIOS reports it. Sorry can't provide more information as I need to recover first. Anyway, this is very strange and I want to warn anybody first. My system is SMP, three identical SCSI disks hooked up to the onboard AIC-7896. Three 256MB swap partitions, separate root on the first disk and /usr on the striped volume. After some work with fixit floppy and sysinstall I can say for sure the dump procedure wiped off disklabel and probably some 256MB of following space. The other two disks have healthy disklabel in place. The first disk has only bootblocks and slice table now (DOS partition table). Damn. I'm very pleased that I did backup four days ago.. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crash in currtprio, after dumping no operating system..
On Thu, Mar 02, 2000 at 07:29:51PM -0500, Peter Dufault [EMAIL PROTECTED] wrote: Was it a panic saying currtprio != curproc-p_rtprio.prio? That was my fault, it's out now. Any SMP kernel from earlier today should re-sup. Sorry can't remember details, I was bound to getting crashdump especially for this purpose ;-) I'm up now, lost some saved emails but who cares, hehe. Uh, I never ever found myself in so immediate need for backup. I'm going to re-cvsup and build another world, let's see what happens now. But, anybody out there who knows _why the hell_ the dump routine wiped off my disklabel? Here's the disklabel, it's exactly same as before. Please note I have 256MB of memory and also 256MB swap partition, can it be that the dump was larger than the swap? I can't imagine how it can happen or why the routine doesn't check for space, if so. The other two disks are exactly same, except they have 64MB unused space at the end. # /dev/rda0c: type: SCSI disk: da0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 553 sectors/unit: 8899947 rpm: 7200 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 131072 5242884.2BSD 1024 819216 # (Cyl. 32*- 40*) b: 5242880 swap# (Cyl.0 - 32*) c: 88999470unused0 0 # (Cyl.0 - 553*) e: 8244587 655360 vinum# (Cyl. 40*- 553*) -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crash in currtprio, after dumping no operating system..
On Fri, Mar 03, 2000 at 03:23:17PM +1100, Bruce Evans [EMAIL PROTECTED] wrote: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 131072 5242884.2BSD 1024 819216 # (Cyl. 32*- 40*) b: 5242880 swap# (Cyl.0 - 32*) c: 88999470unused0 0 # (Cyl.0 - 553*) e: 8244587 655360 vinum# (Cyl. 40*- 553*) The dump fills up precisely the entire 'b' partition. Since the partition begins at offset 0, the dump overwrites the label at sector offset 1 and any bootblocks at sector offsets 0-15. This misconfiguration is handled for swapping but not for dumping. This shouldn't lose any data. Just restore the label from a backup and write new bootblocks. Thanks for clarifying, but now I have next question. Why sysinstall allows such misconfiguration? As I understand now the right way is start the disk with root partition not swap. The disklabel shown here was created with 4.0-2228-CURRENT sysinstall. It seems now I'm wrong but I always thought the best place for swap is the beginning of disk. Can you please confirm that the common practise is disklabel with root partition in the beginning of disk? Thanks -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: calcru / microuptime problem
On Mon, Mar 13, 2000 at 09:00:26PM +0100, Poul-Henning Kamp [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], "David E. Cross" writes: I have had these problems ever since upgrading to -current about a month ago. The kernel very regularly spews out messages like: Mar 13 14:23:39 gemini /kernel: calcru: negative time of -2663631 usec for pid 568 (sshd2) Disable APM in your bios and remove apm from your config. The 'microuptime() went backwards' happened to me also lately, week or so ago. Tyan mobo with GX chipset, power management disabled completely in the BIOS, no apm in kernel. Two PIII-550, one 20GB IBM disk (ATA). Same symptoms as above, heavy disk I/O, I was stress-testing the machine, except the machine hung for some unknown reason: I was able to switch vty's and ping the machine but not login, no disk I/O. I'm waiting for two 36GB IBM SCSI disks, which should arrive soon, then the next round without ATA is what I'm planning. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: calcru / microuptime problem
On Tue, Mar 14, 2000 at 04:40:43PM +1030, Daniel O'Connor [EMAIL PROTECTED] wrote: On 14-Mar-00 Vallo Kallaste wrote: in the BIOS, no apm in kernel. Two PIII-550, one 20GB IBM disk (ATA). Same symptoms as above, heavy disk I/O, I was stress-testing the machine, except the machine hung for some unknown reason: I was able to switch vty's and ping the machine but not login, no disk I/O. I'm waiting for two 36GB IBM SCSI disks, which should arrive soon, then the next round without ATA is what I'm planning. Do you have the latest BIOS rev? You mean for Tyan mobo? No, it's version 1.16b nongraphical AMIBIOS which come with board. I'm having exactly same board but with SCSI only configuration for my workstation which works without any problem for half a year now. Also SMP, two PIII-500. When the new disks arrive, well, I can try the new BIOS also. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0-current breaks building jpeg shared library
Hello Just did switchover to 5.0-current and noticed that building jpeg shared library doesn't work. Lots of X apps depend on jpeg shared library. The fix is very small, just edit patch-ac to include freebsd5* as well. Just FYI. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-current breaks building jpeg shared library
On Tue, Mar 14, 2000 at 08:19:24AM -0800, David O'Brien [EMAIL PROTECTED] wrote: On Tue, Mar 14, 2000 at 01:30:32PM +0200, Vallo Kallaste wrote: Just did switchover to 5.0-current and noticed that building jpeg shared This belongs in [EMAIL PROTECTED] *NOT* the freebsd-current list!!! Yes, I did bounce the mail to freebsd-ports as well. It's current thing also, no? Before people start emailing to this list perhaps they saw the message and can fix it. Sorry. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-current breaks building jpeg shared library
On Tue, Mar 14, 2000 at 01:31:39PM -0800, David O'Brien [EMAIL PROTECTED] wrote: It's current thing also, no? Not in the least. Specialized mailing lists exist to take the specialized traffic off the more general lists. Plus, the fix to your problem is to fix the port. The Ports team takes care of Ports. None of the Kernel hackers here are going to make any ports commits. Strange, I always thought the -current list is for general issues related to -current branch and for true kernel hackers exist -hackers. Okay, this isn't something worth discussing as I believe anybody running -current is able to fix such things and posting to -current isn't really necessary. Thanks -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FreeBSD: Konqueror fails to show WWW pages
Hi! The Konqueror built from sources of yesterday dies while trying to show WWW pages. I'm using FreeBSD 5.0-current now, but the problem was same about two weeks ago with 4.0-current. I tried to discuss the problem in freebsd-current mailing list, but almost no feedback so far. kio (KIOConnection): sendnow 67 konqueror: KonqRun::~KonqRun() kio (KIOConnection): read kio (KIOConnection): read cmd 109 kio (KIOConnection): finished reading cmd 109 kio (KIOJob): dispatch 109 kio (Scheduler): slave status kio (Scheduler): Slave = 0x8152c00 (PID = 12006) protocol = http host = www.matti.ee Not connected kio (KIOConnection): read kio (KIOConnection): read cmd 21 kio (KIOConnection): finished reading cmd 21 kio (KIOJob): dispatch 21 kio (KIOConnection): read kio (KIOConnection): read cmd 24 kio (KIOConnection): finished reading cmd 24 kio (KIOJob): dispatch 24 kio (KIOConnection): read kio (KIOConnection): read cmd 10 kio (KIOConnection): finished reading cmd 10 kio (KIOJob): dispatch 10 kio (KIOConnection): read kio (KIOConnection): read cmd 100 kio (KIOConnection): finished reading cmd 100 kio (KIOJob): dispatch 100 khtml: slotData: 4096 khtml: begin! kio (Scheduler): Scheduler has now 1 jobs 0x813a700 /usr/libexec/ld-elf.so.1: /usr/local/kde/lib/libkhtml.so.3: Undefined symbol "__eh_rtime_match" myhakas:vallo$ nm /usr/local/kde/lib/libkhtml.so.3 | grep __eh_* U __eh_alloc U __eh_rtime_match myhakas:vallo$ The cvsup collections I built were: qt-copy kde-common kdelibs kdebase kdenetwork kdesupport -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Deadlock with vinum raid5
On Sun, Apr 02, 2000 at 01:50:16AM +0200, Bernd Walter [EMAIL PROTECTED] wrote: Greg - I'm using vinums raid5 code since months now for FreeBSDs CVS-Tree on 7x 200M disks - it does not hang for me since a long time. The latest current I tested R5 well is from 19th March on alpha. That's shortly before PHKs changes - I don't beleave that it introduced something new. The only problem with R5 I know of is parity corruption because of a bug in lockrange() for which I've already send you a fix. Even it is a general bug it seems only to cause problems together with softupdates. Ops - I oversaw that this happened with a recent current. The best I can say is that it is likely that it happened after the 19th March. I got now crash under 4.0-RELEASE, with syncer and bufdaemon in the same vrlock state, pax in flswait. I was in single-user mode using pax to extract usr archive to newly created raid5 volume. I'm using NFS mount with flags -3i -r16384 -w16384 over 100Mbit full-duplex link, fxp driver on both sides. Note that I'm using stripe unit size 512k now, otherwise same. Here's handcopy of DDB messages: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc1e03ef4 stack pointer = 0x10:0xc0244a84 frame pointer = 0x10:0xc0244aa0 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 = Idle interrupt mask = bio kernel: type 12 trap, code=0 Stopped at complete_rqe+0x18: movl0x4(%eax),%edx db trace complete_rqeat complete_rqe+0x18 biodone at biodone+0x53 ad_interruptat ad_interrupt+0x2e2 ata_intrat ata_intr+0xca Xresume15() at Xresume15+0x2b --- interrupt, eip = 0xc020e5ae, esp = 0xc0244b54, ebp = 0 --- default_halt() at default_halt+0x2 I hook up serial console to get full traceback next time, but I don't have any knowledge for further analysis. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Deadlock with vinum raid5
On Sun, Apr 02, 2000 at 03:39:35PM +0200, Vallo Kallaste [EMAIL PROTECTED] wrote: I hook up serial console to get full traceback next time, but I don't have any knowledge for further analysis. Here's full traceback, environment is all same, except the filesystem is mounted with async (before it was default, which is nosync I guess): sh-2.03# cd /usr sh-2.03# pax -r -pe -f /mnt/usr.pax Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0fa0ef4 stack pointer = 0x10:0xc0244a84 frame pointer = 0x10:0xc0244aa0 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 = Idle interrupt mask = bio kernel: type 12 trap, code=0 Stopped at complete_rqe+0x18: movl0x4(%eax),%edx db trace complete_rqe(c1069020,c0f04000,c1882f00,0,c1882f00) at complete_rqe+0x18 biodone(c1069020,c0f04034,c1069020,c0ed4180,0) at biodone+0x53 ad_interrupt(c1882f00,0,0,c02051e5,c0ed4180) at ad_interrupt+0x2e2 ata_intr(c0ed4180,0,c00f0010,c0690010,0010) at ata_intr+0xca Xresume14() at Xresume14+0x2b --- interrupt, eip = 0xc020e5ae, esp = 0xc0244b54, ebp = 0 --- default_halt() at default_halt+0x2 db ps pid proc addruid ppid pgrp flag stat wmesg wchan cmd 40 cc3a5440 cd7470000 640 004006 3 getblk c62d1cd0 pax 15 cc3a5100 cd74d0000 115 000204 3 vinum c0fa0b68 vinum 6 cc3a55e0 cd7440000 1 6 004086 3wait cc3a55e0 bash 5 cc3a5780 cc3b20000 0 0 000204 3 vrlock 52f801 syncer 4 cc3a5920 cc3b0 0 0 100204 3 vrlock 582001 bufdaemon 3 cc3a5ac0 cc3ae0000 0 0 000204 3 psleep c026c3c0 vmdaemon 2 cc3a5c60 cc3ac0000 0 0 100204 3 psleep c0254df8 pagedaemon 1 cc3a5e00 cc3aa0000 0 1 004284 3wait cc3a5e00 init 0 c0274640 c02d20000 0 0 000204 3 sched c0274640 swapper db I can give access to my system which is connected over null-modem to this test box. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Deadlock with vinum raid5
On Sun, Apr 02, 2000 at 05:37:30PM +0200, Bernd Walter [EMAIL PROTECTED] wrote: I hook up serial console to get full traceback next time, but I don't have any knowledge for further analysis. You don't need a serial console to get further informations. You should compile the kernel with debug symbols and set dumpdev in rc.conf to get a crash dump. Are you for any chance running the NFS Server without nfsd? I expect them to be needed if you are serving vinum volumes. Yes, but I don't have space for crashdump and I can't build new kernel with limited memory usage because I don't have /usr filesystem up and running. Is there a way to limit memory usage without recompiling kernel? I can store 32MB crashdump at the moment, no separate /var filesystem because I thought 4.0-RELEASE will be stable enough for experimenting with vinum.. I don't have another 4.0-RELEASE or stable system but I'll try to build 4.0-R kernel on -current system. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Deadlock with vinum raid5
On Sun, Apr 02, 2000 at 06:16:43PM +0200, Bernd Walter [EMAIL PROTECTED] wrote: Do you see it only with R5 or also with other organisations? I don't have any problems with my own -current system which has striped volume over three UW SCSI disks. SCSI-only system, SMP. Sources from March 14. I had no problems with striped volume over two ATA disks in the first round with test box, then I added the two disks, configured raid5 and here we are 8-) -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Deadlock with vinum raid5
On Sun, Apr 02, 2000 at 09:07:33PM +0200, Bernd Walter [EMAIL PROTECTED] wrote: Just to clearify the things... Are these problems with 4.0-RELEASE with 4.0-STABLE or with 5.0-CURRENT? Here's the sequence of what I did: 1. I had i386 system with two 20GB IBM ATA disks and 5.0-current system built from March 31 sources. First I used striping over two disks and put /usr filesystem onto it, did overnight testing and all was well. 2. Same system, same sources plus two same disks. Now I tried raid5 over four disks and failed to extract pax archive, got deadlock, not panic. 3. Same system, downgraded to 4.0-RELEASE. Raid5 over four disks and I failed to extract pax archive, got panic. No softupdates. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP changes and breaking kld object module compatibility
On Mon, Apr 24, 2000 at 10:55:05PM -0400, "Brandon D. Valentine" [EMAIL PROTECTED] wrote: The number one excuse large third party server vendors use to justify use of NT over Linux on their high end SMP systems is the poor performance of Linux SMP. This is a tremendous opportunity for FreeBSD to take market share. People are seeing the virtues of free, open source operating systems in the server farm and providing top notch SMP support in FreeBSD will help to see that we make further inroads that the Linux guys do. If the BSDi code assists us in improving SMP performance and if the corporate backing helps our PR image, then we could be in for a fun ride. This is the time to start thinking in terms of "What can we do better?" or we're going to lose the battle. Sure, those changes could go into 5.x and be released when RELENG_5 is branched a year from now. But in this business, a year is 6 months too late. Think about that before you object to what appear to be vast improvements in the performance of the RELENG_4 branch while it is just getting off the ground. Fair enough, but as somebody (Greg Lehey if I recall) said it was taken about 5 years for Sun to develop fine SMP support and we can't expect to be faster. FreeBSD is quite behind of Linux on the SMP issues currently, Linux is somewhat behind of NT and NT, I believe, is still behind of Solaris for SMP. Actually, I don't know, because my Solaris 8 CD is still on the way :( -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP changes and breaking kld object module compatibility
On Mon, Apr 24, 2000 at 11:56:50PM -0700, Christopher Nielsen [EMAIL PROTECTED] wrote: Solaris is far and away better at SMP than NT. I haven't seen NT running on 64-cpu machines, and I certainly haven't seen it scaling very nearly linearly to ~20 CPUs (diminishing returns start to take effect around 22 cpus). Solaris has had this since at least 2.6 (when I last evaluated this) with 2.[78] adding greater stability and more features. You are speaking about SPARC arhitecture, aren't you? Actually we can't compare IA32 and 64-bit SPARC I think and after all I'm absolutely wrong person to discuss about SPARC so I shut up now :-) -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kde2pre: is it FreeBSD or Kde fault?
On Sun, Apr 30, 2000 at 09:50:36PM +0200, Jeroen Hogeveen [EMAIL PROTECTED] wrote: You can try to edit the libtool file in the kdelibs directory to set deplibs="$deplibs -lc -lgcc" (around line number 2600). This will link the __eh_rtime_match. I still get a nonworking khtm however.. : khtml (cache): CachedImage::ref() khtml (cache): Cache::notify() konqueror: KCrash: crashing crashRecursionCounter = 0 konqueror: KCrash: Appname = 0x8073fb0 apppath = 0x0 konqueror: Unable to start dr. konqi DCOP: unregister 'konqueror'kio (KIOConnection): read kio (kioslave): slavewrapper: Communication with app lost. Returning to slave pool. Thanks, I'll give it a try when I get time. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: db 1.85 -- 2.x or 3.x?
On Tue, May 02, 2000 at 08:52:11PM -0400, Garance A Drosihn [EMAIL PROTECTED] wrote: If this is an issue for some nntp software, perhaps that port (the freebsd 'port collection' port...) should build and use the newer version of db? Would that help whatever issue got you interested in this? The upcoming INN-2.3.0 port will need newer Berkeley DB for overview database, in case you specifically request support for it. The 3.0.55 version of Berkeley DB compiles out of the box on the -current as I tried it few days ago. But I think the port of 2.7.7 we have already is enough, althought haven't tried it myself. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
On Tue, May 23, 2000 at 11:06:38AM -0700, Manfred Antar [EMAIL PROTECTED] wrote: Not to change the subject ,but mptable causes a panic on my machine running current. If I revert back to a kernel compiled on the 13th of May everything works fine. I think there were some changes made to the SMP code on the 14th or 15th also the binutils were upgraded and I'm not sure what caused it. With a current kernel I get this when booting: Programming 24 pins in IOAPIC #0 AP #1 (PHY# 12) failed! panic y/n [y] panic: bye-bye mp_lock = 0001; cpuid = 0; lapic.id = Uptime: 0s I've just completed world and compiled new kernel and found that my system reboots right after showing about seven lines of usual boot messages. I've found that UP GENERIC works and UP custom kernel works but SMP is broken. It has to do something with last three days of commits, because my last working SMP kernel is from Friday 19'th. Running mptable on the UP kernel doesn't cause crash for my system. Reboot is totally silent so I don't have any other info, sorry, I've only thought it happens about same time as the APIC probe. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mpboot.s patch
On Wed, May 24, 2000 at 04:33:41AM +0200, [EMAIL PROTECTED] wrote: Try the enclosed patch. Thank you Tor! Your patch fixed the silent reboot problem I had after new binutils import. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can't make installworld :(
On Fri, Jun 09, 2000 at 01:53:35PM +0400, Hostas Red [EMAIL PROTECTED] wrote: I can't make installworld for some time with following message: vm/vm_object.h - vm/vm_object.ph vm/vm_page.h - vm/vm_page.ph vm/vm_pageout.h - vm/vm_pageout.ph vm/vm_pager.h - vm/vm_pager.ph vm/vm_param.h - vm/vm_param.ph vm/vm_prot.h - vm/vm_prot.ph vm/vm_zone.h - vm/vm_zone.ph vm/vnode_pager.h - vm/vnode_pager.ph *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/utils/h2ph. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/utils. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. *** Error code 1 Some manipulations with manual installation of perl didn't help. :( Any ideas? I had same problem in the past. Some person, can't recall his name, said that it's known problem and discussed in the lists. His advice was to search in list archives. I've never found the exact answer but probably my search was wrong. Perhaps you'll have better luck. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Random signals in {build,install}world recently?
Hi It seems to be a recent problem. The hardware is OK, both Windows XP (which I use very seldom) and Gentoo Linux do not exhibit any problems. Basically one will get random signals as I have got in build- and installworld. It's impossible to complete make -j2 buildworld on my machine, but sometimes non-parallel buildworld will do, only to die later in installworld. This is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and 1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it matters. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random signals in {build,install}world recently?
On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt [EMAIL PROTECTED] wrote: VKIt seems to be a recent problem. The hardware is OK, both Windows XP VK(which I use very seldom) and Gentoo Linux do not exhibit any VKproblems. VKBasically one will get random signals as I have got in build- and VKinstallworld. It's impossible to complete make -j2 buildworld on my VKmachine, but sometimes non-parallel buildworld will do, only to die VKlater in installworld. VKThis is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and VK1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it VKmatters. I have the same MB just with 1800+ processors. I had to reduce the CPU frequency by about 10% in the BIOS setup to get the machine stable. I assume the problem is actually the memory. I'm in doubt in this matter, because it's been absolutely stable so far and is as stable as before under Linux and XP. Also, my problems very much coincidence with some list traffic about the same problem, follow the thread: Subject: Seeing system-lockups on recent current Message-ID: [EMAIL PROTECTED] I also managed to panic the system after repeated attempts to get through the installworld (which all failed). The panic string is panic: pmap_enter: attempted pmap_enter on 4MB page and is also described by the message: Subject: panic: pmap_enter: attempted pmap_enter on 4MB page Message-ID: [EMAIL PROTECTED] I have debug kernel, but the system locked up after the message and I had to drive home and reset the system. All those problematic systems seem to be AMD based. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random signals in {build,install}world recently?
On Mon, Oct 20, 2003 at 04:38:32PM +0300, Vallo Kallaste [EMAIL PROTECTED] wrote: [snip all] Ok, following up my own email.. I went back to last known good kernel/world combination, which is from September 16. The next and problematic kernel/world pair is from September 30. So the problem was introduced between these dates. I've built world and kernel from Sep 16 sources 00:00:00 UTC and my system is solid again, it's the fourth make -j4 buildworld in a row now and the problem (signals and ICE's in buildworld, not pmap_enter) is gone. My cents towards resolving this problem.. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random signals in {build,install}world recently?
On Mon, Oct 27, 2003 at 02:46:03PM -0500, Andre Guibert de Bruet [EMAIL PROTECTED] wrote: On Tue, 21 Oct 2003, Vallo Kallaste wrote: I went back to last known good kernel/world combination, which is from September 16. The next and problematic kernel/world pair is from September 30. So the problem was introduced between these dates. Well, I have a system from the 25th that works just fine, we're looking between the dates of 9/25 - 9/30. It is fixed, grab newer sources. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
On Mon, Jun 02, 2003 at 11:36:18AM +0300, Petri Helenius [EMAIL PROTECTED] wrote: left behind. I am remis in not fixing it, but please understand that I also have quite a few other responsibilities, and I get paid $0 to work on RAIDframe. Not being a native english speaker I probably didnt understand that experimental equals broken. If that equation cannot be justified, then the release notes should have said has critical defects or broken, not just experimental. I appreciate the work you and everybody else puts in, it just does not make sense to have people go through the same hoops and hit the wall when that could be saved by a single line noting that that the wall exists. FreeBSD 5.x series is slowly progressing, but is nowhere near to production quality. As the things are currently, you simply waste your time. This is only my opinion and I don't want to offend anyone. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
On Mon, Jun 02, 2003 at 03:31:49PM +0300, Petri Helenius [EMAIL PROTECTED] wrote: FreeBSD 5.x series is slowly progressing, but is nowhere near to production quality. As the things are currently, you simply waste your time. This is only my opinion and I don't want to offend anyone. IMO, software does not magically get better but it must be actively being used and problems reported and fixed in reasonable time. So if 5.x never gets users it never gets production quality. As do I, but I initially thought you needed stable platform. I vaguely remember your mails about some network related things etc. which seemed to indicate such need. I've sent you personal reply. Sorry. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: terminfo man page
On Wed, Jun 18, 2003 at 02:33:57PM -0400, Guy Middleton [EMAIL PROTECTED] wrote: I put this on comp.unix.bsd.freebsd.misc, but I'll ask here too. Is there any reason for the terminfo man page? It's a good man page, a very stylish and well-written man page, but it's wrong. It says the terminfo files are in /usr/share/misc/terminfo (they're not there). They do get installed into /usr/local/share/misc/terminfo as part of the ncurses port. Could we just remove the man page from the base system? No, please. Better install terminfo database into /usr/share/misc/terminfo and be done with it. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE crash
On Wed, Jun 25, 2003 at 06:20:33PM +0200, Ian Freislich [EMAIL PROTECTED] wrote: About 4.5 minutes after rebooting with a SCHED_ULE kernel (I give ULE a go every few months), top started looking really wierd (the CPU % just kept on accumulating for each process). Before dnetc started, httpd showed 17% CPU, but the system was supposedly 100% idle at the time according to top. Then dnetc started and things got wierd. panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0x38 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01e094d stack pointer = 0x10:0xce772be4 frame pointer = 0x10:0xce772bf4 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 = 603 (dnetc) trap number = 12 panic: page fault cpuid = 1; lapic.id = 0100 Stack backtrace: boot() called on cpu#1 syncing disks, buffers remaining... panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled cpuid = 1; lapic.id = 0100 boot() called on cpu#1 Uptime: 4m15s Dumping 191 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 --- I had the same panic last week after updating and had to disable [EMAIL PROTECTED] to get up in hurry. The last kernel (4BSD) ran fine for a month with two seti processes running. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Does bg fsck have problems with large filesystems?
On Tue, Jan 28, 2003 at 11:44:03AM +0100, Attila Nagy [EMAIL PROTECTED] wrote: I've just installed my first 5.0-rel system and did some torture-testing. When resetting the machine to test the backgrounded fsck I experienced the following problem: All filesystems came back quickly and bg fsck worked fine, except for one. I had created a large (50GB) /export filesystem on with fsck reproducively hang. See PR kern/47105. Although it speaks of much larger filesystems, than your, the problem is there. I've already written to Kirk McKusick, but it seems that he has a lot of work, because I didn't get answer. If anybody wants to look into this problem, I can give access to the machine (even serial console)... I don't see it listed in 5.0-RELEASE ERRATA. Several people have now reported problems with background fsck and in the case Kirk as original author is loaded with other work I see no justification to not mention the brokenness of bgfsck. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
tired of crashes
/dev/da2s1e--- magic 19540119 (UFS2) timeWed Feb 5 11:17:08 2003 superblock location 65536 id [ 3e2bcb0b 4f52628 ] ncg 191 size17928524blocks 17363122 bsize 16384 shift 14 mask0xc000 fsize 2048shift 11 mask0xf800 frag8 shift 3 fsbtodb 2 minfree 1% optim space symlinklen 120 maxbsize 16384 maxbpg 2048maxcontig 8 contigsumsize 8 nbfree 1848912 ndir19435 nifree 4356621 nffree 7038 bpg 11761 fpg 94088 ipg 23552 nindir 2048inopb 64 maxfilesize 140806241583103 sbsize 2048cgsize 16384 csaddr 3000cssize 4096 sblkno 40 cblkno 48 iblkno 56 dblkno 3000 cgrotor 139 fmod0 ronly 0 clean 0 flags soft-updates -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tired of crashes
On Wed, Feb 05, 2003 at 10:40:09AM -0800, Kris Kennaway [EMAIL PROTECTED] wrote: --- panic: ufs_dirbad: bad dir cpuid = 1; lapic.id = 0100 boot() called on cpu#1 I get those on the bento cluster when the disk is starting to fail. dd'ing /dev/zero over it usually gives it some more life by forcing it to remap bad blocks as it goes. The disk has been in use for ~1 year and both primary and grown defect lists are the same as in the beginning. So far haven't observed any signs of dying disk. Also no other disk activity has been problematic, I have several times copied over the disk contents (~5GB) to other disk to re-newfs the filesystem. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tired of crashes
On Wed, Feb 05, 2003 at 11:47:44AM +0200, Vallo Kallaste vallo wrote: accumulated filesystem corruption. This is on UFS2 filesystem, haven't tried UFS1 yet. World and kernel are from January 21, PIII SMP system. I'll provide any info one needs to track the cause, needless to say I'm _really_ tired of it. So far I've been unable to reproduce it after update to Feb 5 world and kernel. I'll try to beat it for some more days before considering it gone. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Vinum R5 [was: Re: background fsck deadlocks with ufs2 and big disk]
On Thu, Feb 20, 2003 at 02:28:45PM -0800, Darryl Okahata [EMAIL PROTECTED] wrote: Vallo Kallaste [EMAIL PROTECTED] wrote: I'll second Brad's statement about vinum and softupdates interactions. My last experiments with vinum were more than half a year ago, but I guess it still holds. BTW, the interactions showed up _only_ on R5 volumes. I had 6 disk (SCSI) R5 volume in Compaq Proliant 3000 and the system was very stable before I enabled softupdates.. and of course after I disabled softupdates. In between there were crashes and nasty problems with filesystem. Unfortunately it was production system and I hadn't chanche to play. Did you believe that the crashes were caused by enabling softupdates on an R5 vinum volume, or were the crashes unrelated to vinum/softupdates? I can see how crashes unrelated to vinum/softupdates might trash vinum filesystems. The crashes and anomalies with filesystem residing on R5 volume were related to vinum(R5)/softupdates combo. The vinum R5 and system as a whole were stable without softupdates. Only one problem remained after disabling softupdates, while being online and user I/O going on, rebuilding of failed disk corrupt the R5 volume completely. Don't know is it fixed or not as I don't have necessary hardware at the moment. The only way around was to quiesce the volume before rebuilding, umount it, and wait until rebuild finished. I'll suggest extensive testing cycle for everyone who's going to work with vinum R5. Concat, striping and mirroring has been a breeze but not so with R5. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[Re: cc: Internal error: Illegal instruction (program as)
On Sat, Feb 22, 2003 at 11:43:01AM -0500, Paul A. Howes [EMAIL PROTECTED] wrote: I am receiving some strange errors during a buildworld of 5.0-RELEASE-p2 from 5.0-RELEASE-p1. The location of where the failure varies, but the program that causes the failure is the same every time: as. The errors are a variety of signal 10 and signal 4. I do find an as.core file under /usr/obj, but as is stripped, so there are no debugging symbols or listing that I can provide. The strange thing is that I have been able to successfully build XFree86, KDE, and many other ports on this system. I followed the 4.x-to-5.0 upgrade directions to the letter about a month ago, and have had no major problems before this. Any help would be greatly appreciated! As John Hay suggested, add DISABLE_PSE and DISABLE_PG_G to your kernel configuration and rebuild/install kernel. I was having _exactly_ same behaviour; at the beginning of test runs to narrow the problem a bit I did _large_ ports builds, which ran for 1,5 days.. flawlessly, as you had seen. Then changed test method to parallel (make -j4) buildworld and the problem occasionally appeared from nowhere again. The flags mentioned before will work, as I haven't had any problems after enabling them (months of time now). -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [Re: cc: Internal error: Illegal instruction (program as)
On Sat, Feb 22, 2003 at 11:18:42PM -0800, Terry Lambert [EMAIL PROTECTED] wrote: I thought this was the default in 5.x GENERIC; has someone turned these options off in the default config?!? I certainly haven't seen changes to locore.s, pmap.c, and machdep.c that would fix the problem by working around the CPU bug. Can't say anything for Paul's case, he probably had custom kernel then? If I can remember peter did the options conditional for CPU type, so only P4 owners get'em at boot time. Check the Feb 12 commit logs. -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
On Mon, Feb 24, 2003 at 12:10:46PM +0100, Soeren Schmidt [EMAIL PROTECTED] wrote: These two kernel options seem to have solved the problem. Builds now run smoothly and error-free. I read the comments in NOTES about these options and something clicked: I recall that most Pentium processors will only deal with 4 kB pages. Aren't 4 MB pages a feature of the Xeon processor, as it can address much more memory? If that is the case, then these options should be the default, and their inverse provided in the kernel configuration file (ENABLE_PSE ENABLE_PG_G). Just for the record but my [EMAIL PROTECTED]/533 512MB/DDR does *not* show this problem no matter how hard I beat it. Terry claims the problem is somewhat masked on systems using more memory and particular kernel options. Not my words and claims, but Terry's, however you can try to physically take out memory (if you have two 256MB modules) or limit it at boottime (into which I don't believe, personally, but that's my uneducated faith only). Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1699953492 Hz CPU: Intel(R) Celeron(R) CPU 1.70GHz (1699.95-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf13 Stepping = 3 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 132382720 (126 MB) avail memory = 123191296 (117 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled VESA: v3.0, 832k memory, flags:0x1, mode table:0xc043e2e0 (140) VESA: Brookdale-G Graphics Chip Accelerated VGA BIOS npx0: math processor on motherboard npx0: INT 16 interface acpi0: INTEL D845GLLY on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE31 Using $PIR table, 9 entries at 0xc00f3d20 -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Followup [Re: tired of crashes]
On Wed, Feb 05, 2003 at 11:47:44AM +0200, Vallo Kallaste vallo wrote:
In the last ~three months now I've had 24 kernel crashes, all the
same, all happening in the same circumstances. Happens while cvsup
is running, everytime... except if I remove the checkouts file which
probably causes slowdown of cvsup operation. I have recreated the
filesystem on /dev/da2s1e several times anew, to exclude any
accumulated filesystem corruption. This is on UFS2 filesystem,
haven't tried UFS1 yet. World and kernel are from January 21, PIII
SMP system. I'll provide any info one needs to track the cause,
needless to say I'm _really_ tired of it.
When I updated to Feb 5 world/kernel (after the crashes in a row for
several months), I did extensive testing and found the crash gone.
The test procedure did incremental cvsup over the time range of
01.01.2002 - 30.12.2002 in steps of 1 day. It took quite a while
(day or so) and generated astonishing amount of I/O on the
problematic disk/filesystem. I ran the test for two times, to be
sure, with XFree and usual apps/activity running and without. No
crash. But it's still there, today I got one and it happens
_exactly_ on the same conditions. Got to work in the morning, did
startx (no xdm) and KDE started up, fired up several ssh sessions
and read my mail with mutt, then started cvsup to catch up the
bleeding edge. While cvsup running, switched to free workspace in
KDE and started up Phoenix, to read Daemonnews... at the very moment
the Phoenix window appeared on the screen, the system crashed.
For now I quess it's somehow related to XFree/Phoenix/cvsup combo,
because I remember the last ten (or so) crashes quite well and I
_was starting or starting to use_ Phoenix the times the crash
happened (and cvsup running as well). Can it be related to mga.ko
module or somesuch? I don't do any DRI or 3D myself, but perhaps
Phoenix does something behind the scenes? Just wild guess.
Script started on Tue Feb 25 11:15:39 2003
bash-2.05b# gdb -k /sys/i386/compile/Myhakas-5.0-SMP-4BSD/kernel.debug /usr/cra
sh/vmcore.25
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
panic: ufs_dirbad: bad dir
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 18d19h30m18s
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at ../../../kern/kern_shutdown.c:232
warning: Source file is more recent than executable.
232 }
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc024096a in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc0240c37 in panic () at ../../../kern/kern_shutdown.c:531
#3 0xc02883c2 in bwrite (bp=0xce6d2b68) at ../../../kern/vfs_bio.c:798
#4 0xc0289b66 in vfs_bio_awrite (bp=0xce6d2b68)
at ../../../kern/vfs_bio.c:1650
#5 0xc0204903 in spec_fsync (ap=0xe3a4f804)
at ../../../fs/specfs/spec_vnops.c:459
#6 0xc0203c48 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:123
#7 0xc035248b in ffs_sync (mp=0xc41c7a00, waitfor=2, cred=0xc1514e80,
td=0xc0444a20) at vnode_if.h:612
#8 0xc029e2fb in sync (td=0xc0444a20, uap=0x0)
at ../../../kern/vfs_syscalls.c:138
#9 0xc024054b in boot (howto=256) at ../../../kern/kern_shutdown.c:273
#10 0xc0240c37 in panic () at ../../../kern/kern_shutdown.c:531
#11 0xc035a442 in ufs_dirbad (ip=0x0, offset=0, how=0x0)
at ../../../ufs/ufs/ufs_lookup.c:631
#12 0xc0359967 in ufs_lookup (ap=0xe3a4faa4)
at ../../../ufs/ufs/ufs_lookup.c:294
#13 0xc03612a8 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2787
#14 0xc028df1c in vfs_cache_lookup (ap=0x0) at vnode_if.h:82
#15 0xc03612a8 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2787
#16 0xc0292732 in lookup (ndp=0xe3a4fc18) at vnode_if.h:52
#17 0xc029213b in namei (ndp=0xe3a4fc18) at ../../../kern/vfs_lookup.c:181
#18 0xc02a1362 in lstat (td=0xc5c5fb60, uap=0xe3a4fd10)
at ../../../kern/vfs_syscalls.c:1700
#19 0xc03c4c6c in syscall (frame=
{tf_fs = 136118319, tf_es = 134873135, tf_ds = 136118319, tf_edi =
1361343---Type return to continue, or q return to quit---
04, tf_esi = 134876320, tf_ebp = 136133492, tf_isp = -475726476, tf_ebx = 136631584,
tf_edx = 0, tf_ecx = 0, tf_eax = 190, tf_trapno = 22, tf_err = 2, tf_eip = 672677171,
tf_cs = 31, tf_eflags = 582, tf_esp = 136133356, tf_ss = 47})
at ../../../i386/i386/trap.c:1033
#20 0xc03acacd in Xint0x80_syscall () at {standard
SCHED_ULE oddities
Hi Just for fun I tried out SCHED_ULE once again, using todays source. What I got was really odd situation that my newly installed kernel (and modules) didn't find the way to disk and loader complained about missing kernel on next boot. The /boot/kernel directory was simply missing and / filesystem dirty. Smells very similar to the problems with unclean shutdown (buffers not written out to disk) circulating in -current recently, but as I didn't have the serial console open while booting, can't say for sure. For the curious the procedure was as follows: checkout new sources buildworld/installworld build new kernel/install new kernel immediately do shutdown -r now repeat the last two steps as long as you wish or until the problem \ appears -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Vinum R5 [was: Re: background fsck deadlocks with ufs2 and big disk]
On Thu, Feb 27, 2003 at 11:59:59AM +1030, Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: The crashes and anomalies with filesystem residing on R5 volume were related to vinum(R5)/softupdates combo. Well, at one point we suspected that. But the cases I have seen were based on a misassumption. Do you have any concrete evidence that points to that particular combination? Don't have any other evidence than the case I was describing. After changing my employer I hadn't had much time or motivation to try again. The vinum R5 and system as a whole were stable without softupdates. Only one problem remained after disabling softupdates, while being online and user I/O going on, rebuilding of failed disk corrupt the R5 volume completely. Yes, we've fixed a bug in that area. It had nothing to do with soft updates, though. Oh, that's very good news, thank you! Yes, it had nothing to do with soft updates at all and that's why I had the remained after in the sentence. Don't know is it fixed or not as I don't have necessary hardware at the moment. The only way around was to quiesce the volume before rebuilding, umount it, and wait until rebuild finished. I'll suggest extensive testing cycle for everyone who's going to work with vinum R5. Concat, striping and mirroring has been a breeze but not so with R5. IIRC the rebuild bug bit any striped configuration. Ok, I definitely had problems only with R5, but you certainly know much better what it was exactly. I'll need to lend 50-pin SCSI cable and test vinum again. Will it matter on what version of FreeBSD I'll try on? My home system runs -current of Feb 5, but if you suggest -stable for consistent results, I'll do it. Thanks -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Vinum R5 [was: Re: background fsck deadlocks with ufs2 and big disk]
On Thu, Feb 27, 2003 at 11:53:02AM +0200, Vallo Kallaste vallo wrote: The vinum R5 and system as a whole were stable without softupdates. Only one problem remained after disabling softupdates, while being online and user I/O going on, rebuilding of failed disk corrupt the R5 volume completely. Yes, we've fixed a bug in that area. It had nothing to do with soft updates, though. Oh, that's very good news, thank you! Yes, it had nothing to do with soft updates at all and that's why I had the remained after in the sentence. Don't know is it fixed or not as I don't have necessary hardware at the moment. The only way around was to quiesce the volume before rebuilding, umount it, and wait until rebuild finished. I'll suggest extensive testing cycle for everyone who's going to work with vinum R5. Concat, striping and mirroring has been a breeze but not so with R5. IIRC the rebuild bug bit any striped configuration. Ok, I definitely had problems only with R5, but you certainly know much better what it was exactly. I'll need to lend 50-pin SCSI cable and test vinum again. Will it matter on what version of FreeBSD I'll try on? My home system runs -current of Feb 5, but if you suggest -stable for consistent results, I'll do it. So I did. Loaned two SCSI disks and 50-pin cable. Things haven't improved a bit, I'm very sorry to say it. The entire test session (script below) was done in single user. To be fair, I did tens of them, and the mode doesn't matter. Complete script: Script started on Sat Mar 1 19:54:45 2003 # pwd /root # dmesg Copyright (c) 1992-2003 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: Sun Feb 2 16:16:49 EET 2003 [EMAIL PROTECTED]:/usr/home/vallo/Kevad-5.0 Preloaded elf kernel /boot/kernel/kernel at 0xc0516000. Preloaded elf module /boot/kernel/vinum.ko at 0xc05160b4. Preloaded elf module /boot/kernel/ahc_pci.ko at 0xc0516160. Preloaded elf module /boot/kernel/ahc.ko at 0xc051620c. Preloaded elf module /boot/kernel/cam.ko at 0xc05162b4. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 132955356 Hz CPU: Pentium/P54C (132.96-MHz 586-class CPU) Origin = GenuineIntel Id = 0x526 Stepping = 6 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 67108864 (64 MB) avail memory = 59682816 (56 MB) Intel Pentium detected, installing workaround for F00F bug Initializing GEOMetry subsystem VESA: v2.0, 4096k memory, flags:0x0, mode table:0xc037dec2 (122) VESA: ATI MACH64 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX ATA controller port 0xff90-0xff9f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ahc0: Adaptec 2940 Ultra SCSI adapter port 0xf800-0xf8ff mem 0xffbee000-0xffbeefff irq 10 at device 13.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs pci0: display, VGA at device 14.0 (no driver attached) atapci1: Promise ATA66 controller port 0xff00-0xff3f,0xffe0-0xffe3,0xffa8-0xffaf,0xffe4-0xffe7,0xfff0-0xfff7 mem 0xffbc-0xffbd irq 11 at device 15.0 on pci0 ata2: at 0xfff0 on atapci1 ata3: at 0xffa8 on atapci1 orm0: Option ROMs at iomem 0xed000-0xedfff,0xca000-0xca7ff,0xc8000-0xc9fff,0xc-0xc7fff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 ed0 at port 0x300-0x31f iomem 0xd8000 irq 5 on isa0 ed0: address 00:80:c8:37:e2:a6, type NE2000 (16 bit) fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 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: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 5 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 (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0401 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0501 can't assign resources (port) Timecounters tick every 1.000 msec ata0-slave: ATAPI identify retries exceeded ad4: 2445MB QUANTUM FIREBALL EL2.5A [5300/15/63] at ata2-master UDMA33 ad6: 2423MB SAMSUNG WU32553A (2.54GB) [4924/16/63] at ata3-master UDMA33 acd0: CDROM WPI CDD-820 at ata0-master PIO3 Waiting 15 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0
Re: ATA problems
On Tue, Mar 04, 2003 at 04:59:33PM +0100, Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: Soeren Schmidt [EMAIL PROTECTED] writes: It seems Dag-Erling Smorgrav wrote: ad0: READ command timeout tag=0 serv=1 - resetting ad0: invalidating queued requests That why it is disabled, its not working for the time being. For me, the time being == since it was introduced in the tree. It has never worked for me, ever. That's the point I was trying to make. It's probably dependent of your ATA controller. You have the infamous P5A board with ALi chipset, it has timekeeping problems also if I remember. I've used DTLA and DPTA disk behind PIIX4 controller and have had zero problems after the initial development did settle. -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
