Re: panic: probing for non-PCI bus
John Baldwin wrote: On 11-Nov-2003 John Hay wrote: Upgrading a Asus P2L97-DS dual Pentium II 266MHz box, I got this panic when booting: I have the exact same motherboard, only I run with dual Pentium II 300MHz. However I run a beta bios (to support ata disks larger than 32GB) that I got from Asus many years ago. I am using this system as my workstation at home, and it does have an AGP slot (with an nvidia card in). ACPI has worked before, and it still does except is fires off about 4 interrupts (on IRQ20). However I'll have to wait until I get home to provide acpidumps and mptables when I get home. Oof, no MADT table. Your BIOS sucks. :-P Don't use ACPI because PCI interrupts aren't going to work otherwise. Does this system have an AGP slot? Also, do you have a dmesg from before? If I remember correctly I do not have a MADT table either, but ACPI did find the CPUs. We/I'll know more when I get home. -- Morten Rodal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: probing for non-PCI bus
John Baldwin wrote: acpu_cpu is not the same thing as CPUs listed in the MADT. If there is no MADT, then FreeBSD won't find any APICs and won't be able to trust ACPI PCI interrupt routing. In fact, ACPI will still be trying to route interrupts to the ATPICS, and not to the APICs if the MADT isn't found and used. So I *MUST* run without ACPI? (Not that much of a loss, since I'm not using to anything, other than having to push the powerbutton and having the computer safely shut down) Hopefully there isn't many hardware vendors that have such a bogus ACPI implementation. -- Morten Rodal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xscreensaver bug?
[EMAIL PROTECTED] wrote: Hi, I'm new in FreeBSD. I found that after I lock screen with xscreensaver, I can unlock it with the root's password as well as my normal user's password. I don't think it is a good thing. Is it a bug? It is not a bug, but rather a feature of xscreensaver. It has (to the best of my knowledge) nothing to do with FreeBSD. If you install xscreensaver on Linux, or some other platform, it will probably allow you to unlock the screen with the root password there too. -- Morten Rodal pgp0.pgp Description: PGP signature
Re: Status of SCHED_ULE?
On Mon, Sep 29, 2003 at 01:04:49AM -0400, Jeff Roberson wrote: On Sun, 28 Sep 2003, Morten Rodal wrote: On Sat, Sep 27, 2003 at 11:31:25PM -0400, Jeff Roberson wrote: On Sat, 27 Sep 2003, Morten Rodal wrote: It has improved quite a bit lately, and is now also working with KSE. However, the mouse will get sluggish whenever the computer is under bursts of load (i.e. a compile) I have not had this experience. Can you give me details of your machine and the kind of load that causes slugishness? I'll correct it as soon as I can identify it. The machine is an dual Pentium 2 300MHz, and I'm running gnome 2.4. I do also experience this with my computer at school, a single Pentium3 733MHz. The load isn't very complicated, usually just gnome 2.4 and mozilla firebird running. If I then do anything that requires lots of cpu, like a compile of a program, the interactivity drops fast. On the dual machine I have also experienced a *HUGE* increase in the time for portupgrade -ar to complete. I am not familiar with how portupgrade works, but it seems to spawn a few make's and sort's, but I am not sure why it is currently using 3 hours instead of 10 minutes to complete! (This was tested when there was no packages to upgrade, which shouldn't take long) Both machines (this dual and the one at school) are running with a libmap.conf in order to use libkse, is this perhaps affecting the performance of ULE? It could be. Can you try with libthr or libc_r and let me know? I tried converting to libthr at school and started a portupgrade -ar. (Of course I had restarted all the applications that uses threads) There was no difference in the interactivity, but I came to think of one other thing. I use the /dev/sysmouse and moused, not quite sure why but that's how I've always used my mouse (PS2 or USB) with FreeBSD. Could this have something to do with the mouse feeling sloppy? -- Morten Rodal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of SCHED_ULE?
On Sat, Sep 27, 2003 at 11:31:25PM -0400, Jeff Roberson wrote: On Sat, 27 Sep 2003, Morten Rodal wrote: It has improved quite a bit lately, and is now also working with KSE. However, the mouse will get sluggish whenever the computer is under bursts of load (i.e. a compile) I have not had this experience. Can you give me details of your machine and the kind of load that causes slugishness? I'll correct it as soon as I can identify it. The machine is an dual Pentium 2 300MHz, and I'm running gnome 2.4. I do also experience this with my computer at school, a single Pentium3 733MHz. The load isn't very complicated, usually just gnome 2.4 and mozilla firebird running. If I then do anything that requires lots of cpu, like a compile of a program, the interactivity drops fast. On the dual machine I have also experienced a *HUGE* increase in the time for portupgrade -ar to complete. I am not familiar with how portupgrade works, but it seems to spawn a few make's and sort's, but I am not sure why it is currently using 3 hours instead of 10 minutes to complete! (This was tested when there was no packages to upgrade, which shouldn't take long) Both machines (this dual and the one at school) are running with a libmap.conf in order to use libkse, is this perhaps affecting the performance of ULE? I am not sure how useful this is to you, but if you have any other pointers as to what I should look at just ask. -- Morten Rodal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of SCHED_ULE?
On Sun, Sep 28, 2003 at 01:26:24PM +0100, Matt wrote: Morten Rodal wrote: On Sat, Sep 27, 2003 at 11:31:25PM -0400, Jeff Roberson wrote: On Sat, 27 Sep 2003, Morten Rodal wrote: It has improved quite a bit lately, and is now also working with KSE. However, the mouse will get sluggish whenever the computer is under bursts of load (i.e. a compile) I have not had this experience. Can you give me details of your machine and the kind of load that causes slugishness? I'll correct it as soon as I can identify it. The machine is an dual Pentium 2 300MHz, and I'm running gnome 2.4. I do also experience this with my computer at school, a single Pentium3 733MHz. The load isn't very complicated, usually just gnome 2.4 and mozilla firebird running. If I then do anything that requires lots of cpu, like a compile of a program, the interactivity drops fast. On the dual machine I have also experienced a *HUGE* increase in the time for portupgrade -ar to complete. I am not familiar with how portupgrade works, but it seems to spawn a few make's and sort's, but I am not sure why it is currently using 3 hours instead of 10 minutes to complete! (This was tested when there was no packages to upgrade, which shouldn't take long) Both machines (this dual and the one at school) are running with a libmap.conf in order to use libkse, is this perhaps affecting the performance of ULE? I am not sure how useful this is to you, but if you have any other pointers as to what I should look at just ask. Are you running 5.1-release or 5.1-current? I ask because I have used ULE on two different kernels so far on this box. One was 5.1-release running gnome2, mozilla, xmms. On this the mouse stutters really badly whenever anything is being compiled. However on the 5.1-current kernel this behavior no longer happens and the mouse is fine. I suspect ULE has had a few enhancements between the release and now. I am running 5.1-current Dual machine: FreeBSD slurp.rodal.no 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Thu Sep 25 04:03:23 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp i386 School computer: FreeBSD hauk10.idi.ntnu.no 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Fri Sep 26 09:12:55 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/hauk10 i386 -- Morten Rodal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of SCHED_ULE?
On Sat, Sep 27, 2003 at 06:47:54PM +0200, Roderick van Domburg wrote: Hello everyone, I was wondering about the status of the ULE scheduler. Is it very experimental still or is it reasonably suitable for everyday (i.e. non-mission-critical) use? It has improved quite a bit lately, and is now also working with KSE. However, the mouse will get sluggish whenever the computer is under bursts of load (i.e. a compile) -- Morten Rodal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Tue, Sep 23, 2003 at 07:18:21PM -0700, Kris Kennaway wrote: pwlib-1.5.0_2 I have sent patches for pwlib and gnomemeeting to the maintainer shortly after the gnome2.4 import, and he said they would be commited (with a slight modification) when the ports freeze was lifted. -- Morten Rodal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled
On Fri, Sep 12, 2003 at 08:54:59AM +0200, Morten Rodal wrote: A little bit of history first. I am having great trouble in running any of the Mozilla web browsers under -CURRENT with libkse. (If you are really interested see the thread on threads@) When I ran Mozilla Firebird with the --debug (which lets you run Mozilla Firebird from within gdb) the machine paniced. The backtrace is rather long and I am not sure if the subject of this email is the real panic either. This computer is/was (I am currently rebuilding the kernel to todays sources) running: FreeBSD slurp.rodal.no 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Fri Aug 22 18:06:03 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp i386 More details are available upon request. Since the last panic I upgraded to FreeBSD slurp.rodal.no 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Fri Sep 12 08:59:58 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp i386 (both world and kernel). I am still able to reproduce this, and it is fairly simple. On a smp machine (haven't tried my laptop, and I got more important stuff there that I dont want to lose in a panic) do the following: 1) Install the mozilla-firebird port 2) Edit libmap.conf so that it uses libkse 3) Start it by running firebird --debug, this will present you with a gdb prompt. Type run here and watch your computer panic. (It takes a little while) So this brings up the question, is there a known problem with debugging multi-threaded applications (which use libkse) that can cause a panic? I will bring home my laptop, and will be able to use a serial debugger if that would help anyone willing to trace this down. -- Morten Rodal Script started on Tue Sep 16 08:25:54 2003 slurp# gdb -k kernel.13 vmcore.13 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: absolutely cannot call smp_ipi_shootdown with interrupts already disabled panic messages: --- panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled cpuid = 0; lapic.id = 0100 Stack backtrace: boot() called on cpu#0 syncing disks, buffers remaining... panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled cpuid = 0; lapic.id = 0100 boot() called on cpu#0 Uptime: 3d19h39m32s Dumping 447 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 --- Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/linux/linux.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/linux/linux.ko.debug Reading symbols from /boot/kernel/snd_sb16.ko...done. Loaded symbols for /boot/kernel/snd_sb16.ko Reading symbols from /boot/kernel/snd_sbc.ko...done. Loaded symbols for /boot/kernel/snd_sbc.ko Reading symbols from /boot/kernel/snd_pcm.ko...done. Loaded symbols for /boot/kernel/snd_pcm.ko Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/acpi/acpi.ko.debug Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/if_gif/if_gif.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/if_gif/if_gif.ko.debug Reading symbols from /boot/kernel/nvidia.ko...done. Loaded symbols for /boot/kernel/nvidia.ko Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/cd9660/cd9660.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/cd9660/cd9660.ko.debug Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/nfsserver/nfsserver.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/nfsserver/nfsserver.ko.debug #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc01de9b6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc01dee08 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc0320467 in smp_tlb_shootdown (vector=0, addr1=0, addr2=0) at /usr/src/sys/i386/i386/mp_machdep.c:2396 #4 0xc03207a9 in smp_invlpg_range (addr1=0, addr2=0) at /usr/src/sys/i386/i386/mp_machdep.c:2527 #5 0xc0322b38 in pmap_invalidate_range (pmap=0xc03eda40, sva=3440447488, eva=3440463872) at /usr/src/sys/i386/i386/pmap.c:719 #6 0xc0323011 in pmap_qremove (sva=3440447488, count=0) at /usr/src/sys/i386/i386/pmap.c:985 #7 0xc022ba4a in vfs_vmio_release (bp=0xcca1ec60) at /usr/src/sys/kern/vfs_bio.c:1588 #8
panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled
A little bit of history first. I am having great trouble in running any of the Mozilla web browsers under -CURRENT with libkse. (If you are really interested see the thread on threads@) When I ran Mozilla Firebird with the --debug (which lets you run Mozilla Firebird from within gdb) the machine paniced. The backtrace is rather long and I am not sure if the subject of this email is the real panic either. This computer is/was (I am currently rebuilding the kernel to todays sources) running: FreeBSD slurp.rodal.no 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Fri Aug 22 18:06:03 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp i386 More details are available upon request. -- Morten Rodal Script started on Fri Sep 12 08:49:49 2003 slurp# gdb -k kernel.12 vmcore.12 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: absolutely cannot call smp_ipi_shootdown with interrupts already disabled panic messages: --- panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled cpuid = 1; lapic.id = 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 = boot() called on cpu#1 Uptime: 3d0h0m11s Dumping 447 MB [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [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 --- Reading symbols from /boot/kernel/linux.ko...done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/snd_sb16.ko...done. Loaded symbols for /boot/kernel/snd_sb16.ko Reading symbols from /boot/kernel/snd_sbc.ko...done. Loaded symbols for /boot/kernel/snd_sbc.ko Reading symbols from /boot/kernel/snd_pcm.ko...done. Loaded symbols for /boot/kernel/snd_pcm.ko Reading symbols from /boot/kernel/nvidia.ko...done. Loaded symbols for /boot/kernel/nvidia.ko Reading symbols from /boot/kernel/acpi.ko...done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/if_gif.ko...done. Loaded symbols for /boot/kernel/if_gif.ko Reading symbols from /boot/kernel/nfsserver.ko...done. Loaded symbols for /boot/kernel/nfsserver.ko Reading symbols from /boot/kernel/cd9660.ko...done. Loaded symbols for /boot/kernel/cd9660.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc01e40f6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc01e4548 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc0322347 in smp_tlb_shootdown (vector=0, addr1=0, addr2=0) at /usr/src/sys/i386/i386/mp_machdep.c:2397 #4 0xc0322689 in smp_invlpg_range (addr1=0, addr2=0) at /usr/src/sys/i386/i386/mp_machdep.c:2529 #5 0xc0324a18 in pmap_invalidate_range (pmap=0xc03e6640, sva=3489652736, eva=3489669120) at /usr/src/sys/i386/i386/pmap.c:719 #6 0xc0324d71 in pmap_qremove (sva=3489652736, count=0) at /usr/src/sys/i386/i386/pmap.c:961 #7 0xc022ffaa in vfs_vmio_release (bp=0xccab1058) at /usr/src/sys/kern/vfs_bio.c:1587 #8 0xc0230724 in getnewbuf (slpflag=0, slptimeo=0, size=6144, maxsize=16384) at /usr/src/sys/kern/vfs_bio.c:1864 #9 0xc0231fba in geteblk (size=6144) at /usr/src/sys/kern/vfs_bio.c:2627 #10 0xc022dca3 in bwrite (bp=0x4000) at /usr/src/sys/kern/vfs_bio.c:813 #11 0xc022eabc in bawrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1148 #12 0xc0238bc0 in vop_stdfsync (ap=0xdc2bc708) at /usr/src/sys/kern/vfs_default.c:742 #13 0xc01a8ad0 in spec_fsync (ap=0xdc2bc708) at /usr/src/sys/fs/specfs/spec_vnops.c:417 #14 0xc01a7ec8 in spec_vnoperate (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:122 #15 0xc02c1fe1 in ffs_sync (mp=0xc3a2ec00, waitfor=2, cred=0xc1378e80, td=0xc03adcc0) at vnode_if.h:627 #16 0xc0246aeb in sync (td=0xc03adcc0, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:142 ---Type return to continue, or q return to quit--- #17 0xc01e3bff in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:281 #18 0xc01e4548 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #19 0xc0322347 in smp_tlb_shootdown (vector=0, addr1=0, addr2=0) at /usr/src/sys/i386/i386/mp_machdep.c:2397 #20 0xc032264a in smp_invlpg (addr=0) at /usr/src/sys/i386/i386/mp_machdep.c:2516 #21 0xc0324993 in pmap_invalidate_page (pmap=0xc03e6640, va=3313360896) at /usr/src/sys/i386/i386/pmap.c:691 #22 0xc03267c9 in pmap_enter (pmap=0xc03e6640, va=3225314880, m=0xc0baac48, prot=7 '\a', wired=1) at /usr/src/sys/i386/i386/pmap.c:2037 #23 0xc02dba67
FreeBSD 5.1-CURRENT and panic in xl(4)
Hi,
I've been hitting this panic two times now, and I thought I'd report
it in the hope that someone can tell me what might be wrong.
Not very long ago I bought a new ethernet card, a 3C905, exactly the same as
the one I already had but this one apparently has rxcsum and txcsum.
The computer is an SMP machine with two xl(4) network cards, but only
xl1 has a network cable attached to it. The kernel is from August 22.
I will keep the crash dump around for a while if anyone has any other
requests, or would like to poke around in it.
At the time of the crash there wasn't much network traffic, but I
think I maybe got some bad hardware or that the xl driver is not fully
MPSAFE?
--
Morten Rodal
Script started on Mon Sep 8 20:31:11 2003
slurp# gdb -k kernel.10 vmcore.10
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: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id =
fault virtual address = 0xafa0856a
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0258e3e
stack pointer = 0x10:0xd4ac2c64
frame pointer = 0x10:0xd4ac2c88
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 = 29 (irq10: xl1)
trap number = 12
panic: page fault
cpuid = 1; lapic.id =
Stack backtrace:
boot() called on cpu#1
syncing disks, buffers remaining... 3458 3458 3458 3455 3455 3452 3452 3452 3452 3452
3452 3452 3452 3452 3452 3452 3452 3452 3452 3452 3452 3452 3452 3452 3452
giving up on 1024 buffers
Uptime: 17d0h58m39s
Dumping 447 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
---
Reading symbols from
/usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from /boot/kernel/snd_sb16.ko...done.
Loaded symbols for /boot/kernel/snd_sb16.ko
Reading symbols from /boot/kernel/snd_sbc.ko...done.
Loaded symbols for /boot/kernel/snd_sbc.ko
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from
/usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from /boot/kernel/nvidia.ko...done.
Loaded symbols for /boot/kernel/nvidia.ko
Reading symbols from
/usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/if_gif/if_gif.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/if_gif/if_gif.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/nfsserver/nfsserver.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/nfsserver/nfsserver.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/cd9660/cd9660.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/cd9660/cd9660.ko.debug
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc01e40f6 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc01e4548 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc032a806 in trap_fatal (frame=0xd4ac2c24, eva=0)
at /usr/src/sys/i386/i386/trap.c:818
#4 0xc032a472 in trap_pfault (frame=0xd4ac2c24, usermode=0, eva=2946532714)
at /usr/src/sys/i386/i386/trap.c:732
#5 0xc0329fcd in trap (frame=
{tf_fs = -1053294568, tf_es = 16, tf_ds = 16, tf_edi = -1348434594, tf_esi =
-1013325824, tf_ebp = -726913912, tf_isp = -726913968, tf_ebx = 1610646858, tf_edx =
-1053074432, tf_ecx = -1053074432, tf_eax = -1053074432, tf_trapno = 12, tf_err = 0,
tf_eip = -1071280578, tf_cs = 8, tf_eflags = 66066, tf_esp = 0, tf_ss = -1053139200})
at /usr/src/sys/i386/i386/trap.c:417
#6 0xc03125f8 in calltrap () at {standard input}:103
#7 0xc02a1f53 in xl_rxeof (sc=0xc399e000) at /usr/src/sys/pci/if_xl.c:2125
#8 0xc02a25bf in xl_intr (arg=0xc399e000) at /usr/src/sys/pci/if_xl.c:2344
#9 0xc01cdeb8 in ithread_loop (arg=0xc3977700)
at /usr/src/sys/kern/kern_intr.c:534
#10 0xc01ccb11 in fork_exit (callout=0xc01cdce0 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:796
(kgdb) up 7
#7 0xc02a1f53 in xl_rxeof (sc=0xc399e000
panic: ffs_freefile: freeing free inode
I got a panic (and of course the usual panic on sync panic) when my
machine was just sitting more or less idle in X. The kernel is
FreeBSD 5.1-CURRENT (slurp) #0: Mon Aug 11 21:01:38 CEST 2003
and the machine is a dual Pentium II with only a minimal kernel (i.e.
stripped GENERIC).
--
Morten Rodal
User: Pretend not to be crazy.
jabberwacky: I cannot do that.
-- www.chatterboxchallenge.com
Script started on Wed Aug 13 13:53:36 2003
slurp# gdb -k kernel.8 vmcore.8
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: ffs_freefile: freeing free inode
panic messages:
---
panic: ffs_freefile: freeing free inode
cpuid = 0; lapic.id = 0100
Stack backtrace:
boot() called on cpu#0
syncing disks, buffers remaining... panic: bremfree: removing a buffer not on a queue
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
Uptime: 2h13m50s
Dumping 447 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
---
Reading symbols from
/usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from /boot/kernel/snd_sb16.ko...done.
Loaded symbols for /boot/kernel/snd_sb16.ko
Reading symbols from /boot/kernel/snd_sbc.ko...done.
Loaded symbols for /boot/kernel/snd_sbc.ko
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from /boot/kernel/nvidia.ko...done.
Loaded symbols for /boot/kernel/nvidia.ko
Reading symbols from
/usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/acpi/acpi.ko.debug
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc01e3ec6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc01e4318 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc022d541 in bremfreel (bp=0xcca759e0) at /usr/src/sys/kern/vfs_bio.c:644
#4 0xc022d44b in bremfree (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:626
#5 0xc0238938 in vop_stdfsync (ap=0xd59e1a98)
at /usr/src/sys/kern/vfs_default.c:740
#6 0xc01a8870 in spec_fsync (ap=0xd59e1a98)
at /usr/src/sys/fs/specfs/spec_vnops.c:417
#7 0xc01a7c68 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:122
#8 0xc02c1a11 in ffs_sync (mp=0xc3a2e000, waitfor=2, cred=0xc1378e80,
td=0xc03adb20) at vnode_if.h:627
#9 0xc024686b in sync (td=0xc03adb20, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:142
#10 0xc01e39cf in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:281
#11 0xc01e4318 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#12 0xc02a9198 in ffs_freefile (fs=0xc39a9000, devvp=0xc3ad5000, ino=3,
mode=17407) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1917
#13 0xc02ba8f4 in handle_workitem_freefile (freefile=0xc411b000)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:3401
#14 0xc02b6178 in process_worklist_item (matchmnt=0x0, flags=0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:778
#15 0xc02b5e00 in softdep_process_worklist (matchmnt=0x0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:622
#16 0xc02421c6 in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1786
#17 0xc01cc8e1 in fork_exit (callout=0xc0241d90 sched_sync, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:790
(kgdb) up 12
#12 0xc02a9198 in ffs_freefile (fs=0xc39a9000, devvp=0xc3ad5000, ino=3,
mode=17407) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1917
1917panic(ffs_freefile: freeing free inode);
(kgdb) p *fs
$1 = {fs_firstfield = 0, fs_unused_1 = 0, fs_sblkno = 8, fs_cblkno = 16,
fs_iblkno = 24, fs_dblkno = 1496, fs_old_cgoffset = 0, fs_old_cgmask = -1,
fs_old_time = 1060763786, fs_old_size = 5816260, fs_old_dsize = 5723995,
fs_ncg = 62, fs_bsize = 16384, fs_fsize = 2048, fs_frag = 8, fs_minfree = 8,
fs_old_rotdelay = 0, fs_old_rps = 60, fs_bmask = -16384, fs_fmask = -2048,
fs_bshift = 14, fs_fshift = 11, fs_maxcontig = 8, fs_maxbpg = 2048,
fs_fragshift = 3, fs_fsbtodb = 2, fs_sbsize = 2048, fs_spare1 = {0, 0},
fs_nindir = 4096, fs_inopb = 128, fs_old_nspf = 4, fs_optim = 0,
fs_old_npsect = 376192, fs_old_interleave = 1, fs_old_trackskew = 0,
fs_id = {1042989277, 433616384}, fs_old_csaddr = 1496, fs_cssize = 2048,
fs_cgsize = 16384, fs_spare2 = 0, fs_old_nsect = 376192,
fs_old_spc = 376192, fs_old_ncyl = 62, fs_old_cpg = 1, fs_ipg = 23552,
fs_fpg = 94048, fs_old_cstotal = {cs_ndir = 570, cs_nbfree
libkse crash and sched ule?
I updated to the latest sources early today (CEST time) and install
rtld-elf with libmap support in order to give KSE another try.
However upon starting the Mozilla Firebird executable with very simple
/etc/libmap.conf:
libc_r.so.5 libkse.so.1
libc_r.so libkse.so
the computer starts to dump core in the background (I haven't got a
serial cable right here) and then reboots. Apart from stripping all
the devices I haven't got from GENERIC kernel I have added SCHED_ULE.
Is there a know problem with using SCHED_ULE and KSE?
--
Morten Rodal
Script started on Thu Jul 3 23:12:23 2003
# gdb -k kernel.3 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: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc01cab3e
stack pointer = 0x10:0xd6607c28
frame pointer = 0x10:0xd6607c34
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 = 15 (random)
trap number = 12
panic: page fault
Stack backtrace:
syncing disks, buffers remaining... 3868 3868 3868 3868 3868 3868 3868 3868 3868 3868
3868 3868 3868 3868 3868 3868 3868 3868 3868 3868
giving up on 2042 buffers
Uptime: 8h40m25s
Dumping 511 MB
ata0: resetting devices ..
done
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
---
Reading symbols from
/usr/obj/usr/src/sys/atlantis/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/atlantis/modules/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from /boot/kernel/snd_ich.ko...done.
Loaded symbols for /boot/kernel/snd_ich.ko
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from
/usr/obj/usr/src/sys/atlantis/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/atlantis/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/atlantis/modules/usr/src/sys/modules/nfsclient/nfsclient.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/atlantis/modules/usr/src/sys/modules/nfsclient/nfsclient.ko.debug
Reading symbols from /boot/kernel/nvidia.ko...done.
Loaded symbols for /boot/kernel/nvidia.ko
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 /usr/src/sys/kern/kern_shutdown.c: No such file or directory.
in /usr/src/sys/kern/kern_shutdown.c
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc01c3b57 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc01c3f19 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc03034b2 in trap_fatal (frame=0xd6607be8, eva=0)
at /usr/src/sys/i386/i386/trap.c:836
#4 0xc0302a73 in trap (frame=
{tf_fs = -1070071784, tf_es = -995885040, tf_ds = -698351600, tf_edi =
-1054896880, tf_esi = -1009368448, tf_ebp = -698319820, tf_isp = -698319852, tf_ebx =
-1009357536, tf_edx = 0, tf_ecx = -1006848832, tf_eax = 0, tf_trapno = 12, tf_err = 2,
tf_eip = -1071862978, tf_cs = 8, tf_eflags = 66118, tf_esp = -1054893920, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:256
#5 0xc02f3668 in calltrap () at {standard input}:96
#6 0xc01cc73f in mi_switch () at /usr/src/sys/kern/kern_synch.c:524
#7 0xc01cbe23 in msleep (ident=0xc0370960, mtx=0x0, priority=160, wmesg=0x0,
timo=10) at /usr/src/sys/kern/kern_synch.c:259
#8 0xc0167d61 in random_kthread (arg=0x0)
at /usr/src/sys/dev/random/randomdev.c:330
#9 0xc01ad780 in fork_exit (callout=0xc0167cf0 random_kthread, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:794
(kgdb) quit
# exit
Script done on Thu Jul 3 23:12:37 2003
pgp0.pgp
Description: PGP signature
Re: libkse crash and sched ule?
On Thu, Jul 03, 2003 at 05:31:02PM -0400, Daniel Eischen wrote: On Thu, 3 Jul 2003, Morten Rodal wrote: I updated to the latest sources early today (CEST time) and install rtld-elf with libmap support in order to give KSE another try. However upon starting the Mozilla Firebird executable with very simple /etc/libmap.conf: libc_r.so.5 libkse.so.1 libc_r.so libkse.so the computer starts to dump core in the background (I haven't got a serial cable right here) and then reboots. Apart from stripping all the devices I haven't got from GENERIC kernel I have added SCHED_ULE. Is there a know problem with using SCHED_ULE and KSE? What happens with SCHED_4BSD? I have just recompiled the kernel to use SCHED_4BSD and have not yet experienced a crash. top(1) is happily showing four MozillaFirebird-bin threads. -- Morten Rodal pgp0.pgp Description: PGP signature
Re: who am i
On Fri, Jul 04, 2003 at 12:46:10AM +0200, Richard Arends wrote: Hello, Please take a look at this: = [snowlap] ~$ who am i richard ttyp5Jul 4 00:34 (:0.0) [snowlap] ~$ su - Password: Last login: Fri Jul 4 00:31:17 on ttyp5 snowlap# who am i root ttyp5Jul 4 00:34 snowlap# exit logout [snowlap] ~$ who am i root ttyp5Jul 4 00:34 = Of course the latest 'who am i' should return 'richard' and not(!) 'root' Regards, Richard. I am seeing the same things, and I reported similar stuff in another mail to this list. Someone suggested that this was a utmp(5) problem and might be a problem with the su(1) program. -- Morten Rodal pgp0.pgp Description: PGP signature
Re: acpi patch for dell laptop?
On Sat, Jun 21, 2003 at 12:13:10AM +0200, Stijn Hoop wrote: On Fri, Jun 20, 2003 at 05:29:30PM -0400, Mike Sturdee wrote: Where can I find the latest, greatest patch that fixes this? Try this URL: http://sandcat.nl/~stijn/freebsd/dell.php and let me know if it works. I was also seeing this errors on a Dell Inspiron 8200, until I followed your instructions. Thank you for making apci (and more importantly the battery level) work again! -- Morten Rodal pgp0.pgp Description: PGP signature
Recent getty(8) changes clobbers w(1)
After the recent getty(8) changes w(1) will now show root logins on the same ttys if you use su(1). However, after logging out the root user is not removed from the w(1) (or who(1) for that matter). Example output from w(1) where tty p0 and p4 have been used to login with root, and currently logged out while p2 is still logged in. [atlantis] ~ w 3:17pm up 5:44, 8 users, load averages: 0,02 0,15 0,31 USER TTY FROM LOGIN@ IDLE WHAT root p0 - 9:40am - vi root p2 - 3:11pm 2 -su (csh) root p4 - 3:14pm - w morten p0 :0.0 3:10pm - vi morten p1 :0.0 9:46am 2 irssi morten p2 :0.0 3:10pm 2 -su (csh) morten p3 :0.0 3:10pm 6 ssh slimy morten p4 :0.0 3:11pm - w As far as I know this started after the getty(8) changes, but it could be some other changes as while. Am I the only one seeing this? The machine is running world and kernel from 16th of June. FreeBSD atlantis.rodal.no 5.1-CURRENT FreeBSD 5.1-CURRENT #31: Mon Jun 16 13:26:24 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/atlantis i386 -- Morten Rodal pgp0.pgp Description: PGP signature
Re: FTP client dumping core
On Wed, Jun 04, 2003 at 03:21:45PM -0300, Fred Souza wrote: Can you rebuild ftpd with ggdb in CFLAGS and repeat the traceback? The ftpd? I don't have access to it, sorry. If you meant the ftp client, here's the output from gdb (the same as before): I think what Kris ment was something similiar to cd /usr/src/usr.bin/ftp make clean make DEBUG_FLAGS=-g all install -- Morten Rodal pgp0.pgp Description: PGP signature
Re: Clock running double time
On Fri, Mar 14, 2003 at 11:14:51PM -0800, [EMAIL PROTECTED] wrote: Has anyone ever seen this? My clock is running double time, that is, each second it advances two seconds. Needless to say, ntpd can't sync up with any servers. This has been reported several times (searching the mailinglist archives gives great results): http://docs.freebsd.org/cgi/getmsg.cgi?fetch=369488+0+archive/2003/freebsd-current/20030223.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=811469+0+archive/2003/freebsd-current/20030216.freebsd-current http://docs.freebsd.org/cgi/getmsg.cgi?fetch=884815+0+archive/2003/freebsd-current/20030126.freebsd-current Read up on those threads and you'll hopefully get it fixed. -- Morten Rodal pgp0.pgp Description: PGP signature
Re: kern/49079: panic: bwrite: buffer is not busy
On Fri, Mar 14, 2003 at 06:47:27PM +0100, Morten Rodal wrote:
[snip the parent post]
I just got another one of these. This time it didn't double panic
while syncing the disks. I've been getting this quite often now,
almost daily. If there is anything else I can help you with to get to
the bottom of this problem don't hesitate to ask.
Attached is a the gdb output and the backtrace from DDB.
--
Morten Rodal
panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id =
Stack backtrace:
backtrace(c0341972,0,c03448b1,d533f988,1) at backtrace+0x17
panic(c03448b1,d533f99c,c0304cd9,d533f99c,c01da2c4) at panic+0x10a
bwrite(cc9a5fe8,d533fa34,c02220e2,cc9a5fe8,cc9a6118) at bwrite+0x152
bawrite(cc9a5fe8,cc9a6118,4,d533fd48,2002) at bawrite+0x1c
cluster_wbuild(c41b1a44,4000,e,0,6) at cluster_wbuild+0x732
cluster_write(cc9afa98,58000,0,2,c3fdc300) at cluster_write+0x571
ffs_write(d533fbc4,20002,c38d5c30,0,d533fc70) at ffs_write+0x5cf
vn_write(c3ec26cc,d533fc70,c3fdc300,0,c38d5c30) at vn_write+0x20d
dofilewrite(c38d5c30,c3ec26cc,1d,859e800,200) at dofilewrite+0xe8
write(c38d5c30,d533fd10,c,d533fd20,3) at write+0x69
syscall(8e4002f,2f,bfbf002f,0,2808f100) at syscall+0x2ac
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4), eip = 0x285ba6d3, esp = 0xbfbff21c, ebp = 0xbfbff258 ---
Script started on Sat Mar 15 23:02:18 2003
slurp# gdb -k kernel.3 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:
---
panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id =
Stack backtrace:
boot() called on cpu#1
syncing disks, buffers remaining... 3452 3452 3451 3451 3449 3448 3448 3448 3448 3448
3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448
giving up on 110 buffers
Uptime: 48m16s
Dumping 447 MB
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 16[CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 32[CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 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
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc01d457f in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01d4907 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc02194e2 in bwrite (bp=0xcc9a5fe8) at /usr/src/sys/kern/vfs_bio.c:802
#4 0xc0219e6c in bawrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1144
#5 0xc02220e2 in cluster_wbuild (vp=0xc41b1a44, size=16384, start_lbn=17,
len=6) at /usr/src/sys/kern/vfs_cluster.c:966
#6 0xc0221931 in cluster_write (bp=0xcc9afa98, filesize=360448, seqcount=2)
at /usr/src/sys/kern/vfs_cluster.c:566
#7 0xc02aa1ef in ffs_write (ap=0xd533fbc4)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:726
#8 0xc023885d in vn_write (fp=0xc3ec26cc, uio=0xd533fc70,
active_cred=0xc3fdc300, flags=0, td=0xc38d5c30) at vnode_if.h:417
#9 0xc01f7fb8 in dofilewrite (td=0xc38d5c30, fp=0xc3ec26cc, fd=0,
buf=0x859e800, nbyte=0, offset=0, flags=0) at file.h:239
#10 0xc01f7df9 in write (td=0xc38d5c30, uap=0xd533fd10)
at /usr/src/sys/kern/sys_generic.c:329
#11 0xc030d09c in syscall (frame=
{tf_fs = 149159983, tf_es = 47, tf_ds = -1078001617, tf_edi = 0, tf_esi =
671674624, tf_ebp = -1077939624, tf_isp = -718013068, tf_ebx = 671686852, tf_edx = 29,
tf_ecx = 0, tf_eax = 4, tf_trapno = 0, tf_err = 2, tf_eip = 677095123, tf_cs = 31,
tf_eflags = 518, tf_esp = -1077939684, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1030
#12 0xc02f52cd in Xint0x80_syscall () at {standard input}:139
---Can't read userspace from dump, or kernel process---
(kgdb) slurp# ^Dexit
Script done on Sat Mar 15 23:02:30 2003
pgp0.pgp
Description: PGP signature
Re: kern/49079: panic: bwrite: buffer is not busy
On Sun, Mar 16, 2003 at 02:46:13AM -0500, Jeff Roberson wrote:
On Sat, 15 Mar 2003, Morten Rodal wrote:
On Fri, Mar 14, 2003 at 06:47:27PM +0100, Morten Rodal wrote:
[snip the parent post]
I just got another one of these. This time it didn't double panic
while syncing the disks. I've been getting this quite often now,
almost daily. If there is anything else I can help you with to get to
the bottom of this problem don't hesitate to ask.
Attached is a the gdb output and the backtrace from DDB.
Excelent, can you open up the kernel in gdb again. Then do the following:
frame 3
print bp
With this information I should be able to find the problem.
--
Morten Rodal
Script started on Sun Mar 16 08:57:26 2003
slurp# gdb -k kernel.3 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:
---
panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id =
Stack backtrace:
boot() called on cpu#1
syncing disks, buffers remaining... 3452 3452 3451 3451 3449 3448 3448 3448 3448 3448
3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448 3448
giving up on 110 buffers
Uptime: 48m16s
Dumping 447 MB
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 16[CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 32[CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 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
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) frame 3
#3 0xc02194e2 in bwrite (bp=0xcc9a5fe8) at /usr/src/sys/kern/vfs_bio.c:802
802 panic(bwrite: need chained iodone);
(kgdb) print bp
$1 = (struct buf *) 0xcc9a5fe8
(kgdb) print *bp
$2 = {b_io = {bio_cmd = 2, bio_dev = 0x, bio_disk = 0x0,
bio_blkno = 4188480, bio_offset = 2145681408, bio_bcount = 16384,
bio_data = 0xd219e000 , bio_flags = 0, bio_error = 0, bio_resid = 0,
bio_done = 0xc021d1f0 bufdonebio, bio_driver1 = 0x0, bio_driver2 = 0x0,
bio_caller1 = 0xc39c9400, bio_caller2 = 0xcc9a5fe8, bio_queue = {
tqe_next = 0x0, tqe_prev = 0xc39c940c}, bio_attribute = 0x0,
bio_from = 0x0, bio_to = 0x0, bio_length = 0, bio_completed = 0,
bio_children = 1398, bio_inbed = 0, bio_parent = 0x0, bio_t0 = {sec = 0,
frac = 0}, bio_task = 0, bio_task_arg = 0x0, bio_pblkno = 518876},
b_op = 0xc036e018, b_magic = 280038160,
b_iodone = 0xc0221300 cluster_callback, b_offset = 262144, b_vnbufs = {
tqe_next = 0x0, tqe_prev = 0x0}, b_left = 0x0, b_right = 0x0,
b_vflags = 0, b_freelist = {tqe_next = 0xcc9a5908, tqe_prev = 0xc03a145c},
b_qindex = 0, b_flags = 1677721604, b_xflags = 0 '\0', b_lock = {
lk_interlock = 0xc039b7a4, lk_flags = 0, lk_sharecount = 0,
lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 80,
lk_wmesg = 0xc034482b bufwait, lk_timo = 0, lk_lockholder = 0x,
lk_newlock = 0x0}, b_bufsize = 16384, b_runningbufspace = 0,
b_kvabase = 0xd219e000 , b_kvasize = 16384, b_lblkno = 16,
b_vp = 0xc41b1a44, b_object = 0x0, b_dirtyoff = 0, b_dirtyend = 16384,
b_rcred = 0x0, b_wcred = 0x0, b_saveaddr = 0xd219e000, b_pager = {
pg_spc = 0x0, pg_reqpage = 0}, b_cluster = {cluster_head = {
tqh_first = 0xccab02f8, tqh_last = 0xccab0420}, cluster_entry = {
tqe_next = 0xccab02f8, tqe_prev = 0xccab0420}}, b_pages = {0xc0f97d08,
0xc0f80c50, 0xc0f92398, 0xc0e9cfe0, 0xc0eefc48, 0xc0efd490, 0xc0a8a3d8,
0xc0f04120, 0xc0a85c68, 0xc0a853b0, 0xc0a3c1f8, 0xc0f1a140, 0xc0de4288,
0xc0f468d0, 0xc0ac3c18, 0xc0a61e60, 0xc0a4fea8, 0xc0f175f0, 0xc0de5638,
0xc0dee680, 0xc0ddeac8, 0xc0f07210, 0xc0a9fe58, 0xc0f462a0, 0xc0dd40e8,
0xc0f3a630, 0xc0ef4178, 0xc0f3dcc0, 0xc0de6b08, 0xc0f3b050, 0xc0f17998,
0xc0dd81e0}, b_npages = 4, b_dep = {lh_first = 0x0}}
(kgdb) slurp# ^Dexit
Script done on Sun Mar 16 08:57:55 2003
pgp0.pgp
Re: kern/49079: panic: bwrite: buffer is not busy
On Thu, Mar 13, 2003 at 03:05:03AM -0500, Jeff Roberson wrote: On Tue, 11 Mar 2003, Doug Barton wrote: It won't. I have 1.376 of vfs_bio.c, and -current as of the 7th, and I just got another one of these last night. The panic message is the same as I've been getting, but the bremfree message is slightly different, if that helps any. I have 1.378 of vfs_bio.c and I just got one of these panics. Kernel built on 13th of March. (Thu Mar 13 16:25:15 CET 2003) Can anyone tell me when this started? Or perhaps backup your sources until this goes away? I am not able to reproduce this. Can you give me the following information. I am not sure, but my computer fist panic with this on March 6th. Type of machine, cpu, memory, etc. Dual Pentium II 300MHz 447MB SDRAM Mounted filesystems and their block size. /dev/da0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/da0s1e on /tmp (ufs, local, soft-updates) /dev/da0s1f on /usr (ufs, local, soft-updates) /dev/ad0s1e on /usr/home (ufs, local, nosuid, soft-updates) /dev/ad0s1d on /usr/local (ufs, local, soft-updates) /dev/ad2s1e on /mnt/media (ufs, local, nosuid, soft-updates) /dev/da0s1d on /var (ufs, local, nosuid, soft-updates) I have attached the output of the disklabel command. Hopefully that will tell you the block size (I am unsure about where to find it). I am not sure if this is related but the disklabel command issued a warning on all three hardisks that partition c didn't cover the whole unit. Type of workload. I was web browsing and listening to music with xmms. Not very heavy load or much disk activity. -- Morten Rodal # /dev/ad0s1c: type: ESDI disk: ad0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 33483 sectors/unit: 33750864 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] c: 337508010unused0 0 # (Cyl.0 - 33482*) d: 1048576004.2BSD 2048 16384 28512 # (Cyl.0 - 10402*) e: 23265041 104857604.2BSD 2048 16384 28512 # (Cyl. 10402*- 33482*) # /dev/ad2s1c: type: ESDI disk: ad2s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 5605 sectors/unit: 90060327 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] c: 900603270unused0 0 # (Cyl.0 - 5605*) e: 9006032704.2BSD 2048 1638489 # (Cyl.0 - 5605*) # /dev/da0s1c: type: SCSI disk: da0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 1044 sectors/unit: 16777215 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: 209715204.2BSD 2048 16384 28512 # (Cyl.0 - 130*) b: 1793168 2097152 swap# (Cyl. 130*- 242*) c: 167717970unused0 0 # (Cyl.0 - 1043*) d: 524288 38903204.2BSD 2048 16384 32776 # (Cyl. 242*- 274*) e: 524288 44146084.2BSD 2048 16384 32776 # (Cyl. 274*- 307*) f: 11832901 49388964.2BSD 2048 16384 28512 # (Cyl. 307*- 1043*) pgp0.pgp Description: PGP signature
panic: bwrite: buffer is not busy???
I briefly searched my mailbox for other panics with this panic string,
but all the others seem to be due to tcp_input and not the filesystem
(as I suspect mine is). The machine is running a SMP kernel built
yesterday (Wed Mar 5 22:50:35 CET 2003).
Unfortunatly I was not able to save the stack backtrace from DDB, but
I hope the gdb backtrace will help someone figure out what may have
caused this.
--
Morten Rodal
Script started on Thu Mar 6 19:30:12 2003
slurp# gdb -k kernel.1 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:
---
panic: bwrite: buffer is not busy???
cpuid = 0; lapic.id = 0100
Stack backtrace:
boot() called on cpu#0
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
Uptime: 18h38m45s
Dumping 447 MB
16[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] 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
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc01d43ca in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01d46a7 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc0218dc2 in bwrite (bp=0xccb1ec98) at /usr/src/sys/kern/vfs_bio.c:795
#4 0xc021a909 in vfs_bio_awrite (bp=0xccb1ec98)
at /usr/src/sys/kern/vfs_bio.c:1692
#5 0xc02a881a in ffs_fsync (ap=0xe35928a4)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:257
#6 0xc02a78f9 in ffs_sync (mp=0xc3a73200, waitfor=2, cred=0xc1376e80,
td=0xc0363180) at vnode_if.h:612
#7 0xc022f8bb in sync (td=0xc0363180, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#8 0xc01d3fab in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280
#9 0xc01d46a7 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#10 0xc0218dc2 in bwrite (bp=0xcca077d8) at /usr/src/sys/kern/vfs_bio.c:795
#11 0xc021974c in bawrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1138
#12 0xc022178a in cluster_wbuild (vp=0xc3cf85b4, size=16384, start_lbn=50,
len=2) at /usr/src/sys/kern/vfs_cluster.c:996
#13 0xc0220d7f in cluster_write (bp=0xcca47310, filesize=847872, seqcount=1)
at /usr/src/sys/kern/vfs_cluster.c:596
#14 0xc02a949f in ffs_write (ap=0xe3592bc4)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:836
#15 0xc0237c7d in vn_write (fp=0xc41b2ca8, uio=0xe3592c70,
active_cred=0xc3aa7380, flags=0, td=0xc4152780) at vnode_if.h:417
#16 0xc01f7928 in dofilewrite (td=0xc4152780, fp=0xc41b2ca8, fd=0,
buf=0x8e12e00, nbyte=0, offset=0, flags=0) at file.h:239
#17 0xc01f7769 in write (td=0xc4152780, uap=0xe3592d10)
at /usr/src/sys/kern/sys_generic.c:329
#18 0xc030be8c in syscall (frame=
{tf_fs = 262191, tf_es = 47, tf_ds = -1079246801, tf_edi = 0, tf_esi =
671674624, tf_ebp = -1077939880, tf_isp = -480694924, tf_ebx = 671686852, tf_edx = 29,
tf_ecx = 0, tf_eax = 4, tf_trapno = 22, tf_err = 2, tf_eip = 677083971, tf_cs = 31,
tf_eflags = 518, tf_esp = -1077939940, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1030
#19 0xc02f404d in Xint0x80_syscall () at {standard input}:139
---Can't read userspace from dump, or kernel process---
(kgdb) slurp# ^Dexit
Script done on Thu Mar 6 19:30:29 2003
pgp0.pgp
Description: PGP signature
Re: panic: bwrite: buffer is not busy???
On Thu, Mar 06, 2003 at 08:50:41PM +0100, Attila Nagy wrote: Hello, I briefly searched my mailbox for other panics with this panic string, but all the others seem to be due to tcp_input and not the filesystem (as I suspect mine is). The machine is running a SMP kernel built yesterday (Wed Mar 5 22:50:35 CET 2003). Is it like this one? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/46861 No, these seem to be caused by a bug in the tcp code (may be fixed in -current?) -- Morten Rodal pgp0.pgp Description: PGP signature
Re: -O2 considered harmful
On Thu, Feb 27, 2003 at 05:49:47AM -0500, Geoffrey wrote: This is fine and good, but make.conf appears to be hiding in 5.0 (or at least in the various installs/cvsups I've encountered to date). What flags are accepted is a bit of a guessing game without a template in /etc/defaults (yes, I could wade through man pages but with the rate of change on release, those recommendations aren't a given either). Have you looked at the make.conf in /usr/share/examples/etc ? -- Morten Rodal pgp0.pgp Description: PGP signature
Re: patch for the nVidia driver and -CURRENT
On Tue, Feb 25, 2003 at 07:28:09PM +0100, Maxime Henrion wrote:
[snip a lot of the patch]
@@ -1431,7 +1442,8 @@
SLIST_FOREACH(at, sc-alloc_list, list) {
if (offset = at-address
offset at-address + at-size)
-return atop(vtophys(offset));
+*paddr = vtophys(offset);
+return 0;
}
return -1;
Should the function return 0 even if the if (offset..) fails? I have
no clue about the nvidia kernel driver (or kernel stuff at all) but it
seems to me that the only way the function can return -1 is if the
list is empty.
--
Morten Rodal
pgp0.pgp
Description: PGP signature
Re: ACPI: -dp2 vs. -release
On Thu, Feb 20, 2003 at 02:45:27PM +0100, Peter Gade Jensen wrote: I installed the DP2 release of current on my Toshiba laptop when it was released and acpi worked very well. When the powercable was disconected the profile changed to economic _and_ the screen was dimmed a little bit to save power. But with every other iso release or cvsup from head since, acpi doesn't dim the screen anymore when running on batteries? what has changed or what can I do to make this work again(besides reverting back t -dp2)? I have the same feature on my Dell laptop. The screen's brightness (or dim if you want) will go down when the computer is running on batteries. It is however possible to change this back to normal with the Fn key (you probably have something similiar on your Toshiba) so that the brightness back to normal. Dell laptops remember this, so the next time I run the computer on batteries it will restore the brightness to the level I had last time I used it on batteries. If the Toshiba is simliar in this way all you have to do is adjust the brightness level (can be done in the BIOS of Dell too) down to a desired level and it will remember it. I do not think this has anything to do with ACPI implimentation in FreeBSD. -- Morten Rodal msg52765/pgp0.pgp Description: PGP signature
Re: Panic in fork()
On Sat, Feb 08, 2003 at 01:24:06AM -0800, Kris Kennaway wrote: Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = 0100 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01a1e2d stack pointer = 0x10:0xe4146c74 frame pointer = 0x10:0xe4146cbc 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 = 2 (sh) kernel: type 12 trap, code=0 Stopped at fork1+0x3fd:cmpl%ebx,0x14(%eax) db trace fork1(c6ee5000,14,0,e4146cd4,c6c04788) at fork1+0x3fd fork(c6ee5000,e4146d10,c03445dc,407,0) at fork+0x52 syscall(2f,2f,2f,80f9cb4,80fe000) at syscall+0x28e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (2, FreeBSD ELF32, fork), eip = 0x807bd63, esp = 0xbfbff69c, ebp = 0xbfbff6c8 --- db Is this anything like the one I experienced in late January? http://www.freebsd.org/cgi/getmsg.cgi?fetch=1447263+1454677+/usr/local/www/db/text/2003/freebsd-current/20030126.freebsd-current -- Morten Rodal msg51985/pgp0.pgp Description: PGP signature
Re: Panic in fork()
On Sat, Feb 08, 2003 at 03:05:12AM -0800, Kris Kennaway wrote:
bento# addr2line -e kernel.debug 0xc01a1e2d
../../../kern/kern_fork.c:388
for (; p2 != NULL; p2 = LIST_NEXT(p2, p_list)) {
PROC_LOCK(p2);
388 -- while (p2-p_pid == trypid ||
That is the exact same spot I saw my computer (old smp machine) crash.
I think someone mentioned that it would be more or less impossible to
crash there since one would not enter the for loop when p2 is NULL.
Could it be that PROC_LOCK tampers with p2?
Also see my other post to your original message.
--
Morten Rodal
msg51994/pgp0.pgp
Description: PGP signature
Re: panic in fork() on SMP 5.0-RELEASE
On Mon, Jan 27, 2003 at 03:27:00PM -0500, John Baldwin wrote:
Do you still have the kernel.debug from this kernel lying around?
Can you pop gdb up on it and do 'l *0xc01bdb48' please? That is
the instruction pointer from the fault and will give the line that
the actual panic occurred at.
(kgdb) l *0xc01bdb48
0xc01bdb48 is in fork1 (/usr/src/sys/kern/kern_fork.c:388).
383 */
384 p2 = LIST_FIRST(allproc);
385 again:
386 for (; p2 != NULL; p2 = LIST_NEXT(p2, p_list)) {
387 PROC_LOCK(p2);
388 while (p2-p_pid == trypid ||
389 p2-p_pgrp-pg_id == trypid ||
390 p2-p_session-s_sid == trypid) {
391 trypid++;
392 if (trypid = pidchecked) {
--
Morten Rodal
msg51029/pgp0.pgp
Description: PGP signature
panic in fork() on SMP 5.0-RELEASE
Is this a known panic? I tried to search the mailinglist archives to
see if somebody had posted something similar, but I couldn't find
anything.
The system is running 5.0-RELEASE with a pretty standard kernel (just
removed all the drivers I don't use and added SMP support). I think
the load of the system might have been high at the moment as I had
just started
cd /usr/ports make -j8 clean
before I went to eat dinner. When I came back a few hours later it at
rebooted, with this panic.
I have attached the backtrace of this (dual?) panic. I have never
poked in the kernel source code before, so if there is anything else
you need to know just ask and I'll see what I can do.
--
Morten Rodal
Script started on Sat Jan 25 21:17:42 2003
slurp# gdb -k kernel.0 vmcore.0
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 = 0100
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01bdb48
stack pointer = 0x10:0xe3ac4c04
frame pointer = 0x10:0xe3ac4cac
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 = 580 (sh)
trap number = 12
panic: page fault
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
Uptime: 5d18h59m34s
Dumping 447 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
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc01d4bea in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc01d4ea7 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc021a852 in bwrite (bp=0xcca8c150) at /usr/src/sys/kern/vfs_bio.c:796
#4 0xc021bf46 in vfs_bio_awrite (bp=0xcca8c150) at /usr/src/sys/kern/vfs_bio.c:1643
#5 0xc019e203 in spec_fsync (ap=0xe3ac49f4) at
/usr/src/sys/fs/specfs/spec_vnops.c:462
#6 0xc019d558 in spec_vnoperate (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:126
#7 0xc02a9c62 in ffs_sync (mp=0xc3a37000, waitfor=2, cred=0xc1376e80, td=0xc035e900)
at vnode_if.h:612
#8 0xc022fb9b in sync (td=0xc035e900, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:138
#9 0xc01d47cb in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:273
#10 0xc01d4ea7 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#11 0xc030b662 in trap_fatal (frame=0xe3ac4bc4, eva=0) at
/usr/src/sys/i386/i386/trap.c:844
#12 0xc030b312 in trap_pfault (frame=0xe3ac4bc4, usermode=0, eva=20) at
/usr/src/sys/i386/i386/trap.c:758
#13 0xc030ae02 in trap (frame=
{tf_fs = -475267048, tf_es = -1070792688, tf_ds = -988741616, tf_edi =
-1070209248, tf_esi = -988528640, tf_ebp = -475247444, tf_isp = -475247632, tf_ebx =
582, tf_edx = -989019040, tf_ecx = -988528640, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1071916216, tf_cs = 8, tf_eflags = 66195, tf_esp = -1053458112, tf_ss = 1})
at /usr/src/sys/i386/i386/trap.c:445
#14 0xc02f3918 in calltrap () at {standard input}:99
#15 0xc01bd2f0 in fork (td=0xc5144000, uap=0xe3ac4d10) at
/usr/src/sys/kern/kern_fork.c:124
#16 0xc030b9bc in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1, tf_esi = 135258112, tf_ebp =
-1077938280, tf_isp = -475247244, tf_ebx = 135236344, tf_edx = 135236332, tf_ecx =
-1077938240, tf_eax = 2, tf_trapno = 12, tf_err = 2, tf_eip = 134723859, tf_cs = 31,
tf_eflags = 514, tf_esp = -1077938324, tf_ss = 47}) at
/usr/src/sys/i386/i386/trap.c:1033
#17 0xc02f396d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---
(kgdb) slurp# ^Dexit
Script done on Sat Jan 25 21:18:04 2003
msg50908/pgp0.pgp
Description: PGP signature
Re: panic in fork() on SMP 5.0-RELEASE
On Sat, Jan 25, 2003 at 12:38:28PM -0800, Nate Lawson wrote: The question is, why? I suspect something to do with memory due to the second two bytes being a valid kernel address. How about a dmesg? [forgot to cc: [EMAIL PROTECTED]] Are you suspecting faulty memory? See attached dmesg.boot. -- Morten Rodal 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-RELEASE #0: Sun Jan 19 17:03:57 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp Preloaded elf kernel /boot/kernel/kernel at 0xc05e2000. Preloaded elf module /boot/kernel/linux.ko at 0xc05e20b4. Preloaded elf module /boot/kernel/snd_sb16.ko at 0xc05e2160. Preloaded elf module /boot/kernel/snd_sbc.ko at 0xc05e2210. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc05e22bc. Preloaded elf module /boot/kernel/nvidia.ko at 0xc05e2368. Preloaded elf module /boot/kernel/acpi.ko at 0xc05e2414. Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (300.68-MHz 686-class CPU) Origin = GenuineIntel Id = 0x634 Stepping = 4 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 469749760 (447 MB) avail memory = 449974272 (429 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS P2L97-DS on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 7 entries at 0xc00f0d20 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #0 intpin 19 - irq 2 IOAPIC #0 intpin 18 - irq 7 agp0: Intel 82443LX (440 LX) host to PCI bridge mem 0xe400-0xe7ff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 IOAPIC #0 intpin 16 - irq 11 nvidia0: GeForce2 GTS mem 0xd800-0xdfff,0xd600-0xd6ff irq 11 at device 0.0 on pci1 isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xd400-0xd41f irq 2 at device 4.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.03, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. Timecounter PIIX frequency 3579545 Hz pci0: bridge, PCI-unknown at device 4.3 (no driver attached) ahc0: Adaptec aic7880 Ultra SCSI adapter port 0xd000-0xd0ff mem 0xd580-0xd5800fff irq 2 at device 6.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs xl0: 3Com 3c905-TX Fast Etherlink XL port 0xb800-0xb83f irq 7 at device 10.0 on pci0 xl0: Ethernet address: 00:10:4b:3e:23:58 miibus0: MII bus on xl0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 orm0: Option ROMs at iomem 0xcc000-0xd0fff,0xc-0xcb7ff on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sbc0: Creative SB AWE64 Gold at port 0x388-0x38b,0x330-0x331,0x220-0x22f irq 5 drq 5,1 on isa0 pcm0: SB16 DSP 4.16 on sbc0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec ad0: 16479MB Maxtor 91728D8 [33483/16/63] at ata0-master UDMA33 ad2: 43979MB IBM-DTLA-307045 [89355/16/63] at ata1-master UDMA33 acd0: DVD-ROM CREATIVEDVD-ROM DVD2240E 12/24/97 at ata0-slave PIO4 Waiting 15 seconds for SCSI devices to settle cd0 at ahc0 bus 0 target 4 lun 0 cd0: PLEXTOR CD-R PX-R820T 1.03 Removable CD-ROM SCSI-2 device cd0: 5.000MB/s transfers (5.000MHz, offset 8) cd0: cd present [327986 x 2048 byte records] da0 at ahc0 bus 0 target 6 lun 0 da0: QUANTUM FIREBALL SE8.4S PJ09 Fixed Direct Access SCSI-2
Re: GCC 3.2
On Sun, Aug 18, 2002 at 03:27:31PM +0200, Martin Blapp wrote: Hi, Any plans or ideas when gcc3.2 will be imported ? Martin I think if you search the mailinglist archive you will find your answer quickly (it has been addressed several times). -- Morten Rodal // // PGP ID 2D75595B // 22DE D67A 1AEA EF94 872A 9384 6D67 B50B 2D75 595B // msg41985/pgp0.pgp Description: PGP signature
Re: Rewrite of the perl script rmuser to C
On Sat, Aug 10, 2002 at 02:02:39PM +0200, Eirik Nygaard wrote: I have just rewritten the rmuser perl script to C, it would be great if you could take a look at it and check if everything is ok. You should probably replace the strcpy() and strcat() with strlcpy(3) and strlcat(3), or at least use the strncpy(3) and strncat(3). Also, sprintf() should be replaced with snprintf(3). Maybe close the file descriptors in the signal handlers? How do I get this commited? Now that I cannot answer for :) -- Morten Rodal // // PGP ID 2D75595B // 22DE D67A 1AEA EF94 872A 9384 6D67 B50B 2D75 595B // msg41750/pgp0.pgp Description: PGP signature
