Re: Kernel Panic from Yesterday's CVSup
On Mon, Feb 05, 2001 at 02:51:59PM -0800, John Baldwin wrote:
On 05-Feb-01 Crist J. Clark wrote:
I don't recall reports of trouble with recent CURRENT, but my CVSup
from yesterday afternoon is panicing. Before I try too debug this, has
anyone been getting these or knows what I might be missing?
Boot messages and the panic info are attached.
Could you please turn on DDB, WITNESS, and INVARIANTS in your kernel and see if
you can reproduce this? Also, compile the kernel with debug symbols. Then
type 'trace' at the db prompt when it does to get a backtrace of where it blew
up. Thanks.
OK. The boot messages and debug output is attachment one, the kernel
config is second. For the record, I have not made any changes to the
kernel; fresh CVSup.
--
Crist J. Clark [EMAIL PROTECTED]
Copyright (c) 1992-2001 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 #2: Mon Feb 5 23:59:09 PST 2001
[EMAIL PROTECTED]:/usr/obj/export/current/src/sys/BUBBLES
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium/P54C (132.96-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x52b Stepping = 11
Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8
real memory = 33554432 (32768K bytes)
avail memory = 30015488 (29312K bytes)
Preloaded elf kernel "kernel.BUBBLES" at 0xc02c5000.
Intel Pentium detected, installing workaround for F00F bug
apm0: APM BIOS on motherboard
apm0: found APM BIOS v1.1, connected at v1.1
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
pci0: display, VGA at 8.0 (no driver attached)
ep0: 3Com 3C509-TP EtherLink III at port 0x300-0x30f irq 10 on isa0
ep0: Ethernet address 00:20:af:17:a3:e9
ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0
fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5" drive on fdc0 drive 0
ppc0: Parallel port at port 0x3bc-0x3c3 irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
plip0: PLIP network interface on ppbus0
lpt0: Printer on ppbus0
lpt0: Interrupt-driven port
ppi0: Parallel I/O on ppbus0
ppc1: cannot reserve I/O port range
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sio2 at port 0x3e8-0x3ef irq 5 on isa0
sio2: type 16550A
unknown: PNP0700 can't assign resources
unknown: PNP0400 can't assign resources
unknown: PNP0501 can't assign resources
unknown: PNP0501 can't assign resources
unknown: PNP0680 can't assign resources
IP packet filtering initialized, divert enabled, rule-based forwarding disabled,
default to deny, logging limited to 1000 packets/entry by default
ad0: 1222MB QUANTUM FIREBALL1280A [2484/16/63] at ata0-master BIOSPIO
acd0: CDROM CD-532E-A at ata0-slave using BIOSPIO
Mounting root from ufs:/dev/ad0s1a
kernel trap 9 with interrupts disabled
panic: mutex sched lock recursed at /export/current/src/sys/kern/kern_synch.c:918
Debugger("panic")
Stopped at Debugger+0x44: pushl %ebx
db trace
Debugger(c0215a83) at Debugger+0x44
panic(c02148a2,c022fc69,c02160a0,396,c0823f00) at panic+0x70
_mtx_assert(c0278140,9,c02160a0,396,c0823f00) at _mtx_assert+0x63
mi_switch(c3611b80,20,9,c3a29f08,c01f2a6d) at mi_switch+0x25
sched_ithd(e) at sched_ithd+0xd9
Xresume14() at Xresume14+0x8
--- interrupt, eip = 0x8, esp = 0xc3a29ee4, ebp = 0xc3a29ed4 ---
(null)(c01fcd58,8,80286,c02781a0,20) at 0x8
db
# $Id: BUBBLES,v 1.4 2001/02/04 06:49:24 cjc Exp cjc $
#
# BUBBLES - 2000/11/11, cjc
#
# Kernel configuration for IBM Pentium 133
#
# 2000/12/09, cjc - DEVEL became BUBBLES
#
machine i386
cpu I586_CPU
ident BUBBLES
maxusers32
#To statically compile in device wiring instead of /boot/device.hints
#hints "GENERIC.hints" #Default places to look for devices.
#makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols
options WITNESS
options INVARIANTS
options DDB
options INET#InterNETworking
options INET6 #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
#optionsFFS_ROOT#FFS usable as root device [keep this!]
options SOFTUPDATES #Enable FFS soft updates support
#optionsDEVFS #Device Filesystem
options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!]
options UCONSOLE#Allow users to grab the console
options KTRACE #ktrace(1) support
options SYSVSHM #SYSV-style shared memory
options SYSVMSG
Re: md, current and stable
On Tue, 06 Feb 2001 16:34:39 +1100, "Chris Knight" wrote: Since the new md was introduced, it is not possible to build a -current snapshot on a -stable box. Are there any plans to MFC this soon? Woah, what's the problem? This sounds like something that should be fixed, not covered up with an MFC. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (KAME-snap 3974) Re: TI-RPC, IPv6 and NFS (was: Re: strongrecommendationre: NFS)
As I already wrote in a prior statement, Alfred Perlstein and I ported TI_RPC to FreeBSD. It compiles with recent CURRENT. http://www.attic.ch/patches/rpc.diff_01152001-2.sh.tgz All you have to do is to start rpc.diff_01152001-2.sh in the source tree and make a buildworld and then run mergemaster (installing etc/defaults/rc.conf and etc/netconfig) Then the system is ready. Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: md, current and stable
Howdy, -Original Message- From: Sheldon Hearn [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 6 February 2001 20:38 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: md, current and stable On Tue, 06 Feb 2001 16:34:39 +1100, "Chris Knight" wrote: Since the new md was introduced, it is not possible to build a -current snapshot on a -stable box. Are there any plans to MFC this soon? Woah, what's the problem? This sounds like something that should be fixed, not covered up with an MFC. When -current's release scripts were cut over to use mdconfig due to PHK's death warrant notice of vn, vnconfig and MFS, release builds stopped working on -stable due to -stable's md driver not having a handler for /dev/mdctl. As vn + friends are disappearing, it makes sense for md to be MFCed, thus fixing the problem. Ciao, Sheldon. Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: md, current and stable
In message 004a01c09026$ec0261f0$[EMAIL PROTECTED], "Chris Knight" writes: Howdy, -Original Message- From: Sheldon Hearn [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 6 February 2001 20:38 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: md, current and stable On Tue, 06 Feb 2001 16:34:39 +1100, "Chris Knight" wrote: Since the new md was introduced, it is not possible to build a -current snapshot on a -stable box. Are there any plans to MFC this soon? Woah, what's the problem? This sounds like something that should be fixed, not covered up with an MFC. When -current's release scripts were cut over to use mdconfig due to PHK's death warrant notice of vn, vnconfig and MFS, release builds stopped working on -stable due to -stable's md driver not having a handler for /dev/mdctl. As vn + friends are disappearing, it makes sense for md to be MFCed, thus fixing the problem. Somebody with a stable machine: try it and send patches. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On Mon, Feb 05, 2001 at 08:46:42PM -0800, John Baldwin wrote:
On 06-Feb-01 Andrea Campi wrote:
Sorry to bother everybody, but did anybody note from my panic trace,
that instruction pointer is 0xdeadc0de? Isn't that bad? :-p
That means it is free'd memory. One cause might be something that is free'ing
its interrupt handler w/o releasing it properly. Alternatively, it might be a
Ok, can't help with the rest of your answer, but I'd like to help debug if the
issue is here.
Problem: I can't do anything at db prompt? Backtrace is doing nothing except
triggering a new register dump (another fault I assume).
Anyway, I'm using:
device card
device pcic
device ep
I started looking around in src/sys/dev/{ep,pccard,pcic}/* for recent changes
that could have caused it, but I soon got lost... :(
What should I try? I can go back to an earlier kernel (via cvs compile, sadly
I don't have any old working kernel anymore), but I'd have to first understand
how far back I can go without getting out of sync between kernel world...
Meanwhile, I'll try the latest kernel, and also cardbus to see if the results
are different in any way...
Bye,
Andrea
--
Intel: where Quality is job number 0.9998782345!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
On Tue, Feb 06, 2001 at 03:43:33PM +0900, [EMAIL PROTECTED] wrote: From: "Kenneth D. Merry" [EMAIL PROTECTED] Date: Mon, 5 Feb 2001 17:00:41 -0700 I think we already have the most important functionality from the od(4) driver in the da and cd drivers. If there are any features that are in the od(4) driver that should be in the da(4) or cd(4) drivers, but aren't, please speak up. Though I have not tried `da' lately, if you don't insert a medium in the drive at the time of CAM rescan bus, `da' tries to get the geometry by XPT_CALC_GEOMETRY then panics with divided by zero in most SCSI drivers. With `od' it says just the medium is 0MB and does not cause panic. Probably `od' knows the medium is not in the drive (watching UNIT READY or something?). Sounds very much like a bug which should be fixed than worked around. Especialy when even the workaround doesn't run! I was running a HP mo which claimed to be an optical drive. It did run very fine under every condition. Now the drive is configured to inquiry as direct access because I used it on a solaris box for some days. Now all my removeable drives claim all to be direct access. I asume your drive firmware doesn't send a propper 'NOT READY'. But that shouldn't panic the system. Is it safe to change the size (geometry) of media with `da', eg. at first no medium (0MB), then 128MB, 230MB, 640MB (sector size is 2048bytes) and so on ? Can you provide us with the exact message and a stack trace from the system? And don't forget the exact drive inquiry string and version. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
What's changed recently with vmware/linuxemu/file I/O
Hi, I'm wondering what's changed recently to cause vmware2 running on the linuxemu to lose a lot of performance with disk I/O. A couple of weeks ago I could boot win2000 under vmware2 in a matter of minutes; on today's kernel it takes 5 or 10 minutes to boot, and disk I/O is through the roof. Could someone please hit me with a clue-bat :) Joe PGP signature
Re: Kernel Panic from Yesterday's CVSup
Problem: I can't do anything at db prompt? Backtrace is doing nothing except triggering a new register dump (another fault I assume). New kernel, new panic, new info: db witness_list "Giant" (0xc0279be0) locked at ../../i386/isa/ithread.c:191 db show registers cs 0x8 ds 0x10 es 0x10 fs 0x18 ss 0x10 eax 0xdeadc0de ecx 0xc59eb4b4 edx 0xc0279be0 Giant ebx 0xc0a7a480 _end+0x36f8 esp 0xc65faf68 ebp 0xc65faf78 esi 0xc0a7a4e0 _end+0x3758 edi 0xc01fc998 ithd_loop eax 0xdeadc0de efl 0x10282 Besides the obvious need to fix this one problem, shouldn't we ASSERT ih-ih_handler != NULL before calling it? Bye, Andrea -- Reboot America. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: od driver for -CURRENT
From: Bernd Walter [EMAIL PROTECTED] Date: Tue, 6 Feb 2001 13:30:30 +0100 Though I have not tried `da' lately, if you don't insert a medium in the drive at the time of CAM rescan bus, `da' tries to get the geometry by XPT_CALC_GEOMETRY then panics with divided by zero in most SCSI drivers. With `od' it says just the medium is 0MB and does not cause panic. Probably `od' knows the medium is not in the drive (watching UNIT READY or something?). Sounds very much like a bug which should be fixed than worked around. Especialy when even the workaround doesn't run! I should have written that I didn't dare to do above in 4-stable and 5-current with `da' driver. I tried with 3.x without `od'. Today I tried with 4.2-RELEASE (sorry not -current) and, 1. Boot up the 4.2-RELEASE with GENERIC kernel. 2. Connect MO drive with PC Card SCSI(ncv). 3. Insert PC Card without medium in the MO drive. 4. The pccardd automatically run camcontrol rescan. 5. Message says that da0 is 0MB capacity. 6. Run fdisk da0 7. got panic with divided by zero. Probably divided by zero is caused at line 737 or 748 in the scsi_low_action() in cam/scsi/scsi_low.c because of ccg-block_size or secs_per_cylinder is zero. If I insert a 128MB medium in the drive at 3, no panic occurs. I asume your drive firmware doesn't send a propper 'NOT READY'. I don't think so. I tried two drives and many people claimed that `da' caused the same problem with MOs and Zips in Japanese mailing lists at the era of 3.x . That's the one reason many people in Japan eager to `od'. Is it safe to change the size (geometry) of media with `da', eg. at first no medium (0MB), then 128MB, 230MB, 640MB (sector size is 2048bytes) and so on ? I didn't dare to do this medium change with `da'. Because I thought `da' did not read the geometry when I changed media. Can you provide us with the exact message and a stack trace from the system? And don't forget the exact drive inquiry string and version. I will try with -current later (may be in one week). // Noriaki Mitsuanga // To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
The line where I was having the trap is still within cpu_switch (line 236 of swtch.s). I added WITNESS and INVARIANTS to my kernel and I get a new panic. This time I see: kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at ../../kern/kern_synch.c:918 panic() _mtx_assert(c031b6c0,9,c0290990,396,c043b100) at _mtx_assert+0x63 mi_switch(c031b6c0,0,c,c24bef08,c02681cd) at mi_switch+0x25 sched_ithd(e) at sched_ithd+0xd9 Xresume14() at Xresume14+0x8 --- interrupt, eip = 0xc02b0008, esp - 0xc2fbeee4, epb = 0xc2feed4 --- __set_sysinit_set_sym_sc_mem_sys_init(c0275020,c02b0008,286,c031b7230,0) at __set_sysinit_set_sym_sc_mem_sys_init+0x644 Jim Bloom [EMAIL PROTECTED] PS: Here is the original message. It was cut and pasted from the logs since your message is sitting in another OS on a dual boot machine. On 06-Feb-01 Jim Bloom wrote: I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create a core dump. Here is a hand transcription of what I see. Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc0270ad8 stack pointer = 0x10:0xc2fb4f50 frame pointer = 0x10:0xc2fb4f64 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 16 (irq14:ata0) kernel: type 9 trap, code=0 Stopped at sw1b+0x77: ltr %si backtrace sw1b(4000) at sw1b+0x77 (note this is actually swtch()) Actually, this is beyond the end of cpu_switch I think. You are effectively off in lala land. ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7 This is either in the mtx_enter of Giant or in the interrupt handler itself. I'm betting an interrupt handler isn't being setup properly one way or another, and that the code is jumping through a bogus pointer and ending up in lala land executing random code. fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d fork_trampoline() at fork_trampoline+0x8 I don't have WITNESS or INVARIANTS at this time and don;t have a serial console so I can't capture the output. These help to capture bugs by doing extra checks though, and especially with current they are highly, highly, highly recommended right now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
Josef Karthauser wrote: Hi, I'm wondering what's changed recently to cause vmware2 running on the linuxemu to lose a lot of performance with disk I/O. A couple of weeks ago I could boot win2000 under vmware2 in a matter of minutes; on today's kernel it takes 5 or 10 minutes to boot, and disk I/O is through the roof. Could someone please hit me with a clue-bat :) Joe Part 1.2Type: application/pgp-signature I noticed this too. It's about 3 x slower for me. Even the startup sequence when we haven't even loaded the bootblocks is MUCH slower.. I'm using vmware 1.0.x and running FreeBSD on it for kernel debugging. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Close PR misc/24122 and misc/15471
Could someone close PR misc/{24122,15471}?
PR misc/24122 is no longer relevent.
I doubt anyone will every apply the patches in PR misc/15471 to
older versions of FreeBSD.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Please review sh SIGSTOP fix
Martin Cracauer [EMAIL PROTECTED] writes:
would you please have a look at the following sh fix? My brain is a
bit rusty and maybe I overlook a drawback.
When a child is receiving SIGSTOP, eval continues with the next
command. While that is correct for the interactive case (Control-Z
and you get the prompt back), it is wrong for a shellscript, which
just continues with the next command, never again waiting for the
stopped child. Noted when childs from cronjobs were stopped, just to
make more processes (by wosch).
Careful - is this behavior used as a feature during boot when
starting services? I.e. you can ^Z and it will continue with the next
service; effectively backgrounding the service that's waiting. I.e. is
this a feature (perhaps accidental) that people assume and rely on? And
if so, is there another way to get the functionality, and is it important
to people?
Perhaps I'm totally wrong here and misunderstood the issue.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
On Tue, 6 Feb 2001, Josef Karthauser wrote: I'm wondering what's changed recently to cause vmware2 running on the linuxemu to lose a lot of performance with disk I/O. Use of cmpxchg and possibly other SMP pessimizations. A couple of weeks ago I could boot win2000 under vmware2 in a matter of minutes; on today's kernel it takes 5 or 10 minutes to boot, and disk I/O is through the roof. Could someone please hit me with a clue-bat :) Read your freebsd-emulation mail :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
On Wed, Feb 07, 2001 at 02:40:27AM +1100, Bruce Evans wrote: Could someone please hit me with a clue-bat :) Read your freebsd-emulation mail :-). /me wanders off to subscribe to freebsd-emulation. Thanks Bruce. Joe PGP signature
Re: What's changed recently with vmware/linuxemu/file I/O
Bruce Evans wrote: On Tue, 6 Feb 2001, Josef Karthauser wrote: I'm wondering what's changed recently to cause vmware2 running on the linuxemu to lose a lot of performance with disk I/O. Use of cmpxchg and possibly other SMP pessimizations. A couple of weeks ago I could boot win2000 under vmware2 in a matter of minutes; on today's kernel it takes 5 or 10 minutes to boot, and disk I/O is through the roof. Could someone please hit me with a clue-bat :) Read your freebsd-emulation mail :-). You are wrong Bruce, the cmpxchg discussion was regarding why running FreeBSD as a GUEST OS was slow, because the virtual machine was very slow at emulating them. That does not explain why Windows2000 and the Boot loader both slowed down by a factor or 3-6 over teh last 2 weeks. It's even slower to start up, before it has even started any emulation.. This feels like the system is massively slowing down page activations or some other sort of exceptions that are standard for vmware. The same vmware with the same guest OS (not been updated) is now much slower. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Crist J. Clark wrote: On Mon, Feb 05, 2001 at 02:51:59PM -0800, John Baldwin wrote: On 05-Feb-01 Crist J. Clark wrote: I don't recall reports of trouble with recent CURRENT, but my CVSup from yesterday afternoon is panicing. Before I try too debug this, has anyone been getting these or knows what I might be missing? Boot messages and the panic info are attached. Could you please turn on DDB, WITNESS, and INVARIANTS in your kernel and see if you can reproduce this? Also, compile the kernel with debug symbols. Then type 'trace' at the db prompt when it does to get a backtrace of where it blew up. Thanks. OK. The boot messages and debug output is attachment one, the kernel config is second. For the record, I have not made any changes to the kernel; fresh CVSup. ARGH. The trap code is breaking this. We are getting a trap with interrupts disabled because we have hit a bug while holding a spin mutex. The handy-dandy trap code then enables interrupts for us which allows an interrupt to come in and blow up recursing on sched_lock and obscuring the previous trap. That, and it looks like ddb can't follow back through an interrupt trace properly. Can you edit src/sys/i386/i386/trap.c and comment out the 'enable_intr()' with the nasty comment above it about spin mutexes in trap(): /* * We should walk p_heldmtx here and see if any are * spin mutexes, and not do this if so. */ enable_intr(); } Just comment out that enable_intr() and please try again. This should give you a stack trace where the actual bug is. Thanks. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Jim Bloom wrote: The line where I was having the trap is still within cpu_switch (line 236 of swtch.s). I added WITNESS and INVARIANTS to my kernel and I get a new panic. This time I see: kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at ../../kern/kern_synch.c:918 panic() _mtx_assert(c031b6c0,9,c0290990,396,c043b100) at _mtx_assert+0x63 mi_switch(c031b6c0,0,c,c24bef08,c02681cd) at mi_switch+0x25 sched_ithd(e) at sched_ithd+0xd9 Xresume14() at Xresume14+0x8 --- interrupt, eip = 0xc02b0008, esp - 0xc2fbeee4, epb = 0xc2feed4 --- __set_sysinit_set_sym_sc_mem_sys_init(c0275020,c02b0008,286,c031b7230,0) at __set_sysinit_set_sym_sc_mem_sys_init+0x644 Jim Bloom [EMAIL PROTECTED] Hm, can you show the registers? I wonder if we are somehow running a process that isn't fully created yet. Hmm, that shouldn't be a problem looking at fork1().. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Andrea Campi wrote: Problem: I can't do anything at db prompt? Backtrace is doing nothing except triggering a new register dump (another fault I assume). New kernel, new panic, new info: db witness_list "Giant" (0xc0279be0) locked at ../../i386/isa/ithread.c:191 db show registers cs 0x8 ds 0x10 es 0x10 fs 0x18 ss 0x10 eax 0xdeadc0de ecx 0xc59eb4b4 edx 0xc0279be0 Giant ebx 0xc0a7a480 _end+0x36f8 esp 0xc65faf68 ebp 0xc65faf78 esi 0xc0a7a4e0 _end+0x3758 edi 0xc01fc998 ithd_loop eax 0xdeadc0de efl 0x10282 Besides the obvious need to fix this one problem, shouldn't we ASSERT ih-ih_handler != NULL before calling it? It isn't null in this case, it is 0xdeadc0de. Can you try a pre-preemption kernel and see if that fixes it? Bye, Andrea -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: md, current and stable
On 06-Feb-01 Sheldon Hearn wrote: On Tue, 06 Feb 2001 16:34:39 +1100, "Chris Knight" wrote: Since the new md was introduced, it is not possible to build a -current snapshot on a -stable box. Are there any plans to MFC this soon? Woah, what's the problem? This sounds like something that should be fixed, not covered up with an MFC. Erm, building releases of different branches than the build box isn't really supported. If you want a -current release, build it on a -current box. If you want a -stable release, build it on a -stable box. It may work at times that you can build -stable on -current and vice versa, but that is not supported and one does so at their own risk. Releases are bad enough as is w/o having to add in a multitude of hacks so that one can roll a 5.0 release on a 2.2.x box, etc. Ciao, Sheldon. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please review sh SIGSTOP fix
In [EMAIL PROTECTED], Randell Jesup wrote: Martin Cracauer [EMAIL PROTECTED] writes: would you please have a look at the following sh fix? My brain is a bit rusty and maybe I overlook a drawback. When a child is receiving SIGSTOP, eval continues with the next command. While that is correct for the interactive case (Control-Z and you get the prompt back), it is wrong for a shellscript, which just continues with the next command, never again waiting for the stopped child. Noted when childs from cronjobs were stopped, just to make more processes (by wosch). Careful - is this behavior used as a feature during boot when starting services? I.e. you can ^Z and it will continue with the next service; effectively backgrounding the service that's waiting. I.e. is this a feature (perhaps accidental) that people assume and rely on? I hope not, thats definitivly a bug. Do you intent to continue the stopped proccess anytime? I don't think that are many cases where they were hung so that backgrounding them is needed but where they are not completely hung. And if so, is there another way to get the functionality, and is it important to people? Control-C kills the currently starting process and Control-\ makes the whole /etc/rc return to singleuser-mode. That are the only documented ways to interact with /etc/rc. If you really want to background one process from /etc/rc, you would still do that by writing a wrapped that catches SIGINT and send SIGSTOP to its child (which is the original thing to start). Martin -- Martin Cracauer [EMAIL PROTECTED]http://www.cons.org/cracauer/ As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway -Calvin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please review sh SIGSTOP fix
In [EMAIL PROTECTED], Martin Cracauer wrote: If you really want to background one process from /etc/rc, you would still do that by writing a wrapped that catches SIGINT and send ^^^ ^ wrapper shellscript s SIGSTOP to its child (which is the original thing to start). Sorry Martin -- Martin Cracauer [EMAIL PROTECTED]http://www.cons.org/cracauer/ As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway -Calvin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
In message [EMAIL PROTECTED] Andrea Campi writes: : Problem: I can't do anything at db prompt? Backtrace is doing nothing except : triggering a new register dump (another fault I assume). I'm having all kinds of issues with -current and pccards. OLDCARD hangs solid when I remove a card. Newcard randomly does weird things. If you want stability, I'd strongly advise running -stable for the next few months on your laptop. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Here are the registers (subject to typing errors): cs 0xc2fb0008 ds 0xa10 es0x10 fs0x18 ss0x10 eax 0x12 ecx 0x20 edx 0xc00b8f00 ebx0x2 esp 0xc2fbee1c ebp 0xc2fbee28 esi 0x100 edi 0xc0290990 __set_sysctl_set_sym_sysctl__kern_fscale+0x4 eip 0xc0266fcc Debugger+44 efl 0x56 Jim Bloom [EMAIL PROTECTED] John Baldwin wrote: On 06-Feb-01 Jim Bloom wrote: The line where I was having the trap is still within cpu_switch (line 236 of swtch.s). I added WITNESS and INVARIANTS to my kernel and I get a new panic. This time I see: kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at ../../kern/kern_synch.c:918 panic() _mtx_assert(c031b6c0,9,c0290990,396,c043b100) at _mtx_assert+0x63 mi_switch(c031b6c0,0,c,c24bef08,c02681cd) at mi_switch+0x25 sched_ithd(e) at sched_ithd+0xd9 Xresume14() at Xresume14+0x8 --- interrupt, eip = 0xc02b0008, esp - 0xc2fbeee4, epb = 0xc2feed4 --- __set_sysinit_set_sym_sc_mem_sys_init(c0275020,c02b0008,286,c031b7230,0) at __set_sysinit_set_sym_sc_mem_sys_init+0x644 Jim Bloom [EMAIL PROTECTED] Hm, can you show the registers? I wonder if we are somehow running a process that isn't fully created yet. Hmm, that shouldn't be a problem looking at fork1().. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: md, current and stable
John Baldwin [EMAIL PROTECTED] writes: Releases are bad enough as is w/o having to add in a multitude of hacks so that one can roll a 5.0 release on a 2.2.x box, etc. Sure, but allowing 4.x users to do a source upgrade to 5.0 makes the upgrade path much more flexible. There's a big difference between "support source upgrades from version N-1" and "support source upgrades from all versions". --nat -- nat lanza - research programmer, parallel data lab, cmu scs [EMAIL PROTECTED] http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: md, current and stable
In message [EMAIL PROTECTED], Nat Lanza writes: John Baldwin [EMAIL PROTECTED] writes: Releases are bad enough as is w/o having to add in a multitude of hacks so that one can roll a 5.0 release on a 2.2.x box, etc. Sure, but allowing 4.x users to do a source upgrade to 5.0 makes the upgrade path much more flexible. There's a big difference between "support source upgrades from version N-1" and "support source upgrades from all versions". You don't need "make release" to do a source upgrade from 4.x to 5.x... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: md, current and stable
Poul-Henning Kamp [EMAIL PROTECTED] writes: You don't need "make release" to do a source upgrade from 4.x to 5.x... You're right. Whoops. I can still see it being useful in some cases, though, and as long as the changes necessary to support it aren't too ugly it might be worthwhile. --nat -- nat lanza - research programmer, parallel data lab, cmu scs [EMAIL PROTECTED] http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: md, current and stable
In message [EMAIL PROTECTED], Nat Lanza writes: Poul-Henning Kamp [EMAIL PROTECTED] writes: You don't need "make release" to do a source upgrade from 4.x to 5.x... You're right. Whoops. I can still see it being useful in some cases, though, and as long as the changes necessary to support it aren't too ugly it might be worthwhile. I think it is possible without too much trouble, but it would take somebody to do it, it will not make my TODO list in finite time unless somebody sends me patches. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Looking for old snapshots
Hi, I tried to install a snapshot of -current on my "new" test box. The hardware used for the box should be OK, I've managed to boot it with a recent snapshot of RELENG_4. -current is another matter. I've tried to install 20010131 and 20001204 and both die with a "Fatal Trap 18: integer divide fault while in kernel mode". The last words are: sio4: probe failed test(s): 0 2 4 6 9 unknown: Standard PC COM port failed to probe at port 0x10-0x1f on isa0 adv1: Invalid baseport of 0x20 specified. Nearest valid baseport is 0x100. Failing probe. Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x8:0xc01e1c64 stack pointer = 0x10:0xc07d5704 frame pointer = 0x10:0xc07d570c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, IOPL = 0 current process = 0 (swapper) trap number = 18 panic: integer divide fault Uptime: 0s Any further analysis seems impossible: The kernel on the install floppy doesn't contain any symbols :-( The box is a P-60 (complete with the floating point bug) on a really old Intel mainboard (82433LX chipset?). The box has 32 MByte RAM, an Adaptec 2940 AU and an Oak Technologies ISA VGA Card. Right now, I'm looking for old (Sep/Oct/Nov 2000) snapshots of -current to find a version that works on this box. Thanks in advance /s/Udo -- Murphy was an optimist To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Jim Bloom wrote: Here are the registers (subject to typing errors): cs0xc2fb0008 ds 0xa10 es 0x10 fs 0x18 ss 0x10 eax 0x12 ecx 0x20 edx 0xc00b8f00 ebx 0x2 esp 0xc2fbee1c ebp 0xc2fbee28 esi0x100 edi 0xc0290990 __set_sysctl_set_sym_sysctl__kern_fscale+0x4 eip 0xc0266fcc Debugger+44 efl 0x56 Jim Bloom [EMAIL PROTECTED] Erm, this doesn't look good: movl$GPROC0_SEL*8, %esi /* GSEL(entry, SEL_KPL) */ ltr %si #define GPROC0_SEL 4 /* Task state process slot zero and up */ Thus, %esi should be 32 == 0x20, not 0x100. :( I have no clue why that is screwed up, unless something is overwriting your code segment. Can you panic it and do an x/i of sw1b+0x72? It should look something like this: 121: be 20 00 00 00 mov$0x20,%esi 126: 0f 00 deltr%si -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Which kernel do you want me to try this with? I have tried two different kernels with two different errors. (Both have been sent at different times in the past couple days.) The registers listed here from the second kernel (with WITNESS, INVARIANTS, INVARIANT_SUPPORT, MUTEX_DEBUG). As such the addresses disagree (sw1b has 8 more bytes for invariants), but the text segment was correct. Without debug, I get the trap 9. With debug, I get a trap 12 immediately followed by a panic with mutex shced lock recursion. I rebuilt the kernel with out the debugging and check the state of things. The code is correct and the esi register had the expected value. Jim Bloom [EMAIL PROTECTED] P.S. I am hitting the same problem Robert Watson mentioned. I don't have room for three kernels on the machine. John Baldwin wrote: On 06-Feb-01 Jim Bloom wrote: Here are the registers (subject to typing errors): cs0xc2fb0008 ds 0xa10 es 0x10 fs 0x18 ss 0x10 eax 0x12 ecx 0x20 edx 0xc00b8f00 ebx 0x2 esp 0xc2fbee1c ebp 0xc2fbee28 esi0x100 edi 0xc0290990 __set_sysctl_set_sym_sysctl__kern_fscale+0x4 eip 0xc0266fcc Debugger+44 efl 0x56 Jim Bloom [EMAIL PROTECTED] Erm, this doesn't look good: movl$GPROC0_SEL*8, %esi /* GSEL(entry, SEL_KPL) */ ltr %si #define GPROC0_SEL 4 /* Task state process slot zero and up */ Thus, %esi should be 32 == 0x20, not 0x100. :( I have no clue why that is screwed up, unless something is overwriting your code segment. Can you panic it and do an x/i of sw1b+0x72? It should look something like this: 121: be 20 00 00 00 mov$0x20,%esi 126: 0f 00 deltr%si To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Besides the obvious need to fix this one problem, shouldn't we ASSERT ih-ih_handler != NULL before calling it? It isn't null in this case, it is 0xdeadc0de. Can you try a pre-preemption kernel and see if that fixes it? *BLUSH* Of course ehehe ;-) Ok, I will. Can you give me a date I should try going back to, without kernel getting out of sync with my world? Bye, Andrea -- Yes, I've heard of "decaf." What's your point? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Jim Bloom wrote: Which kernel do you want me to try this with? I have tried two different kernels with two different errors. (Both have been sent at different times in the past couple days.) The registers listed here from the second kernel (with WITNESS, INVARIANTS, INVARIANT_SUPPORT, MUTEX_DEBUG). As such the addresses disagree (sw1b has 8 more bytes for invariants), but the text segment was correct. You'll have to turn off WITNESS to get it to die in cpu_switch(), but you'll want to leave the others on for now. Without debug, I get the trap 9. With debug, I get a trap 12 immediately followed by a panic with mutex shced lock recursion. I rebuilt the kernel with out the debugging and check the state of things. The code is correct and the esi register had the expected value. H. Ok, try with debugging minus WITNESS (and you don't want MUTEX_DEBUG, that slows things down a _lot_). Then see if %esi is still 0x100 instead of 0x20. If so, then check the instructions to make sure they aren't hosed. P.S. I am hitting the same problem Robert Watson mentioned. I don't have room for three kernels on the machine. Yes. :( The default / size for -current is not very good, as development boxes need more room on / than production boxes. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Andrea Campi wrote: Besides the obvious need to fix this one problem, shouldn't we ASSERT ih-ih_handler != NULL before calling it? It isn't null in this case, it is 0xdeadc0de. Can you try a pre-preemption kernel and see if that fixes it? *BLUSH* Of course ehehe ;-) Ok, I will. Can you give me a date I should try going back to, without kernel getting out of sync with my world? Umm, this is the commit you want to be before: jake2001/01/31 19:34:21 PST Modified files: sys/alpha/alpha interrupt.c machdep.c sys/i386/isa ithread.c npx.c Log: Implement preemptive scheduling of hardware interrupt threads. ... A kernel on the 30th or so should work fine with an up to date world. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange fopen() behaviour
dev.lan.Awfulhak.org kernel log messages: microuptime() went backwards (18415.166882 - 18415.158249) microuptime() went backwards (18490.192910 - 18490.187579) microuptime() went backwards (19572.644000 - 19572.638237) microuptime() went backwards (19878.637972 - 19878.637330) microuptime() went backwards (20043.869158 - 20043.868971) microuptime() went backwards (20074.159108 - 20074.152253) microuptime() went backwards (20210.078270 - 20210.072448) I'm also seing this as of CURRENT-2001-01-27 and later: pcm1: hwptr went backwards 36 - 0 pcm1: hwptr went backwards 40 - 16 pcm1: hwptr went backwards 2084 - 2048 pcm1: hwptr went backwards 2092 - 2064 Strange... -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
Bruce Evans wrote: On Tue, 6 Feb 2001, Josef Karthauser wrote: I'm wondering what's changed recently to cause vmware2 running on the linuxemu to lose a lot of performance with disk I/O. Use of cmpxchg and possibly other SMP pessimizations. A couple of weeks ago I could boot win2000 under vmware2 in a matter of minutes; on today's kernel it takes 5 or 10 minutes to boot, and disk I/O is through the roof. Could someone please hit me with a clue-bat :) Read your freebsd-emulation mail :-). You are wrong Bruce, the cmpxchg discussion was regarding why running FreeBSD as a GUEST OS was slow, because the virtual machine was very slow at emulating them. That does not explain why Windows2000 and the Boot loader both slowed down by a factor or 3-6 over teh last 2 weeks. It's even slower to start up, before it has even started any emulation.. This feels like the system is massively slowing down page activations or some other sort of exceptions that are standard for vmware. The same vmware with the same guest OS (not been updated) is now much slower. Indeed. I've been doing a ``make build'' on an OpenBSD-current vm for three days (probably about 36 hours excluding suspends) on a 366MHz laptop with a ATA33 disk. This is on a Feb 4 kernel. NetBSD next -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On Tue, Feb 06, 2001 at 11:02:32AM -0800, John Baldwin wrote:
[snip]
ARGH. The trap code is breaking this.
[snip]
Just comment out that enable_intr() and please try again. This should give you
a stack trace where the actual bug is. Thanks.
Done. And the winner is... (see attachment, did not repeat the kernel
config since it has not changed)
--
Crist J. Clark [EMAIL PROTECTED]
Copyright (c) 1992-2001 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 #3: Tue Feb 6 13:59:53 PST 2001
[EMAIL PROTECTED]:/usr/obj/export/current/src/sys/BUBBLES
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium/P54C (132.96-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x52b Stepping = 11
Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8
real memory = 33554432 (32768K bytes)
avail memory = 30015488 (29312K bytes)
Preloaded elf kernel "kernel.BUBBLES" at 0xc02c5000.
Intel Pentium detected, installing workaround for F00F bug
apm0: APM BIOS on motherboard
apm0: found APM BIOS v1.1, connected at v1.1
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
pci0: display, VGA at 8.0 (no driver attached)
ep0: 3Com 3C509-TP EtherLink III at port 0x300-0x30f irq 10 on isa0
ep0: Ethernet address 00:20:af:17:a3:e9
ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0
fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5" drive on fdc0 drive 0
ppc0: Parallel port at port 0x3bc-0x3c3 irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
plip0: PLIP network interface on ppbus0
lpt0: Printer on ppbus0
lpt0: Interrupt-driven port
ppi0: Parallel I/O on ppbus0
ppc1: cannot reserve I/O port range
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sio2 at port 0x3e8-0x3ef irq 5 on isa0
sio2: type 16550A
unknown: PNP0700 can't assign resources
unknown: PNP0400 can't assign resources
unknown: PNP0501 can't assign resources
unknown: PNP0501 can't assign resources
unknown: PNP0680 can't assign resources
IP packet filtering initialized, divert enabled, rule-based forwarding disabled,
default to deny, logging limited to 1000 packets/entry by default
ad0: 1222MB QUANTUM FIREBALL1280A [2484/16/63] at ata0-master BIOSPIO
acd0: CDROM CD-532E-A at ata0-slave using BIOSPIO
Mounting root from ufs:/dev/ad0s1a
kernel trap 9 with interrupts disabled
panic: blockable mtx_enter() of Giant when not legal @
/export/current/src/sys/i386/i386/trap.c:653
Debugger("panic")
Stopped at Debugger+0x44: pushl %ebx
db trace
Debugger(c0215a83) at Debugger+0x44
panic(c0214bc0,c022fc74,c0230820,28d,c02782e0) at panic+0x70
witness_enter(c02782e0,0,c0230820,28d,0) at witness_enter+0x1d9
_mtx_enter(c02782e0,0,c0230820,28d,c02781a0) at _mtx_enter+0x106
trap(18,10,10,c3612a60,20) at trap+0x583
calltrap() at calltrap+0x5
--- trap 0x9, eip = 0xc01fc642, esp = 0xc3a29f50, ebp = 0xc3a29f64 ---
sw1b(4000) at sw1b+0x81
ithd_loop(0,c3a29fa8) at ithd_loop+0x10d
fork_exit(c0200d94,0,c3a29fa8) at fork_exit+0x2d
fork_trampoline() at fork_trampoline+0x8
db
Re: Kernel Panic from Yesterday's CVSup
John Baldwin wrote: On 06-Feb-01 Jim Bloom wrote: Which kernel do you want me to try this with? I have tried two different kernels with two different errors. (Both have been sent at different times in the past couple days.) The registers listed here from the second kernel (with WITNESS, INVARIANTS, INVARIANT_SUPPORT, MUTEX_DEBUG). As such the addresses disagree (sw1b has 8 more bytes for invariants), but the text segment was correct. You'll have to turn off WITNESS to get it to die in cpu_switch(), but you'll want to leave the others on for now. I turned off WITNESS and still received the mutex error. A little reading of the code showed that mutex assertions are inclued with ifdef INVARIANTS. Without debug, I get the trap 9. With debug, I get a trap 12 immediately followed by a panic with mutex shced lock recursion. I rebuilt the kernel with out the debugging and check the state of things. The code is correct and the esi register had the expected value. H. Ok, try with debugging minus WITNESS (and you don't want MUTEX_DEBUG, that slows things down a _lot_). Then see if %esi is still 0x100 instead of 0x20. If so, then check the instructions to make sure they aren't hosed. With INVARIANTS turned off and WITNESS on, I received a trap 27 (stack fault) at sw1b+0x77. The instructions are fine and %esi was 0x20 as it should be. I won't worry about MUTEX_DEBUG being slow just yet. I am only around the start of /etc/rc when the machine dies. Do you have any other ideas on things that I can try to diagnose this problem? Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 07-Feb-01 Crist J. Clark wrote: On Tue, Feb 06, 2001 at 11:02:32AM -0800, John Baldwin wrote: [snip] ARGH. The trap code is breaking this. [snip] Just comment out that enable_intr() and please try again. This should give you a stack trace where the actual bug is. Thanks. Done. And the winner is... (see attachment, did not repeat the kernel config since it has not changed) Well, can't win with WITNESS here. :) It is still panic'ing on the 'ltr' though. Hmm, oh. ARgh. It's showing the regs from teh most recent panic probably. *sigh* Just turn off WITNESS altogether. It is getting in our way in this particular instance. Sorry for the numerous bounces back and forth. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 07-Feb-01 Jim Bloom wrote: John Baldwin wrote: On 06-Feb-01 Jim Bloom wrote: Which kernel do you want me to try this with? I have tried two different kernels with two different errors. (Both have been sent at different times in the past couple days.) The registers listed here from the second kernel (with WITNESS, INVARIANTS, INVARIANT_SUPPORT, MUTEX_DEBUG). As such the addresses disagree (sw1b has 8 more bytes for invariants), but the text segment was correct. You'll have to turn off WITNESS to get it to die in cpu_switch(), but you'll want to leave the others on for now. I turned off WITNESS and still received the mutex error. A little reading of the code showed that mutex assertions are inclued with ifdef INVARIANTS. Without debug, I get the trap 9. With debug, I get a trap 12 immediately followed by a panic with mutex shced lock recursion. I rebuilt the kernel with out the debugging and check the state of things. The code is correct and the esi register had the expected value. H. Ok, try with debugging minus WITNESS (and you don't want MUTEX_DEBUG, that slows things down a _lot_). Then see if %esi is still 0x100 instead of 0x20. If so, then check the instructions to make sure they aren't hosed. With INVARIANTS turned off and WITNESS on, I received a trap 27 (stack fault) at sw1b+0x77. The instructions are fine and %esi was 0x20 as it should be. I won't worry about MUTEX_DEBUG being slow just yet. I am only around the start of /etc/rc when the machine dies. A stack fault on 'ltr'? Hmm... leeching from teh 386 manual on ltr: Protected Mode Exceptions #GP(0) for an illegal memory operand effective address in the CS, DS, ES, FS, or GS segments; #SS(0) for an illegal address in the SS segment; #GP(0) if the current privilege level is not 0; #GP(selector) if the object named by the source selector is not a TSS or is already busy; #NP(selector) if the TSS is marked "not present"; #PF(fault-code) for a page fault Hmm, so our %ss selector must be invalid in the new TSS. h0h0. Ok, umm. I have no idea how that happened. AFAIK, that shouldn't be touched once the system is up and running. :( So, probably something is trashing it by walking off a dead pointer or some such. :( Do you have any other ideas on things that I can try to diagnose this problem? Right now, no. I know of one potential problem child with preemption: the interrupt thread list handling, and I'm overhauling the ithread code right now so I can try and fix that. Jim Bloom [EMAIL PROTECTED] -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DEVFS and ms-dos partitions
I have a world and kernel from 4 Feb 01. I tried listing the contents in my mounted MS-DOS slice via "ls /msdos" as a normal users, but got a permission denied message (which I've never received before). So, a quick check on the directory permissions shows: d---w- 1 root 493arch 4096 Jan 1 1980 msdos/ which appears to be somewhat strange. So, I unmounted the slice and manually mounted the slice with various incantations of mount_msdos. All yield the above listing. The source in src/sbin/mount_msdos has changed in a long time, so is this a side effect of using DEVFS? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS and ms-dos partitions
On Tue, 6 Feb 2001, Steve Kargl wrote:
I have a world and kernel from 4 Feb 01. I tried listing the
contents in my mounted MS-DOS slice via "ls /msdos" as a normal
users, but got a permission denied message (which I've never
received before). So, a quick check on the directory permissions
shows:
d---w- 1 root 493arch 4096 Jan 1 1980 msdos/
which appears to be somewhat strange. So, I unmounted the
slice and manually mounted the slice with various incantations
of mount_msdos. All yield the above listing.
The source in src/sbin/mount_msdos has changed in a long time,
so is this a side effect of using DEVFS?
This is caused by the same bug that cause panics for exporting
filesystems (things in mount structs moving around whenever the size
of struct mtx changes). struct msdosfs_args is particularly well
designed to be affected by this bug even when nothing is exported:
struct msdosfs_args {
char*fspec; /* blocks special holding the fs to mount */
struct export_args export; /* network export information */
uid_t uid;/* uid that owns msdosfs files */
gid_t gid;/* gid that owns msdosfs files */
mode_t mask; /* mask to be applied for msdosfs perms */
int flags; /* see below */
int magic; /* version number */
u_int16_t u2w[128]; /* Local-Unicode table */
u_int8_t ul[128]; /* Local upper-lower table */
u_int8_t lu[128]; /* Local lower-upper table */
u_int8_t d2u[128]; /* DOS-local table */
u_int8_t u2d[128]; /* Local-DOS table */
};
The fields after the export field become garbage when the size of the
export field changes. The garbage is easy to see using `ls -ld /msdos'.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS and ms-dos partitions
Bruce Evans wrote: On Tue, 6 Feb 2001, Steve Kargl wrote: d---w- 1 root 493arch 4096 Jan 1 1980 msdos/ The source in src/sbin/mount_msdos has changed in a long time, not so is this a side effect of using DEVFS? This is caused by the same bug that cause panics for exporting filesystems (things in mount structs moving around whenever the size of struct mtx changes). struct msdosfs_args is particularly well designed to be affected by this bug even when nothing is exported: [snip of struct] The fields after the export field become garbage when the size of the export field changes. The garbage is easy to see using `ls -ld /msdos'. Hmmm, thanks for the explanation. That o+w permission is a little worrisome. I take it there's no way to force a a different mode on the directory (short of never getting world and kernel out-of-sync, which makes chasing the last mutex bugs much more fun). Mea culpa: I know better. It is a slice not a partition. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
WELCOME TO THE SOJOURN PROJECT!
The Sojourn Project is a civil rights education project that takes high school students from around the nation to historical civil rights landmarks throughout the South. From time to time, we use this newsletter to publicize our program and encourage involvement from the African-American community. For more information about the program, please visit http://www.sojournproject.org. INDEPENDENCE COMMUNITY FOUNDATION GRANT SUPPORTS CIVIL RIGHTS EDUCATION PROJECT IN BROOKLYN For Immediate Release January 30, 2001 BROOKLYN, N.Y. -- On the eve of Black History Month, the New York chapter of the Sojourn civil rights project today proudly announced the receipt of a grant from the Independence Community Foundation (ICF) that will underwrite a Brooklyn public high school student for a 10-day travel-study program to civil rights landmarks in the South. The student will join a group of New York City and California students who qualify for expeditions scheduled for spring 2001. In addition to this student scholarship, the ICF grant will provide organizational support for Sojourn to present a course on civil rights history to students from Brooklyn high schools and non-profit programs. Marilyn G. Gelber, Executive Director of ICF, said: Independence Foundation is pleased to support such a worthy project. We are particularly delighted that this $5,000 grant will allow a Brooklyn student to explore firsthand the roots of our nations civil rights movement and personally observe the extraordinary change that leaders like the Rev. Dr. Martin Luther King Jr. helped to bring about. By understanding history, young people will be better prepared to combat bigotry today. ICFs advocacy on behalf of Sojourn has been a vital factor in successfully introducing the project to Brooklyn and its broad network of philanthropic support. According to Sojourn board member NY State Assemblyman Roger Green (57th AD), The staff at ICF vetted the program as it rolled out in Brooklyn last summer. Then they pledged their support. And then they went the extra mile, providing introductions to other supporters. Without the foresight and generosity of ICF, Sojourns presence in New York would still be a dream. ICF made it real. Mr. Green chairs the Assembly Committee on Children Families in Albany. Sojourn provides an opportunity for high school students from New York City, San Francisco, Oakland and Los Angeles to travel to the South and study the civil rights era in intimate settings. The programs itinerary includes Washington DC, Atlanta, Tuskegee, Montgomery, Selma, Birmingham, Jackson, Little Rock and Memphis. By way of a living history syllabus books, documentaries, recordings and on-site visits with civil rights veterans lessons of tolerance, nonviolence, personal courage, compassion, forgiveness, faith, hope, justice and civic responsibility are imparted during expeditions. John Lewis (U.S. Congressman), Myrlie Evers-Williams (Medgar Evers widow), members of the Little Rock Nine, voting rights pioneer Robert Moses, Rev. Fred Shuttlesworth (leader of the 1963 Birmingham movement), Chris McNair (father of one of four little girls killed in a Birmingham church bombing) and Martin Luther King III, among others, meet with students and teachers during their many stops through the South. Since February 1999, Sojourn has conducted eight civil rights expeditions. More than 665 participants have met with civil rights veterans who have shared the programs ethical lesson plans. By the end of this school year, Sojourn will have served more than 1000 students. To visit Sojourns Web site, click: www.sojournproject.org. To visit the Web site of the Independence Community Foundation, click: www.icfny.org. Until justice rolls down like waters and righteousness like a mighty stream.
Re: Strange fopen() behaviour
On Wed, Feb 07, 2001 at 12:34:18AM +0100, Farid Hajji wrote: I'm also seing this as of CURRENT-2001-01-27 and later: pcm1: hwptr went backwards 36 - 0 pcm1: hwptr went backwards 40 - 16 pcm1: hwptr went backwards 2084 - 2048 pcm1: hwptr went backwards 2092 - 2064 These have existed "forever"..different problem. Kris PGP signature
ctm via mail NEWBIE
I receive ctm-src current by e-mail, which I retrive using netscape. I save message as plain text then I try uudecode and I alvays get no begin line I tryed to edit file but I'm not able to get it work. Regards, Rasa P.S. I know that this question doesn,t belong here but I did not get answer for a long time from [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
