Re: kernel panic with today's CURRENT on sparc64 at boot
On Wed, Jan 22, 2003 at 08:59:51PM +0100, Thomas Moestl wrote: On Tue, 2003/01/21 at 17:33:42 +, [EMAIL PROTECTED] wrote: Hi cvsup'd to . today on an E220R, single CPU with two Symbios scsi cards. Box had been running fine with RC3, but would not boot with -CURRENT kernel: Current: hme4: Ethernet address: 08:00:20:b7:ef:44 miibus4: MII bus on hme4 ukphy3: Generic IEEE 802.3u media interface on miibus4 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sym0: 875 port 0x1000-0x10ff mem 0x1090a000-0x1090afff,0x10908000-0x109080ff i rq 32 at device 3.0 on pci0 panic: trap: fast data access mmu miss cpuid = 0; Debugger(panic) Stopped at Debugger+0x1c: ta %xcc, 1 Can you please cvsup again to pick up some changes that were made yesterday and try again? Hi there Well, after a panic last night in IPFW on -RELEASE, I decided to try -CURRENT again. I just CVSUP'd, built kernel and rebooted. Here's what happened: FreeBSD/sparc64 bootstrap loader, Revision 1.0 ([EMAIL PROTECTED], Wed Jan 22 11:31:27 GMT 2003) bootpath=/pci@1f,4000/scsi@3/disk@0,0:a Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x2cc308+0xe4178 syms=[0x8+0x44310+0x8+0x34e6f] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... nothing to autoload yet. jumping to kernel entry at 0xc0038000. stray vector interrupt 2029 Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #7: Fri Jan 24 10:36:24 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NS Preloaded elf kernel /boot/kernel/kernel at 0xc042c000. Timecounter tick frequency 450026203 Hz cpu0: Sun Microsystems UltraSparc-II Processor (450.03 MHz CPU) Model: SUNW,Ultra-60 Initializing GEOMetry subsystem nexus0: OpenFirmware Nexus device pcib0: U2P UPA-PCI bridge on nexus0 pcib0: Psycho, impl 0, version 4, ign 0x7c0 initialializing counter-timer Timecounter counter-timer frequency 100 Hz DVMA map: 0xfe00 to 0x device 0/1/0: latency timer 0 - 82 pcib0: ofw_pci_init: no interrupt mapping found for 0/1/0 (preset 128) device 0/1/1: latency timer 0 - 82 pcib0: ofw_pci_init: mapping intr for 0/1/1 to 33 (preset was 0) device 0/3/0: latency timer 0 - 140 pcib0: ofw_pci_init: mapping intr for 0/3/0 to 32 (preset was 0) device 0/3/1: latency timer 0 - 140 pcib0: ofw_pci_init: mapping intr for 0/3/1 to 38 (preset was 0) PCI-PCI bridge at 0/2/0: setting bus #s to 0/1/1 pcib0: ofw_pci_init: descending to subordinate PCI bus device 1/0/0: latency timer 0 - 82 pcib0: ofw_pci_init: mapping intr for 1/0/0 to 16 (preset was 0) device 1/0/1: latency timer 0 - 82 pcib0: ofw_pci_init: mapping intr for 1/0/1 to 17 (preset was 0) device 1/1/0: latency timer 0 - 82 pcib0: ofw_pci_init: mapping intr for 1/1/0 to 17 (preset was 0) device 1/1/1: latency timer 0 - 82 pcib0: ofw_pci_init: mapping intr for 1/1/1 to 18 (preset was 0) device 1/2/0: latency timer 0 - 82 pcib0: ofw_pci_init: mapping intr for 1/2/0 to 18 (preset was 0) device 1/2/1: latency timer 0 - 82 pcib0: ofw_pci_init: mapping intr for 1/2/1 to 19 (preset was 0) device 1/3/0: latency timer 0 - 82 pcib0: ofw_pci_init: mapping intr for 1/3/0 to 19 (preset was 0) device 1/3/1: latency timer 0 - 82 pcib0: ofw_pci_init: mapping intr for 1/3/1 to 16 (preset was 0) PCI-PCI bridge at 0/4/0: setting bus #s to 0/2/2 pcib0: ofw_pci_init: descending to subordinate PCI bus device 2/0/0: latency timer 0 - 82 pcib0: ofw_pci_init: mapping intr for 2/0/0 to 24 (preset was 0) device 2/0/1: latency timer 0 - 82 pcib0: ofw_pci_init: mapping intr for 2/0/1 to 25 (preset was 0) device 2/1/0: latency timer 0 - 82 pcib0: ofw_pci_init: mapping intr for 2/1/0 to 25 (preset was 0) device 2/1/1: latency timer 0 - 82 pcib0: ofw_pci_init: mapping intr for 2/1/1 to 26 (preset was 0) device 2/2/0: latency timer 0 - 82 pcib0: ofw_pci_init: mapping intr for 2/2/0 to 26 (preset was 0) device 2/2/1: latency timer 0 - 82 pcib0: ofw_pci_init:
Re: kernel panic with today's CURRENT on sparc64 at boot
On Fri, 2003/01/24 at 11:54:41 +, Steven Haywood wrote:
hme6: Sun HME 10/100 Ethernet mem 0xc80-0xc807fff irq
26 at device 1.1 on
pci2
hme6: DMA buffer map load error 12
hme6: could not be configured
device_probe_and_attach: hme6 attach returned 6
pci2: bridge, PCI-unknown at device 2.0 (no driver
attached)
hme6: Sun HME 10/100 Ethernet mem 0xe80-0xe807fff irq
27 at device 2.1 on
pci2
hme6: DMA buffer map load error 12
hme6: could not be configured
device_probe_and_attach: hme6 attach returned 6
pci2: bridge, PCI-unknown at device 3.0 (no driver
attached)
pci2: bridge, PCI-unknown at device 3.0 (no driver
attached)
n pci2
hme6: DMA buffer map load error 12
hme6: could not be configured
device_probe_and_attach: hme6 attach returned 6
pci0: display at device 5.0 (no driver attached)
pcib3: U2P UPA-PCI bridge on nexus0
pcib3: Psycho, impl 0, version 4, ign 0x7c0
pci3: PCI bus on pcib3
Timecounters tick every 10.000 msec
ipfw2 initialized, divert disabled, rule-based forwarding
enabled, default to de
ny, logging limited to 100 packets/entry by default
Waiting 5 seconds for SCSI devices to settle
da0 at sym0 bus 0 target 1 lun 0
da0: FUJITSU MAG3091L SUN9.0G Fixed Direct Access
SCSI-2 device
da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit),
Tagged Queueing Enabled
da0: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C)
Mounting root from ufs:/dev/da0a
exec /sbin/init: error 8
init: not found in path
/sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall
panic: no init
cpuid = 0;
Debugger(panic)
Stopped at Debugger+0x1c: ta %xcc, 1
This is probably easy to work around for you by increasing the amount
of available DVMA:
--
diff -u -r1.26 psycho.c
--- sparc64/pci/psycho.c21 Jan 2003 08:56:14 - 1.26
+++ sparc64/pci/psycho.c24 Jan 2003 16:05:00 -
@@ -565,7 +565,7 @@
sc-sc_is-is_sb[1] = 0;
if (OF_getproplen(sc-sc_node, no-streaming-cache) 0)
sc-sc_is-is_sb[0] = sc-sc_pcictl + PCR_STRBUF;
- psycho_iommu_init(sc, 2);
+ psycho_iommu_init(sc, 3);
} else {
/* Just copy IOMMU state, config tag and address */
sc-sc_is = osc-sc_is;
--
If that still doesn't help, you can further increase the constant to 4
or 5 (at the expense of another 64kB or 192kB of memory).
- Thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kernel panic with today's CURRENT on sparc64 at boot
On Fri, Jan 24, 2003 at 05:10:07PM +0100, Thomas Moestl wrote:
This is probably easy to work around for you by increasing the amount
of available DVMA:
--
diff -u -r1.26 psycho.c
--- sparc64/pci/psycho.c 21 Jan 2003 08:56:14 - 1.26
+++ sparc64/pci/psycho.c 24 Jan 2003 16:05:00 -
@@ -565,7 +565,7 @@
sc-sc_is-is_sb[1] = 0;
if (OF_getproplen(sc-sc_node, no-streaming-cache) 0)
sc-sc_is-is_sb[0] = sc-sc_pcictl + PCR_STRBUF;
- psycho_iommu_init(sc, 2);
+ psycho_iommu_init(sc, 3);
} else {
/* Just copy IOMMU state, config tag and address */
sc-sc_is = osc-sc_is;
--
If that still doesn't help, you can further increase the constant to 4
or 5 (at the expense of another 64kB or 192kB of memory).
I upped it to 4, recompiled and it works! Thanks :)
Steven
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Options MAXMEM added to GENERIC kernel config causes kernel panic in -current
In the last episode (Jan 23), Vincent Poy said: Greetings everyone, With the latest -CURRENTs ever since atleast September 12, 2002 that I have tested on several different machines ranging from PII/PIII/PIV Desktop and Notebooks, whenever the following option is added to the GENERIC kernel config, the kernel will panic on booting up. I used this option in the January 2002 -currents without problems. The tested systems range in memory from 128MB to 1GIG. options MAXMEM=786432 I have used the equivalent loader variable hw.physmem to limit memory usage for quite a while with no panics. Try putting hw.physmem=768M in /boot/loader.conf and see if it does what you want. Physical memory use set to 786432K [...] real memory = 536870912 (524288K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00651000 - 0x1fff7fff, 530214912 bytes (129447 pages) avail memory = 513802240 (501760K bytes) It looks like there is just 512M of available memory in the system anyhow. Setting MAXMEM to 768M isn't going to do you any good. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Options MAXMEM added to GENERIC kernel config causes kernel panic in -current
On Thu, Jan 23, 2003 at 05:40:16PM -1000, Vincent Poy wrote: /boot/kernel/acpi.ko text=0x2fab4 data=-0x1a84+0x6e0 syms=[0x4+0x5540+0x702d|] snip embedded 0 6 A 0x60 3 4 5 6 7 9 10 11 12 14 15 panic: pmap_mapdev: Couldn't alloc kernel virtual memory Debugger(panic) Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0 db trace Debugger(c0435e9c) at Debugger+0x45 panic(c0460ba0,0,0,c064cbc4,0) at panic+0x7c pmap_mapdev(1ffd,0,c064cc54,c064cbd4,c060547a) at pmap_mapdev+0x5d AcpiOsMapMemory(1ffd,0,0,c064cbc4,0) at AcpiOsMapMemory+0x12 AcpiTbGetThisTable(c064cc54,c064cc08,c064cc64,c064cc54,c064cc54) at AcpiTbGetThisTable+0xa6 AcpiTbGetTableBody(c064cc54,c064cc08,c064cc64,0,0) at AcpiTbTableBody+0x3b AcpiTbGetTable(c064cc54,c064cc64,c064cc54,9,1ffd) at AcpiTbGetTable+0x29 AcpiTbGetTableRsdt(1,fd6e0,0,c061a520,c159ec80) at AcpiTbGetTableRsdt+0x1a AcpiLoadTables(0,c66d8118,c061a3c8,c1586aa0,c064ccfc) at AcpiLoadTables+0x85 acpi_identify(c061a3c8,c159ec80) at acpi_identify+0x99 bus_generic_probe(c159ec80,c66b1090,c064cd34,c028e724,c159ec80) at bus_generic_probe+0x54 nexus_probe(c159ec80) at nexus_probe+0x186 device_probe_child(c159ef00,c159ec80,c028e4e5,c15917c8,1) at device_probe_child+0xcc device_probe_and_attach(c159ec80) at device_probe_and_attach+0x4b root_bus_configure(c159ef00,c045b660,0,4) at root_bus_configure+0x16 configure(0,649c00,649000,0,c01378b5) at configure+0x22 mi_startup() at mi_startup+0x9a begin() at begin+0x2c db Disable acpi. acpi is broken. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic with today's CURRENT on sparc64 at boot
On Tue, 2003/01/21 at 17:33:42 +, [EMAIL PROTECTED] wrote: Hi cvsup'd to . today on an E220R, single CPU with two Symbios scsi cards. Box had been running fine with RC3, but would not boot with -CURRENT kernel: Current: hme4: Ethernet address: 08:00:20:b7:ef:44 miibus4: MII bus on hme4 ukphy3: Generic IEEE 802.3u media interface on miibus4 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sym0: 875 port 0x1000-0x10ff mem 0x1090a000-0x1090afff,0x10908000-0x109080ff i rq 32 at device 3.0 on pci0 panic: trap: fast data access mmu miss cpuid = 0; Debugger(panic) Stopped at Debugger+0x1c: ta %xcc, 1 Can you please cvsup again to pick up some changes that were made yesterday and try again? - Thomas -- Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/ [EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel panic with today's CURRENT on sparc64 at boot
Hi cvsup'd to . today on an E220R, single CPU with two Symbios scsi cards. Box had been running fine with RC3, but would not boot with -CURRENT kernel: Current: hme4: Ethernet address: 08:00:20:b7:ef:44 miibus4: MII bus on hme4 ukphy3: Generic IEEE 802.3u media interface on miibus4 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sym0: 875 port 0x1000-0x10ff mem 0x1090a000-0x1090afff,0x10908000-0x109080ff i rq 32 at device 3.0 on pci0 panic: trap: fast data access mmu miss cpuid = 0; Debugger(panic) Stopped at Debugger+0x1c: ta %xcc, 1 RC3: hme4: Ethernet address: 08:00:20:b7:ef:44 miibus4: MII bus on hme4 ukphy3: Generic IEEE 802.3u media interface on miibus4 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sym0: 875 port 0x1000-0x10ff mem 0x1090a000-0x1090afff,0x10908000-0x109080ff i rq 32 at device 3.0 on pci0 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: 875 port 0x1400-0x14ff mem 0x1090e000-0x1090efff,0x1090c000-0x1090c0ff i rq 38 at device 3.1 on pci0 sym1: No NVRAM, ID 7, Fast-20, SE, parity checking pcib2: PCI-PCI bridge at device 4.0 on pci0 pci2: PCI bus on pcib2 Help! :) Thanks Steven To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel panic in USB: don't do that
Hi, FreeBSD bree.elfwind.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Jan 18 09:05:06 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/RV i386 Just received a kernel panic (don't do that) whilst attemping to upload the firmware for an Alcatel USB ADSL modem. #10 0xc024fa3b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:517 #11 0xc022bd52 in destroy_dev (dev=0xc43b7600) at /usr/src/sys/kern/kern_conf.c:377 #12 0xc01e1edf in ugen_destroy_devnodes (sc=0xc4057000) at /usr/src/sys/dev/usb/ugen.c:293 #13 0xc01e1f07 in ugen_set_config (sc=0xc4057000, configno=1) at /usr/src/sys/dev/usb/ugen.c:315 #14 0xc01e34b4 in ugen_do_ioctl (sc=0xc4057000, endpt=0, cmd=0, addr=0xd7ae9c48 \001, flag=0, p=0xc3fe39a0) at /usr/src/sys/dev/usb/ugen.c:1149 Full kernel config and gdb backtrace attached. If you need any more info, please let me know. -Russell # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.372 2003/01/16 00:21:52 sam Exp $ machine i386 cpu I686_CPU ident RV maxusers0 #To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints #Default places to look for devices. makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options NFS_ROOT#NFS usable as root device, requires NFSCLIENT options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. # Debugging for use in -current options DDB #Enable the kernel debugger #optionsINVARIANTS #Enable calls of extra sanity checking #optionsINVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS #optionsWITNESS #Enable checks to detect deadlocks and cycles #optionsWITNESS_SKIPSPIN#Don't run witness on spinlocks for speed # To make an SMP kernel, the next two are needed #optionsSMP # Symmetric MultiProcessor Kernel #optionsAPIC_IO # Symmetric (APIC) I/O device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering
ACPI causes kernel panic on compaq evo n1020v
hi I'm getting kernel panic on Compaq evo n1020v notebook when trying to boot with ACPI enabled. Last message from kernel is psm0: unable to allocate IRQ without acpi it gets assigned IRQ without problems. Panic is however probably unrelated to psm problem - it paniced the same way when I disabled psm0 device. kernel is current from 05 jan. sources with acpica-20021118-20021122-test20021128 patch, however I got same panics from DP1 DP2 without any additional patches so the bug is not new here is all the debugging information I could think of: dmesg panic with acpi boot -v: http://bsd.ee/~hadara/evo_acpi_debug/dmesg.boot.acpi ( transcribed by hand, because this machine doesn't have any serial ports.. so it probably contains some typos ) dmesg (boot -v) without acpi: http://bsd.ee/~hadara/evo_acpi_debug/dmesg.boot kernel configuration file: http://bsd.ee/~hadara/evo_acpi_debug/IKALDUS only difference between acpi and non acpi kernels were device acpi options ACPI_DEBUG output of acpidump: http://bsd.ee/~hadara/evo_acpi_debug/acpi_dump.txt hints file: http://bsd.ee/~hadara/evo_acpi_debug/device.hints To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel panic on 4.7-STABLE to 5.0 RC2 upgrade.
Hello, I recently attempted to upgrade on of my servers from 4.7 STABLE to 5.0 RC2 using the Upgrade facility of sysinstall. After choosing all the options I needed, the upgrade proceeded through its fsck and started unpacking off the CD. This is where things go sour. About 20% of the way through the first round of Extracting into /, I got a page fault/kernel panic and a reboot. Unfortunately, no other useful information was presented. This problem is limited to 5.0 as I am able to recover a usable machine by installing 4.7 Release using the same method. Has anyone else expperienced anything similar? If you can tell me how to get more information about this crash, I would be happy to try. For now it is just frustrating. Hardware config FYI: Asus CUV4x-D 2X PIII-600 coppermine. 1 ata-100 drive. There is also a windows partition on this disk. LSIlogic MegaRAID 428 ( currently unused ). Should you require further info, please do not hesitate to contact me. -Wade Klaver To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel Panic on -CURRENT w/ SMP
I recently rebuilt my kernel to HEAD and configured my kernel to support the Dual 200Mhz PPro's. upon restart, I recieved the kernel panic below. panic: CPU APIC ID out of range (0..15) cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x55;xchgl%ebx,in_Debugger.0 db trace Debugger(c03ca5f6,0,c03e2f29,c0537d04,1) at Debugger+0x55 panic(c03e2f29,f,0,c0537d3c,c038990e) at panic+0x11f processor_entry(f1440,1,0,0,1) at processor_entry+0x30 mptable_pass2(c0537d68,c020c301,c04430a0,34,c0420550) at mptable_pass2+0x2ce mp_enable(9f000,c0537d80,c0236131,c04430a0,c03ccfd2) at mp_enable+0x37 cpu_mp_start(c04430a0,c03ccfd2,0,1,c0537d98) at cpu_mp_start+0x3d mp_start(0,534000,534c00,534000,0) at mp_start+0x41 mi_startup() at mi_startup+0xb5 begin() at begin+0x2c Like I said, this is a Dual 200Mhz Pentium Pro machine. Any ideas? Thanks -Frank Laszlo -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/IT/MU d s: a-- C++ BU P+ L- E--- W+++ N+ o- K- w-- O M+ V-- PS PE- Y+ PGP++ t+ 5- X R tv+ b DI+ D++ G e h-- r++ y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel Panic on -CURRENT w/ SMP
I believe this panic was cause by the BIOS not recognizing the second CPU.. i rebooted a couple times and did a couple BIOS config settings. now it will load the kernel, but right before fsck (and right after SMP: AP CPU #1 Launched!) I get this: lock order reveral 1st 0xc165x950 process lock (process lock) @ /usr/src/sys/kern/jern_descrip.c:2100 2nd 0xc1659434 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:2107 Any ideas? -Frank Laszlo On Tuesday 07 January 2003 02:39 am, Frank Laszlo wrote: I recently rebuilt my kernel to HEAD and configured my kernel to support the Dual 200Mhz PPro's. upon restart, I recieved the kernel panic below. panic: CPU APIC ID out of range (0..15) cpuid = 0; lapic.id = Debugger(panic) Stopped atDebugger+0x55;xchgl%ebx,in_Debugger.0 db trace Debugger(c03ca5f6,0,c03e2f29,c0537d04,1) at Debugger+0x55 panic(c03e2f29,f,0,c0537d3c,c038990e) at panic+0x11f processor_entry(f1440,1,0,0,1) at processor_entry+0x30 mptable_pass2(c0537d68,c020c301,c04430a0,34,c0420550) at mptable_pass2+0x2ce mp_enable(9f000,c0537d80,c0236131,c04430a0,c03ccfd2) at mp_enable+0x37 cpu_mp_start(c04430a0,c03ccfd2,0,1,c0537d98) at cpu_mp_start+0x3d mp_start(0,534000,534c00,534000,0) at mp_start+0x41 mi_startup() at mi_startup+0xb5 begin() at begin+0x2c Like I said, this is a Dual 200Mhz Pentium Pro machine. Any ideas? Thanks -Frank Laszlo -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/IT/MU d s: a-- C++ BU P+ L- E--- W+++ N+ o- K- w-- O M+ V-- PS PE- Y+ PGP++ t+ 5- X R tv+ b DI+ D++ G e h-- r++ y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel panic
I get this when I try to enable bridging:
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc01f5f8e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc01f61d3 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc0239317 in bremfree (bp=0xcae72988) at
/usr/src/sys/kern/vfs_bio.c:634
#4 0xc023bd20 in getblk (vp=0xc33e5000, blkno=8652544, size=16384,
slpflag=0,
slptimeo=0) at /usr/src/sys/kern/vfs_bio.c:2364
#5 0xc023944a in breadn (vp=0xc33e5000, blkno=0, size=0, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at
/usr/src/sys/kern/vfs_bio.c:692
#6 0xc02393fc in bread (vp=0x0, blkno=0, size=0, cred=0x0, bpp=0x0)
at /usr/src/sys/kern/vfs_bio.c:674
#7 0xc02a7d03 in ffs_update (vp=0xc33e4000, waitfor=0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:102
#8 0xc02bbf1f in ffs_fsync (ap=0xd2c09278)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:315
#9 0xc02bb0ee in ffs_sync (mp=0xc33ce600, waitfor=2, cred=0xc11dfe80,
td=0xc037a700) at vnode_if.h:612
#10 0xc024d36b in sync (td=0xc037a700, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#11 0xc01f5b9c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:273
#12 0xc01f61d3 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#13 0xc0218424 in witness_lock (lock=0xc03873a0, flags=8,
file=0xc0357d23 /usr/src/sys/net/if.c, line=890)
at /usr/src/sys/kern/subr_witness.c:614
#14 0xc01ec5c1 in _mtx_lock_flags (m=0xc037ed40, opts=0,
file=0xc03873a0 @í7À\035}5À\035}5À, line=-1069726564)
at /usr/src/sys/kern/kern_mutex.c:328
#15 0xc025b270 in ifa_ifwithdstaddr (addr=0xc03873a0)
at /usr/src/sys/net/if.c:890
#16 0xc0262680 in ifa_ifwithroute (flags=0, dst=0xc33ce0c0,
gateway=0xc33ce0c0)
at /usr/src/sys/net/route.c:423
#17 0xc0262847 in rt_getifa (info=0xc33ce0c0) at
/usr/src/sys/net/route.c:520
#18 0xc0262ad1 in rtrequest1 (req=1, info=0xd2c09460, ret_nrt=0xd2c094b4)
at /usr/src/sys/net/route.c:632
#19 0xc026276b in rtrequest (req=0, dst=0x0, gateway=0x0, netmask=0x0,
flags=0, ret_nrt=0x0) at /usr/src/sys/net/route.c:479
#20 0xc0282dd7 in in6_ifloop_request (cmd=1, ifa=0xc33ce000)
at /usr/src/sys/netinet6/in6.c:167
#21 0xc0282fce in in6_ifaddloop (ifa=0xc33ce000)
at /usr/src/sys/netinet6/in6.c:224
#22 0xc0285327 in in6_ifinit (ifp=0xc32f4800, ia=0x0, sin6=0x0, newhost=1)
at /usr/src/sys/netinet6/in6.c:1634
#23 0xc028422d in in6_update_ifa (ifp=0xc32f4800, ifra=0xd2c09668,
ia=0xc33ce000) at /usr/src/sys/netinet6/in6.c:978
#24 0xc0287514 in in6_ifattach_linklocal (ifp=0xd2c09668, altifp=0x0)
at /usr/src/sys/netinet6/in6_ifattach.c:497
#25 0xc0287e18 in in6_ifattach (ifp=0xc33ce000, altifp=0x0)
#26 0xc0285e2b in in6_if_up (ifp=0xc32f4800)
at /usr/src/sys/netinet6/in6.c:2326
#27 0xc025b827 in if_route (ifp=0xc32f4800, flag=1, fam=0)
at /usr/src/sys/net/if.c:1120
#28 0xc025b881 in if_up (ifp=0x0) at /usr/src/sys/net/if.c:1147
#29 0xc04a0a74 in ?? ()
#30 0xc04a0b20 in ?? ()
#31 0xc04a0e51 in ?? ()
#32 0xc01fe92b in sysctl_root (oidp=0x0, arg1=0xd2c09ca8, arg2=-1020035060,
req=0xc32f4800) at /usr/src/sys/kern/kern_sysctl.c:1150
#33 0xc01febad in userland_sysctl (td=0x0, name=0xd2c09ca8, namelen=4,
old=0xc333800c, oldlenp=0xc32f4800, inkernel=0, new=0xd2c09ca8,
newlen=0,
retval=0xd2c09ca4) at /usr/src/sys/kern/kern_sysctl.c:1254
#34 0xc01fe9f0 in __sysctl (td=0x0, uap=0xd2c09d10)
at /usr/src/sys/kern/kern_sysctl.c:1184
#35 0xc03148ce in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 4, tf_esi = 0,
tf_ebp = -1077939032, tf_isp = -759128716, tf_ebx = 0, tf_edx =
-1077936551, tf_ecx = -1077936880, tf_eax = 202, tf_trapno = 12, tf_err
= 2, tf_eip = 134587879, tf_cs = 31, tf_eflags = 663, tf_esp =
-1077939076, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#36 0xc0304a1d in Xint0x80_syscall () at {standard input}:140
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kernel panic
On Thu, 26 Dec 2002, Peter Schultz wrote:
Are you actually using IPV6 or do you have IPV6 on your network segment?
It'd be nice to know wheich modules are loaded at 0xc04a0a74, 0xc04a0b20
and 0xc04a0e51. There is some way to make gdb know abouth the modules
too but I haven't kept up with it.
I get this when I try to enable bridging:
#20 0xc0282dd7 in in6_ifloop_request (cmd=1, ifa=0xc33ce000)
at /usr/src/sys/netinet6/in6.c:167
#21 0xc0282fce in in6_ifaddloop (ifa=0xc33ce000)
at /usr/src/sys/netinet6/in6.c:224
#22 0xc0285327 in in6_ifinit (ifp=0xc32f4800, ia=0x0, sin6=0x0, newhost=1)
at /usr/src/sys/netinet6/in6.c:1634
#23 0xc028422d in in6_update_ifa (ifp=0xc32f4800, ifra=0xd2c09668,
ia=0xc33ce000) at /usr/src/sys/netinet6/in6.c:978
#24 0xc0287514 in in6_ifattach_linklocal (ifp=0xd2c09668, altifp=0x0)
at /usr/src/sys/netinet6/in6_ifattach.c:497
#25 0xc0287e18 in in6_ifattach (ifp=0xc33ce000, altifp=0x0)
#26 0xc0285e2b in in6_if_up (ifp=0xc32f4800)
at /usr/src/sys/netinet6/in6.c:2326
#27 0xc025b827 in if_route (ifp=0xc32f4800, flag=1, fam=0)
at /usr/src/sys/net/if.c:1120
#28 0xc025b881 in if_up (ifp=0x0) at /usr/src/sys/net/if.c:1147
#29 0xc04a0a74 in ?? ()
#30 0xc04a0b20 in ?? ()
#31 0xc04a0e51 in ?? ()
#32 0xc01fe92b in sysctl_root (oidp=0x0, arg1=0xd2c09ca8, arg2=-1020035060,
req=0xc32f4800) at /usr/src/sys/kern/kern_sysctl.c:1150
#33 0xc01febad in userland_sysctl (td=0x0, name=0xd2c09ca8, namelen=4,
old=0xc333800c, oldlenp=0xc32f4800, inkernel=0, new=0xd2c09ca8,
newlen=0,
retval=0xd2c09ca4) at /usr/src/sys/kern/kern_sysctl.c:1254
#34 0xc01fe9f0 in __sysctl (td=0x0, uap=0xd2c09d10)
at /usr/src/sys/kern/kern_sysctl.c:1184
#35 0xc03148ce in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 4, tf_esi = 0,
tf_ebp = -1077939032, tf_isp = -759128716, tf_ebx = 0, tf_edx =
-1077936551, tf_ecx = -1077936880, tf_eax = 202, tf_trapno = 12, tf_err
= 2, tf_eip = 134587879, tf_cs = 31, tf_eflags = 663, tf_esp =
-1077939076, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#36 0xc0304a1d in Xint0x80_syscall () at {standard input}:140
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
kernel panic on install with vaio srx51p
hiya folks I've just tried booting the freebsd 5-rc2 ISO on my sony vaio srx51p from the firewire cdrw/dvd. I wasn't really expecting to be able to install from the firewire drive but I thought it might get far enough to net install, however the rc2 iso has done the same on boot as the other 5 releases so far. I thought perhaps I ought to point it out :) this will by typed in by hand as the laptop has no serial ports :) I'm prepared to type in the relevant bits of the crash but I'm not typing the whole thing in :) when the machine is booted, the bios boots off the firewire drive which boots the kernel. this gets quite a way but crashes completely at the cbb0 device. here's what shows up from a standard boot, no variables set or anything: -- cbb0: Unsupported card type detected Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x8:0xc02481f2 stack pointer = 0x10:0xcd28bcc0 frame pointer = 0x10:0xcd28bcc0 code segment = base 0x0, limit oxf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled. IOPL = 0 current process = 21 (irq9: cbb0 cbb1) trap number = 18 panic: integer divide fault --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
I fixed a serious DMA physical address translation bug in OHCI today.
Look on the lists today for this message. Message and patch enclosed.
Note that this fixes one bug in FreeBSD's implementation and a second
bug that is NetBSD/OpenBSD specific. I would appreciate it if someone
would forward this information to the NetBSD/OpenBSD folks.
These were very serious bugs.
-Matt
:Date: Thu, 19 Dec 2002 17:11:32 -0800 (PST)
:From: Matthew Dillon [EMAIL PROTECTED]
:Message-Id: [EMAIL PROTECTED]
:To: Nate Lawson [EMAIL PROTECTED]
:Cc: [EMAIL PROTECTED]
:Subject: Re: UMASS USB bug? (getting the Sony disk-on-key device working)
:References: [EMAIL PROTECTED]
:Sender: [EMAIL PROTECTED]
:List-ID: freebsd-current.FreeBSD.ORG
:List-Archive: http://docs.freebsd.org/mail/ (Web Archive)
:List-Help: mailto:[EMAIL PROTECTED]?subject=help (List Instructions)
:List-Subscribe: mailto:[EMAIL PROTECTED]?subject=subscribe%20freebsd-current
:List-Unsubscribe: mailto:[EMAIL PROTECTED]?subject=unsubscribe%20freebsd-current
:X-Loop: FreeBSD.ORG
:Precedence: bulk
:...
:
Index: ohci.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ohci.c,v
retrieving revision 1.116
diff -u -r1.116 ohci.c
--- ohci.c 9 Dec 2002 01:41:24 - 1.116
+++ ohci.c 20 Dec 2002 01:02:11 -
@@ -493,17 +493,17 @@
u_int32_t intr, tdflags;
int offset = 0;
int len, curlen;
+ int orig_len;
usb_dma_t *dma = xfer-dmabuf;
u_int16_t flags = xfer-flags;
DPRINTFN(alen 4096,(ohci_alloc_std_chain: start len=%d\n, alen));
- len = alen;
+ orig_len = len = alen;
cur = sp;
-
dataphys = DMAADDR(dma, 0);
- dataphysend = OHCI_PAGE(dataphys + len - 1);
+ dataphysend = OHCI_PAGE(DMAADDR(dma, len - 1));
tdflags = htole32(
(rd ? OHCI_TD_IN : OHCI_TD_OUT) |
(flags USBD_SHORT_XFER_OK ? OHCI_TD_R : 0) |
@@ -518,8 +518,8 @@
/* The OHCI hardware can handle at most one page crossing. */
#if defined(__NetBSD__) || defined(__OpenBSD__)
- if (OHCI_PAGE(dataphys) == OHCI_PAGE(dataphysend) ||
- OHCI_PAGE(dataphys) + OHCI_PAGE_SIZE == OHCI_PAGE(dataphysend))
+ if (OHCI_PAGE(dataphys) == dataphysend ||
+ OHCI_PAGE(dataphys) + OHCI_PAGE_SIZE == dataphysend)
#elif defined(__FreeBSD__)
/* XXX This is pretty broken: Because we do not allocate
* a contiguous buffer (contiguous in physical pages) we
@@ -527,7 +527,7 @@
* So check whether the start and end of the buffer are on
* the same page.
*/
- if (OHCI_PAGE(dataphys) == OHCI_PAGE(dataphysend))
+ if (OHCI_PAGE(dataphys) == dataphysend)
#endif
{
/* we can handle it in this TD */
@@ -544,6 +544,8 @@
/* must use multiple TDs, fill as much as possible. */
curlen = 2 * OHCI_PAGE_SIZE -
OHCI_PAGE_MASK(dataphys);
+ if (curlen len) /* may have fit in one page */
+ curlen = len;
#elif defined(__FreeBSD__)
/* See comment above (XXX) */
curlen = OHCI_PAGE_SIZE -
@@ -568,6 +570,9 @@
dataphys, dataphys + curlen - 1));
if (len == 0)
break;
+ if (len 0)
+ panic(Length went negative: %d curlen %d (dma %p offset %08x
+dataphysend %p currentdataphysend %p, len, curlen, *dma, (int)offset, (void
+*)dataphysend, (void *)OHCI_PAGE(DMAADDR(dma,0) + orig_len - 1));
+
DPRINTFN(10,(ohci_alloc_std_chain: extend chain\n));
offset += curlen;
cur = next;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Kernel Panic in runq_check
I have a CURRENT system that is panicing on me every couple of days. I have enabled crash dumps in the rc.conf file, but when the system is rebooted, savecore doesn't find any core files on the swap partition. The system has 128M RAM installed, and the swap partion is ~512M. I am using a GENERIC kernel with SMP options enabled (see diff at bottom of message). Is there anything I need to add to the kernel config file to enable dumping of core files? Can I force a core dump when it panics? How? Current# ls /usr/obj/usr/src/srcC/sys/GENERIC-SMP/kernel* /usr/obj/usr/src/srcC/sys/GENERIC-SMP/kernel /usr/obj/usr/src/srcC/sys/GENERIC-SMP/kernel.debug The system was built from sources cvsuped on Dec 4th. I was trying to compile soureces cvsuped from yesterday when the panic occured. FreeBSD Current.westbend.net 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Thu Dec 5 19:11:47 CST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/srcC/sys/GENERIC-SMP i386 cpuid=0; lapic.id= instruction pointer = 0x8:0xc02f3d21 stack pointer = 0x10:0xc8678cdc frame pointer = 0x10:0xc8678cdc code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, Pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 12 (idle: cpu 0) kernel: type 30 trap, code = 0 stopped at runq_check+0x21: cmpl $0x1, %eax nm -n /boot/kernel_smp/kernel | grep c02f3d c02f3d00 T runq_check c02f3d30 T runq_choose c02f3dc0 T runq_remove Current# grep dump /etc/rc.conf dumpdev=/dev/da0s1b # Device name to crashdump to (or NO). dumpdir=/var/crash# Directory where crash dumps are to be stored savecore_flags= # Used if dumpdev is enabled above, and present. Current# df Filesystem1K-blocksUsed Avail Capacity Mounted on /dev/da0s1a 516062 121330 35344826% / devfs 1 1 0 100% /dev /dev/da0s1f 5160623232 471546 1% /tmp /dev/da0s1g 2310684 576178 154965227% /usr /dev/da0s1e 516062 123158 35162026% /var Current# disklabel -r /dev/da0s1 # /dev/da0s1: type: SCSI disk: da0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 553 sectors/unit: 924 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: 104857604.2BSD 2048 1638489 # (Cyl.0 - 65*) b: 1048576 1048576 swap# (Cyl. 65*- 130*) c: 9240unused0 0 # (Cyl.0 - 553*) e: 1048576 20971524.2BSD 2048 1638489 # (Cyl. 130*- 195*) f: 1048576 31457284.2BSD 2048 1638489 # (Cyl. 195*- 261*) g: 4694620 41943044.2BSD 2048 1638489 # (Cyl. 261*- 553*) Current# dmesg Copyright (c) 1992-2002 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 #1: Thu Dec 5 19:11:47 CST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/srcC/sys/GENERIC-SMP Preloaded elf kernel /boot/kernel_smp/kernel at 0xc067d000. Timecounter i8254 frequency 1193182 Hz CPU: Pentium/P54C (200.46-MHz 586-class CPU) Origin = GenuineIntel Id = 0x52c Stepping = 12 Features=0x3bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC real memory = 134217728 (128 MB) avail memory = 123412480 (117 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 IOAPIC #0 intpin 17 - irq 10 IOAPIC #0 intpin 18 - irq 12 IOAPIC #0 intpin 19 - irq 11 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Intel Pentium detected, installing workaround for F00F bug Initializing GEOMetry subsystem npx0: math processor on motherboard npx0: INT 16 interface Using $PIR table, 6 entries at 0xc00fcdd0 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX3 ATA controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: display, VGA at device 9.0 (no driver attached) fxp0: Intel Pro 10/100B/100+ Ethernet port 0xe400-0xe41f mem 0xd400-0xd40f,0xd410-0xd4100fff irq 12 at device 10.0 on pci0 fxp0: Ethernet address 00:a0:c9:85:b5:ed inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: Adaptec aic7880 Ultra SCSI adapter port 0xe800-0xe8ff mem
Re: ACPI kernel panic with 5.0-RC1
On Tue, 2002-12-10 at 18:43, Paul A. Mayer wrote: Greetings, Congratulations on RC1! I've found an issue! :-) I just upgraded my ASUS LC3800 portable to 5.0-RC1 from 5.0-DP2. The new kernel panics shortly after booting up and drops into the debugger. The messages look something like this: Fatal trap 12 Page fault in kernel mode fault virtual address 0x42 page not present process acpi_thermal Stopped at: vm_object_pip_add+0x37: movzwl 0x42(%esi),%eax This happens after the kernel is loaded and within approximately 15-30 seconds after the login prompt is shown. The machine is based on the i845MP chipset and is running a 2Ghz mobile P4. I'd be happy to provide more debugging info and work on patch testing, just tell me what needs to be known or done. Please mail my personal address as well as the list, as I've not been accepted for the list. Best regards, Paul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Got the same laptop here, with the same problem. Dmesg and some debug info attached. For more debugging info or patch testing just ask. Paul: I found a little work around for this problem. Just boot de laptop without de AC connector. After this msg scrolls past acpi_acad0: acline initialization done, tried 7 times I can plug in de AC connector without the machine panic. But I have seen that if you unplug and then replug the AC connector, the machine panics anyway. -Koop Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0de fault code = supervisor read, page not present instruction pointer = 0x8:0xc057f6d0 stack pointer = 0x10:0xcd232c00 frame pointer = 0x10:0xcd232c00 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 = 7 (acpi_task2) kernel: type 12 trap, code=0 Stopped at AcpiNsMapHandleToNode+0x20: cmpb$0xaa,0(%edx) db Context switches not allowed in the debugger. db trace AcpiNsMapHandleToNode(deadc0de,deadc0de,cd232c28,c05927bb,0) at AcpiNsMapHandleToNode+0x20 AcpiGetHandle(deadc0de,c059cabb,cd232c4c,cd232c50,0) at AcpiGetHandle+0x4d acpi_pwr_switch_consumer(deadc0de,3,cd232cbc,c025a91a,cd232c98) at acpi_pwr_switch_consumer+0xe3 acpi_tz_switch_cooler_off(c29b9090,c24e9300,0,c24e9300,c24e9300) at acpi_tz_switch_cooler_off+0x58 acpi_ForeachPackageObject(c29b6540,c05940c0,c24e9300,c24e9300,c0593a00) at acpi_ForeachPackageObject+0x3d acpi_tz_all_off(c24e9300,c022ede1,c03f7220,8,c059d373) at acpi_tz_all_off+0x2f acpi_tz_establish(c24e9300,0,c059d373,7b,0) at acpi_tz_establish+0x14 acpi_task_thread(0,cd232d48,c03a9c7a,360,0) at acpi_task_thread+0x100 fork_exit(c0596700,0,cd232d48) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xcd232d7c, ebp = 0 --- db panic panic: from debugger Debugger(panic) Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc0355674 stack pointer = 0x10:0xcd232980 frame pointer = 0x10:0xcd23298c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= IOPL = 0 current process = 7 (acpi_task2) Stopped at AcpiNsMapHandleToNode+0x20: cmpb$0xaa,0(%edx) db panic panic: from debugger Uptime: 4m9s pfs_vncache_unload(): 1 entries remaining Dumping 255 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 Dump complete Terminate ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Copyright (c) 1992-2002 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-RC #0: Tue Dec 10 23:27:49 CET 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/babylon Preloaded elf kernel /boot/kernel/kernel at 0xc05af000. Preloaded elf module /boot/kernel/firewire.ko at 0xc05af0a8. Preloaded elf module /boot/kernel/radeon.ko at 0xc05af158. Preloaded elf module /boot/kernel/smbfs.ko at 0xc05af204. Preloaded elf module /boot/kernel/libmchain.ko at 0xc05af2b0. Preloaded elf module /boot/kernel/libiconv.ko at 0xc05af360. Preloaded elf module /boot/kernel/acpi.ko at 0xc05af410. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 281384 Hz CPU: Pentium 4 (2000.08-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf24 Stepping = 4 Features=0x3febf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 268406784 (255 MB) avail memory = 254701568 (242 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled VESA: v2.0, 32768k memory, flags:0x1, mode
Re: ACPI kernel panic with 5.0-RC1
On Wed, 2002-12-11 at 13:07, Koop Mast wrote: Got the same laptop here, with the same problem. Dmesg and some debug info attached. For more debugging info or patch testing just ask. Paul: I found a little work around for this problem. Just boot de laptop without de AC connector. After this msg scrolls past acpi_acad0: acline initialization done, tried 7 times I can plug in de AC connector without the machine panic. But I have seen that if you unplug and then replug the AC connector, the machine panics anyway. -Koop Woeps, forgot to say that I running: FreeBSD lapbeest.bogus 5.0-RC FreeBSD 5.0-RC #0: Tue Dec 10 23:27:49 CET 2002[EMAIL PROTECTED]:/usr/obj/usr/src/sys/babylon i386 with acpi patch acpica-20021118-20021122-test20021128.diff -Koop To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI kernel panic with 5.0-RC1
Greetings, Congratulations on RC1! I've found an issue! :-) I just upgraded my ASUS LC3800 portable to 5.0-RC1 from 5.0-DP2. The new kernel panics shortly after booting up and drops into the debugger. The messages look something like this: Fatal trap 12 Page fault in kernel mode fault virtual address 0x42 page not present process acpi_thermal Stopped at: vm_object_pip_add+0x37: movzwl 0x42(%esi),%eax This happens after the kernel is loaded and within approximately 15-30 seconds after the login prompt is shown. The machine is based on the i845MP chipset and is running a 2Ghz mobile P4. I'd be happy to provide more debugging info and work on patch testing, just tell me what needs to be known or done. Please mail my personal address as well as the list, as I've not been accepted for the list. Best regards, Paul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI kernel panic with 5.0-RC1
Hello, You need to prepare a kernel dump. Pardon the self-promotion: http://www.onlamp.com/pub/a/bsd/2002/03/21/Big_Scary_Daemons.html http://www.onlamp.com/pub/a/bsd/2002/04/04/Big_Scary_Daemons.html With a full bug report, we can address this. Thanks! On Tue, Dec 10, 2002 at 06:43:55PM +0100, Paul A. Mayer wrote: Greetings, Congratulations on RC1! I've found an issue! :-) I just upgraded my ASUS LC3800 portable to 5.0-RC1 from 5.0-DP2. The new kernel panics shortly after booting up and drops into the debugger. The messages look something like this: Fatal trap 12 Page fault in kernel mode fault virtual address 0x42 page not present process acpi_thermal Stopped at: vm_object_pip_add+0x37: movzwl 0x42(%esi),%eax This happens after the kernel is loaded and within approximately 15-30 seconds after the login prompt is shown. The machine is based on the i845MP chipset and is running a 2Ghz mobile P4. I'd be happy to provide more debugging info and work on patch testing, just tell me what needs to be known or done. Please mail my personal address as well as the list, as I've not been accepted for the list. Best regards, Paul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.oreillynet.com/pub/q/Big_Scary_Daemons Absolute BSD: http://www.AbsoluteBSD.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel panic: vfs_alloc()
Hi,
One of my FreeBSD-current test machines panicked upon
bootup. The message which appeared before the panic was:
imode = 041777, inum = 61, fs = /var
panic: ffs_valloc: dup alloc
I am attaching the ddb trace, the gdb trace,
and some Fault trap 12 messages that appeared in the console.
Any ideas?
Thanks.
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
imode = 041777, inum = 61, fs = /var
panic: ffs_valloc: dup alloc
panic()
ffs_valloc()
ufs_makeinode()
ufs_create()
ufs_vnoperate()
vn_open_cred()
vn_open()
kern_open()
open()
syscall()
Xint0x80_syscall()
#0 Debugger (msg=0x12 Address 0x12 out of bounds)
at /usr/src/sys/i386/i386/db_interface.c:323
#1 0xc0318afb in panic (fmt=0x1 Address 0x1 out of bounds)
at /usr/src/sys/kern/kern_shutdown.c:503
#2 0xc0434225 in ffs_valloc (pvp=0xc13b9378, mode=33188, cred=0xc0a09180,
vpp=0xc6028894) at /usr/src/sys/ufs/ffs/ffs_alloc.c:871
#3 0xc045a789 in ufs_makeinode (mode=33188, dvp=0xc13b9378, vpp=0xc6028bec,
cnp=0xc6028c00) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2356
#4 0xc0457489 in ufs_create (ap=0xc6028a2c)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:197
#5 0xc045ac88 in ufs_vnoperate (ap=0x0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2796
#6 0xc037691f in vn_open_cred (ndp=0xc6028bd8, flagp=0xc6028cd8, cmode=420,
cred=0xc0a09180) at vnode_if.h:114
#7 0xc0376779 in vn_open (ndp=0x12, flagp=0x12, cmode=18)
at /usr/src/sys/kern/vfs_vnops.c:91
#8 0xc0370223 in kern_open (td=0xc1201ee0,
path=0x12 Address 0x12 out of bounds, pathseg=18, flags=1538, mode=438)
at /usr/src/sys/kern/vfs_sscalls.c:664
#9 0xc0370090 in open (td=0x12, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:627
#10 0xc04a786e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135291256, tf_esi = 1, tf_eb
p = -1077938600, tf_isp = -972911244, tf_ebx = 135291160, tf_edx = -1077938560,
#11 0xc049727d in Xint0x80_syscall () at {standard input}:140
#12 0x080582af in ?? ()
#13 0x0804c08d in ?? ()
#14 0x0804af71 in ?? ()
#15 0x0804aed7 in ?? ()
#16 0x0804aed7 in ?? ()
#17 0x08053767 in ?? ()
#18 0x080539e9 in ?? ()
#19 0x0804c12b in ?? ()
#20 0x0804af71 in ?? ()
#21 0x0804aed7 in ?? ()
#22 0x0804b358 in ?? ()
#23 0x0804ae8f in ?? ()
#24 0x0804aed7 in ?? ()
#25 0x0804aed7 in ?? ()
#26 0x0804b2a1 in ?? ()
#27 0x0804aeff in ?? ()
#28 0x0804aed7 in ?? ()
#29 0x0804bf6e in ?? ()
#30 0x0804af71 in ?? ()
#31 0x0804add9 in ?? ()
#32 0x0804b18d in ?? ()
#33 0x0804aef1 in ?? ()
#34 0x0804aed7 in ?? ()
#35 0x0804add9 in ?? ()
#36 0x0804add9 in ?? ()
#37 0x0804add9 in ?? ()
#38 0x0804b2a1 in ?? ()
#39 0x0804aeff in ?? ()
#40 0x08053767 in ?? ()
#41 0x0805364b in ?? ()
#42 0x0804814c in ?? ()
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x12
fault code= supervisor read, page not present
instruction pointer = 0x8:0xc0495b50
stack pointer = 0x10:0xc6028698
frame pointer = 0x10:0xc602869c
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = resume, IOPL = 0
current process = 142 (sh)
Debugging kernel panic, routetbl
Hi,
Can someone give me some ideas for how to debug a kernel
panic and isolate where the problem could be?
I've been trying out the Netgraph ATM stuff for a while,
and things have been working fine for a number of weeks.
However, when I cvsup'd -CURRENT from a few days ago,
I have one of my machines crashing after
route add is called on my ATM card.
The crash I am getting is soon after the ATM card is initialized
with ifconfig, and route add is called. This did not happen before,
and the ATM driver source that I am using has worked fine for weeks.
ddb gives me this message:
Memory modified after free 0x1383600(252)
panic: Most recently used by routetbl
And gdb over a serial port gives me this:
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 ar=
e
welcome to change it and/or distribute copies of it under certain condition=
s.
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...
(kgdb) target /dev remote /dev/cuaa0
Remote debugging using /dev/cuaa0
Debugger (msg0x12 Address 0x12 out of bounds)
at /usr/src/sys/i386/i386/db_interface.c:323
323 }
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
warning: shared library handler failed to enable breakpoint
(kgdb) where
#0 Debugger (msg0x12 Address 0x12 out of bounds)
at /usr/src/sys/i386/i386/db_interface.c:323
#1 0xc031892b in panic (fmt0x1 Address 0x1 out of bounds)
at /usr/src/sys/kern/kern_shutdown.c:503
#2 0xc035b4b7 in bremfree (bp0xc2426868) at /usr/src/sys/kern/vfs_bio.c=
:632
#3 0xc035deb0 in getblk (vp0xc1368000, blkno196864, size16384, sl=
pflag0,
slptimeo0) at /usr/src/sys/kern/vfs_bio.c:2344
#4 0xc035b5ea in breadn (vp0xc1368000, blkno137438953490, size18,=
rablkno0x0, rabsize0x0, cnt0, cred0x0, bpp0x12)
at /usr/src/sys/kern/vfs_bio.c:690
#5 0xc035b59c in bread (vp0x12, blkno137438953490, size18, cred=
0x12,
bpp0x12) at /usr/src/sys/kern/vfs_bio.c:672
#6 0xc043a256 in ffs_update (vp0xc1367000, waitfor0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:102
#7 0xc044dc5f in ffs_fsync (ap0xc5bbdb10)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:315
#8 0xc044cece in ffs_sync (mp0xc135e000, waitfor2, cred0xc09f6e00=
,
td0xc0577100) at vnode_if.h:612
#9 0xc036f308 in sync (td0xc0577100, uap0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#10 0xc031830c in boot (howto256) at /usr/src/sys/kern/kern_shutdown.c:2=
73
#11 0xc0318943 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#12 0xc04738bd in mtrash_ctor (mem0xc13e2d00, size32, arg0x0)
at /usr/src/sys/vm/uma_dbg.c:138
#13 0xc04722d7 in uma_zalloc_arg (zone0xc09d0140, udata0x0, flags0=
)
at /usr/src/sys/vm/uma_core.c:1358
#14 0xc030d0c6 in malloc (size4, type0xc05783e0, flags0)
at /usr/src/sys/kern/kern_malloc.c:182
#15 0xc02fbd35 in fdcopy (td0x12) at /usr/src/sys/kern/kern_descrip.c:12=
65
#16 0xc0304140 in fork1 (td0xc0a0c540, flags20, pages0, procp0x=
c5bbdcd4)
at /usr/src/sys/kern/kern_fork.c:446
#17 0xc0303872 in fork (td0xc0a0c540, uap0xc5bbdd10)
at /usr/src/sys/kern/kern_fork.c:122
#18 0xc04a763e in syscall (frame
{tf_fs 47, tf_es 47, tf_ds 47, tf_edi 0, tf_esi 1=
35254016, tf_ebp -1077937816, tf_isp -977543820, tf_ebx 0, tf_e=
dx 672047128, tf_ecx 3, tf_eax 2, tf_trapno 12, tf_err =
2, tf_eip 134723747, tf_cs 31, tf_eflags 514, tf_esp -10779=
37860, tf_ss 47})
at /usr/src/sys/i386/i386/trap.c:1033
#19 0xc049704d in Xint0x80_syscall () at {standard input}:140
#20 0x0804b326 in ?? ()
#21 0x0804ae8f in ?? ()
#22 0x0804aed7 in ?? ()
#23 0x0804aed7 in ?? ()
#24 0x0804b2a1 in ?? ()
#25 0x0804aeff in ?? ()
#26 0x0804aed7 in ?? ()
#27 0x0804bf6e in ?? ()
#28 0x0804af71 in ?? ()
#29 0x0804add9 in ?? ()
#30 0x0804b18d in ?? ()
#31 0x0804aef1 in ?? ()
#32 0x0804aed7 in ?? ()
#33 0x0804add9 in ?? ()
#34 0x0804add9 in ?? ()
#35 0x0804add9 in ?? ()
#36 0x0804b2a1 in ?? ()
#37 0x0804aeff in ?? ()
#38 0x08053767 in ?? ()
#39 0x0805364b in ?? ()
#40 0x0804814c in ?? ()
(kgdb) detach
Ending remote debugging.
(kgdb) quit
Script done on Wed Nov 20 04:13:05 2002
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Brian Fundakowski Feldman [EMAIL PROTECTED] wrote: I can't get more info because crash dumps don't work when this happens, but for what it's worth, here's a traceback which shows what happens when I attempt to use my da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device on an OHCI-based controller. This was working just a few days ago with a UHCI controller, so ... The crash is from an invalid read at 0xbff3e000, which is PTmap plus some offset. The trace as far as I can get it, from a kernel with USB but no options enabled, would be: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. Anyone? I kinda want to use my CF reader. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
On Sun, Nov 17, 2002 at 01:18:00PM -0500, Brian F. Feldman wrote: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. Anyone? I kinda want to use my CF reader. There are rumours that OHCI is borked in NetBSD too and this is a bug that we've inherited. Me, I've not got an OHCI system to test just UHCI. Did it used to work, and got broken, or has it never worked? Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = msg46816/pgp0.pgp Description: PGP signature
Re: kernel panic when booting with USB CF reader
On Sat, 28 Sep 2002, Lars Eggert wrote: I'm seeing a kernel panic on -current (9/26) when booting with a SanDisk ImageMate II USB comact flash reader plugged in. The panic occurs after the kernel has loaded when the first rc.d scripts execute (dumpon, vinum, etc). If I boot with the device disconnected, I can plug it in and unplug it without problems later. Attached is a boot trace and a gdb backtrace. (gdb crashed on me, so I couldn't get more information.) Here's the relevant info from the trace: SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/da0s1a Entropy harvesting: interrupts ethernet point_to_point. kernel dumps on /dev/da1s1b vinum: loaded umass0: BBB reset failed, STALLED da2 at umass-sim0 bus 0 target 0 lun 0 da2: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device da2: 1.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present (da2:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da2:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da2:umass-sim0:0:0:0): SCSI Status: Check Condition (da2:umass-sim0:0:0:0): NOT READY asc:3a,0 (da2:umass-sim0:0:0:0): Medium not present (da2:umass-sim0:0:0:0): Unretryable error Fatal trap 18: integer divide fault while in kernel mode cpuid = 1; lapic.id = 0200 instruction pointer = 0x8:0xc0437608 stack pointer = 0x10:0xeb484870 frame pointer = 0x10:0xeb4848f8 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 = 67 (vinum) kernel: type 18 trap, code=0 Stopped at __qdivrem+0x38: divl%ecx,%eax Is this still a problem? Does it work if you have a flash card plugged into the reader while booting? Can you enable options DDB and type tr to get a backtrace after the panic? The problem appears to be that something is using the return value from READ CAP even though it is not set because there is no flash present (i.e. div by 0). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic when booting with USB CF reader
Nate Lawson wrote: On Sat, 28 Sep 2002, Lars Eggert wrote: I'm seeing a kernel panic on -current (9/26) when booting with a SanDisk ImageMate II USB comact flash reader plugged in. The panic occurs after the kernel has loaded when the first rc.d scripts execute (dumpon, vinum, etc). Is this still a problem? Nope, the problem disappeared sometime in October. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
CNet CNWLC-811 (PRISM2), kernel panic
Hello,
Just bought a CNet WLAN card, and it makes -CURRENT panic when inserted,
or if it is inserted while booting.
Userland installed from 20021101 snapshot.
Kernel from today: FreeBSD 5.0-CURRENT #0: Sat Nov 2 09:50:05 CET 2002
(second panic from me issuing panic from ddb)
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xd11fa000
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01aa2d5
stack pointer = 0x10:0xcc00494c
frame pointer = 0x10:0xcc004b78
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 = 9 (cbb1)
panic: from debugger
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc03b47d4
stack pointer = 0x10:0xcc0046bc
frame pointer = 0x10:0xcc0046c8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 9 (cbb1)
panic: from debugger
Uptime: 1m11s
Dumping 224 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208
---
#0 doadump () at ../../../kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc0242d89 in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc0242fd3 in panic () at ../../../kern/kern_shutdown.c:517
#3 0xc0147ac2 in db_panic () at ../../../ddb/db_command.c:450
#4 0xc0147a42 in db_command (last_cmdp=0xc0429b40, cmd_table=0x0,
aux_cmd_tablep=0xc0422fb8, aux_cmd_tablep_end=0xc0422fbc)
at ../../../ddb/db_command.c:346
#5 0xc0147b56 in db_command_loop () at ../../../ddb/db_command.c:472
#6 0xc014a80a in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:72
#7 0xc03b4532 in kdb_trap (type=12, code=0, regs=0xcc00490c)
at ../../../i386/i386/db_interface.c:166
#8 0xc03c5e12 in trap_fatal (frame=0xcc00490c, eva=0)
at ../../../i386/i386/trap.c:841
#9 0xc03c5b22 in trap_pfault (frame=0xcc00490c, usermode=0,
eva=3508510720)
at ../../../i386/i386/trap.c:760
#10 0xc03c558d in trap (frame=
{tf_fs = -1037107176, tf_es = -872415216, tf_ds = -1072168944,
tf_edi = -1036984320, tf_esi = -1037051392, tf_ebp = -872395912, tf_isp
= -872396488, tf_ebx = 0, tf_edx = -786460672, tf_ecx = -1037071868,
tf_eax = 4096, tf_trapno = 12, tf_err = 0, tf_eip = -1071996203, tf_cs =
8, tf_eflags = 66050, tf_esp = -1037051392, tf_ss = -1036984320}) at
../../../i386/i386/trap.c:446
#11 0xc03b5d08 in calltrap () at {standard input}:98
#12 0xc01aa105 in pccard_read_cis (sc=0x0)
at ../../../dev/pccard/pccard_cis.c:98
#13 0xc01a7ab2 in pccard_attach_card (dev=0xc230e000)
at ../../../dev/pccard/pccard.c:168
#14 0xc01afd26 in cbb_insert (sc=0xc22f8a00) at card_if.h:66
#15 0xc01afad8 in cbb_event_thread (arg=0xc22f8a00)
at ../../../dev/pccbb/pccbb.c:917
#16 0xc022dab4 in fork_exit (callout=0xc01afa40 cbb_event_thread,
arg=0x0,
frame=0x0) at ../../../kern/kern_fork.c:860
(kgdb)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: CNet CNWLC-811 (PRISM2), kernel panic
Does this happen with OLDCARD? I have a couple of cards that do this, but haven't been able to track down why this happens. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CNet CNWLC-811 (PRISM2), kernel panic
Hello, With OLDCARD it does not crash! After crafting a pccard.conf entry for the card, wi does not successfully attach to the card. Do you think it is feasible to add support for this card in the wi driver? Please don't hesitate to ask me for more information if you need it, thanks! If there is any dirty work to be done to make it work, tell me. I'll be more than happy to do it for you :) pccard.conf line: # CNet CNWLC-811 card OEM 11Mbps Wireless LAN PC Card V-3 config auto wi ? insert /etc/pccard_ether $device start remove /etc/pccard_ether $device stop I get the following output from the driver: wi0 at port 0x240-0x27f irq 11 slot 1 on pccard1 wi0: timeout in wi_cmd 0x; event status 0x wi0: timeout in wi_cmd 0x; event status 0x wi0: timeout in wi_cmd 0x; event status 0x wi0: init failed wi0: timeout in wi_cmd 0x0021; event status 0x wi0: timeout in wi_cmd 0x0021; event status 0x wi0: mac read failed 5 device_probe_and_attach: wi0 attach returned 5 # pccardc dumpcis Configuration data for card in slot 1 Tuple #1, code = 0x17 (Attribute memory descriptor), length = 3 000: d9 01 ff Attribute memory device information: Device number 1, type Function specific, WPS = ON Speed = 250nS, Memory block size = 2Kb, 1 units Tuple #2, code = 0x1d (Other conditions for attribute memory), length = 4 000: 01 d9 01 ff (MWAIT) Tuple #3, code = 0x20 (Manufacturer ID), length = 4 000: 00 00 00 00 PCMCIA ID = 0x0, OEM ID = 0x0 Tuple #4, code = 0x21 (Functional ID), length = 2 000: 06 00 Network/LAN adapter Tuple #5, code = 0x15 (Version 1 info), length = 39 000: 05 00 4f 45 4d 00 31 31 4d 62 70 73 20 57 69 72 010: 65 6c 65 73 73 20 4c 41 4e 20 50 43 20 43 61 72 020: 64 20 56 2d 33 00 ff Version = 5.0, Manuf = [OEM], card vers = [11Mbps Wireless LAN PC Card V-3] Tuple #6, code = 0x1a (Configuration map), length = 6 000: 01 02 00 08 03 ff Reg len = 2, config register addr = 0x800, last config = 0xff Registers: XX-- 1 bytes in subtuples Tuple #7, code = 0x1b (Configuration entry), length = 15 000: c1 81 9d 71 55 2e 2e 2d fc 14 45 10 b8 ff 20 Config index = 0x1(default) Interface byte = 0x81 (I/O) wait signal supported Vcc pwr: Nominal operating supply voltage: 5 x 1V Max current average over 1 second: 2.5 x 100mA Max current average over 10 ms: 2.5 x 100mA Power down supply current: 2.5 x 10mA Wait scale Speed = 1.2 x 10 us Card decodes 5 address lines, limited 8/16 Bit I/O IRQ modes: IRQs: 3 4 5 7 8 9 10 11 12 13 14 15 Max twin cards = 0 Misc attr: (Power down supported) Tuple #8, code = 0xff (Terminator), length = 0 2 slots found Mvh, Frode Nordahl On Sat, 2002-11-02 at 19:15, M. Warner Losh wrote: Does this happen with OLDCARD? I have a couple of cards that do this, but haven't been able to track down why this happens. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CNet CNWLC-811 (PRISM2), kernel panic
In message: [EMAIL PROTECTED] Frode Nordahl [EMAIL PROTECTED] writes: : With OLDCARD it does not crash! I'll answer this twice... Can I ask you to do the following: pccardc pccard_mem pccardc pccard_mem 0xf800 pccardc dumpcis (well, where 0xf800 is the same address that NEWCARD reported it was using for ccb bridge). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CNet CNWLC-811 (PRISM2), kernel panic
In message: [EMAIL PROTECTED] Frode Nordahl [EMAIL PROTECTED] writes: : I get the following output from the driver: : wi0 at port 0x240-0x27f irq 11 slot 1 on pccard1 : wi0: timeout in wi_cmd 0x; event status 0x : wi0: timeout in wi_cmd 0x; event status 0x : wi0: timeout in wi_cmd 0x; event status 0x : wi0: init failed : wi0: timeout in wi_cmd 0x0021; event status 0x : wi0: timeout in wi_cmd 0x0021; event status 0x : wi0: mac read failed 5 : device_probe_and_attach: wi0 attach returned 5 This tells me that the wi driver likely doesn't support this (or 0x240 isn't a good place to put it, you might try 0x300 instead)... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CNet CNWLC-811 (PRISM2), kernel panic
On Sun, 2002-11-03 at 00:16, M. Warner Losh wrote: pccardc pccard_mem # pccardc pccardmem PCCARD Memory address set to 0xd pccardc pccard_mem 0xf800 # pccardc pccardmem 0xf800 PCCARD Memory address set to 0xf800 pccardc dumpcis # pccardc pccardmem PCCARD Memory address set to 0xf800 # pccardc dumpcis Configuration data for card in slot 1 Tuple #1, code = 0x17 (Attribute memory descriptor), length = 3 000: d9 01 ff Attribute memory device information: Device number 1, type Function specific, WPS = ON Speed = 250nS, Memory block size = 2Kb, 1 units Tuple #2, code = 0x1d (Other conditions for attribute memory), length = 4 000: 01 d9 01 ff (MWAIT) Tuple #3, code = 0x20 (Manufacturer ID), length = 4 000: 00 00 00 00 PCMCIA ID = 0x0, OEM ID = 0x0 Tuple #4, code = 0x21 (Functional ID), length = 2 000: 06 00 Network/LAN adapter Tuple #5, code = 0x15 (Version 1 info), length = 39 000: 05 00 4f 45 4d 00 31 31 4d 62 70 73 20 57 69 72 010: 65 6c 65 73 73 20 4c 41 4e 20 50 43 20 43 61 72 020: 64 20 56 2d 33 00 ff Version = 5.0, Manuf = [OEM], card vers = [11Mbps Wireless LAN PC Card V-3] Tuple #6, code = 0x1a (Configuration map), length = 6 000: 01 02 00 08 03 ff Reg len = 2, config register addr = 0x800, last config = 0xff Registers: XX-- 1 bytes in subtuples Tuple #7, code = 0x1b (Configuration entry), length = 15 000: c1 81 9d 71 55 2e 2e 2d fc 14 45 10 b8 ff 20 Config index = 0x1(default) Interface byte = 0x81 (I/O) wait signal supported Vcc pwr: Nominal operating supply voltage: 5 x 1V Max current average over 1 second: 2.5 x 100mA Max current average over 10 ms: 2.5 x 100mA Power down supply current: 2.5 x 10mA Wait scale Speed = 1.2 x 10 us Card decodes 5 address lines, limited 8/16 Bit I/O IRQ modes: IRQs: 3 4 5 7 8 9 10 11 12 13 14 15 Max twin cards = 0 Misc attr: (Power down supported) Tuple #8, code = 0xff (Terminator), length = 0 2 slots found (well, where 0xf800 is the same address that NEWCARD reported it was using for ccb bridge). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic when booting with USB CF reader
On Tue, Oct 22, 2002 at 12:10:25AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Lars Eggert writes: umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 5 umass0: Get Max Lun not supported (STALLED) da2 at umass-sim0 bus 0 target 0 lun 0 da2: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device da2: 1.000MB/s transfers da2: 1027MB (2104705 512 byte sectors: 0H 0S/T 0C) but there's only /dev/da2 under /dev, and no entries for the slices. Shouldn't devfs or usbd or something create them automatically, since MAKEDEV is no more? You can probably trigger a re-examination of the device by opening it for write and closing again. Something as simple as sh -c true 4/dev/da2 may do the trick. It's just the Name that don't exist. Some time ago I was told to just open the device even if there is no node listable in /dev. E.g. mount_msdosfs /dev/da2s1 /mnt This is a pre GEOM scenario, so it might have been fixed. Also the panic is a pre GEOM panic - at least for me. I wouldn't give it much time to debug before rechecking with a recent kernel. I can't update my machine right now, but if Lars could update his system and recheck the situation... -- 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
Re: kernel panic when booting with USB CF reader
Bernd Walter wrote: It's just the Name that don't exist. Some time ago I was told to just open the device even if there is no node listable in /dev. E.g. mount_msdosfs /dev/da2s1 /mnt Yes, this works (Terry also pointed this out.) I wish this could be wired to the media change signal somehow. This is a pre GEOM scenario, so it might have been fixed. Also the panic is a pre GEOM panic - at least for me. I wouldn't give it much time to debug before rechecking with a recent kernel. I can't update my machine right now, but if Lars could update his system and recheck the situation... Just checkeded, and it does NOT crash anymore on bootup when no media is inserted (with yesterday's -current.) Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: kernel panic when booting with USB CF reader
On Tue, Oct 22, 2002 at 10:23:06AM -0700, Lars Eggert wrote: Bernd Walter wrote: It's just the Name that don't exist. Some time ago I was told to just open the device even if there is no node listable in /dev. E.g. mount_msdosfs /dev/da2s1 /mnt Yes, this works (Terry also pointed this out.) I wish this could be wired to the media change signal somehow. I'm seeing the phaenomen with a CF media in a pcmcia slot. There is no media change in that situation because the CF itself implements the ata commands. But then again - it should be verified with a recent -current. This is a pre GEOM scenario, so it might have been fixed. Also the panic is a pre GEOM panic - at least for me. I wouldn't give it much time to debug before rechecking with a recent kernel. I can't update my machine right now, but if Lars could update his system and recheck the situation... Just checkeded, and it does NOT crash anymore on bootup when no media is inserted (with yesterday's -current.) Nice to hear. -- 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
Re: kernel panic when booting with USB CF reader
Bernd Walter wrote: On Sat, Sep 28, 2002 at 07:20:08PM -0700, Lars Eggert wrote: I'm seeing a kernel panic on -current (9/26) when booting with a SanDisk ImageMate II USB comact flash reader plugged in. The panic occurs after the kernel has loaded when the first rc.d scripts execute (dumpon, vinum, etc). If I boot with the device disconnected, I can plug it in and unplug it without problems later. Attached is a boot trace and a gdb backtrace. ... I'm seeing the same with a SCSI mo drive. As a short term work around I inserted a media. src from 31th Aug did run and from 21th Sep does not. That workaround is OK. But can you actually mount the USB CF reader? Mine shows up as da2 umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 5 umass0: Get Max Lun not supported (STALLED) da2 at umass-sim0 bus 0 target 0 lun 0 da2: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device da2: 1.000MB/s transfers da2: 1027MB (2104705 512 byte sectors: 0H 0S/T 0C) but there's only /dev/da2 under /dev, and no entries for the slices. Shouldn't devfs or usbd or something create them automatically, since MAKEDEV is no more? Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: kernel panic when booting with USB CF reader
In message [EMAIL PROTECTED], Lars Eggert writes: umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 5 umass0: Get Max Lun not supported (STALLED) da2 at umass-sim0 bus 0 target 0 lun 0 da2: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device da2: 1.000MB/s transfers da2: 1027MB (2104705 512 byte sectors: 0H 0S/T 0C) but there's only /dev/da2 under /dev, and no entries for the slices. Shouldn't devfs or usbd or something create them automatically, since MAKEDEV is no more? You can probably trigger a re-examination of the device by opening it for write and closing again. Something as simple as sh -c true 4/dev/da2 may do the trick. -- 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 trying to utilize a da(4)/umass(4) device with ohci(4)
Does this happen on a current with this patch applied too? Index: usb_port.h === RCS file: /home/ncvs/src/sys/dev/usb/usb_port.h,v retrieving revision 1.58 diff -u -r1.58 usb_port.h --- usb_port.h 2 Oct 2002 07:44:20 - 1.58 +++ usb_port.h 18 Oct 2002 15:14:23 - @@ -339,10 +339,7 @@ #define USBVERBOSE -/* We don't use the soft interrupt code in FreeBSD. */ -#if 0 #define USB_USE_SOFTINTR -#endif #define Static static Joe On Sun, Oct 06, 2002 at 07:42:18PM -0400, Brian Fundakowski Feldman wrote: I can't get more info because crash dumps don't work when this happens, but for what it's worth, here's a traceback which shows what happens when I attempt to use my da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device on an OHCI-based controller. This was working just a few days ago with a UHCI controller, so ... The crash is from an invalid read at 0xbff3e000, which is PTmap plus some offset. The trace as far as I can get it, from a kernel with USB but no options enabled, would be: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg44888/pgp0.pgp Description: PGP signature
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Josef Karthauser [EMAIL PROTECTED] wrote: Does this happen on a current with this patch applied too? I'm certain I tried this already :( -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map toosmall...
jroberson I suspect that there is some other bug then. 1/2 of your jroberson memory should not be consumed by kernel malloc. Do you jroberson have an abnormally large MD or something? MD devices are used to create installation floppies but no, it should be 1.44MB/2.88MB size, relatively small one. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map toosmall...
Makoto Matsushita wrote:
jroberson I suspect that there is some other bug then. 1/2 of your
jroberson memory should not be consumed by kernel malloc. Do you
jroberson have an abnormally large MD or something?
MD devices are used to create installation floppies but no, it should
be 1.44MB/2.88MB size, relatively small one.
The worst case failure with my Ugly patch should be that things hang,
and quit running completey.
If you could save a vmstat -m periodically, approaching the problem
this may help us identify where the memory is going, e.g. the output
from running this script:
#!/bin/sh
INTERVAL=20
while true
do
for i in 0 1 2 3 4 5 6 7 8 9
do
vmstat -m vmstatlog.$i
sync
sleep ${INTERVAL}
done
done
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_maptoosmall...
tlambert2 The worst case failure with my Ugly patch should be that tlambert2 things hang, and quit running completey. I've emailed to the list that I've tried your patch but it cannot boot (actually it boots, but panics immediately.) Maybe I'm using different time of source code. Which 5-current source code did you use to write the patch? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_maptoosmall...
Makoto Matsushita wrote: tlambert2 The worst case failure with my Ugly patch should be that tlambert2 things hang, and quit running completey. I've emailed to the list that I've tried your patch but it cannot boot (actually it boots, but panics immediately.) Maybe I'm using different time of source code. Which 5-current source code did you use to write the patch? Can you provide a traceback, in this case? The patch should have converted all calls that asked for nowait into waiting calls that blocked for memory to be available, instead of panic'ing when it wasn't. In other words, it should be impossible to get the same panic, you should only get a different panic. I'd like to know what the different panic is... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map too small...
On Tue, 15 Oct 2002, Makoto Matsushita wrote: I'm now trying Terry's patch (just rebuilding a kernel). jroberson You are using 100mb of KVA for malloc(9)? Are you certain jroberson that you don't have a memory leak? Maybe there's a chance of a memory leakage by GLOBAL, but I don't sure. jroberson How much memory is in this machine? What are you using it jroberson for? It has 256MB memory, and is used for 5-current release buildbox. I suspect that there is some other bug then. 1/2 of your memory should not be consumed by kernel malloc. Do you have an abnormally large MD or something? Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel panic with panic: kmem_malloc(4096): kmem_map too small...
After upgrading my 5-current box (as of late September 2002), the kernel panics periodically with following message: panic: kmem_malloc(4096): kmem_map too small: 107651072 total allocated The number '4096' and '107651072' is always the same. What am I missing something? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map too small...
Makoto Matsushita wrote: After upgrading my 5-current box (as of late September 2002), the kernel panics periodically with following message: panic: kmem_malloc(4096): kmem_map too small: 107651072 total allocated The number '4096' and '107651072' is always the same. What am I missing something? This was recently discussed on -current. I posted a dumb patch that fixes the problem. Jeff Roberson is looking at fixing the problem the right way right now. Until then, though, you can still use my patch (it makes UMA use kmem_alloc_wait, instead of kmem_malloc). See the archive of the posting, for more details: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1612532+0+archive/2002/freebsd-current/20021013.freebsd-current -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map too small...
On Mon, 14 Oct 2002, Makoto Matsushita wrote: After upgrading my 5-current box (as of late September 2002), the kernel panics periodically with following message: panic: kmem_malloc(4096): kmem_map too small: 107651072 total allocated The number '4096' and '107651072' is always the same. What am I missing something? You are using 100mb of KVA for malloc(9)? Are you certain that you don't have a memory leak? How much memory is in this machine? What are you using it for? Thanks! Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map toosmall...
I'm now trying Terry's patch (just rebuilding a kernel). jroberson You are using 100mb of KVA for malloc(9)? Are you certain jroberson that you don't have a memory leak? Maybe there's a chance of a memory leakage by GLOBAL, but I don't sure. jroberson How much memory is in this machine? What are you using it jroberson for? It has 256MB memory, and is used for 5-current release buildbox. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map toosmall...
tlambert2 This was recently discussed on -current. I posted a dumb tlambert2 patch that fixes the problem. (stuff deleted) tlambert2 See the archive of the posting, for more details: Thank you, I'll try it right now. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map toosmall...
matusita Thank you, I'll try it right now. Unfortunately, kernel panics soon after it wakes up... maybe I've still missed something. -- - Makoto `MAR' Matsushita Booting [/boot/kernel/kernel]... Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Tue Oct 15 11:18:35 JST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SNAPSHOTS_CURRENT Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3e fault code = supervisor write, page not present instruction pointer = 0x8:0xc0262891 stack pointer = 0x10:0xc03d3b5c frame pointer = 0x10:0xc03d3b5c 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 = 0 () trap number = 12 panic: page fault Uptime: 1s To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic from vinum during 'restore'
On 05.10-22:16, n0g0013 wrote: don't currently have the kernel trace for this (i'm rebuilding to get one) and the dump's not making it to disk. perhaps someone else could try and verify in the mean time. don't know if this is related to Mikhail Teterin's post a few hours ago but i have the ddb trace. it may not be exactly accurate because i don't have a serial ddb and therefore have to copy the output from the screen. +++ ddb output from kernel panic +++ panic: kmem_malloc(4096): kmem_map too small: 23134208 total allocated Debugger(panic) Stopped at Debugger+0q45: xchgl %ebx,in_Debugger.0 db trace Debugger(c02cd335) at Debugger+0x45 panic(c02e1402,1000,161,10012,1000) at panic+0x9f kmem_malloc(c0432078,1000,4,c49b47cc,c02759a8) at kmem_malloc+0xcc page_alloc(c05ac500,1000,c49b47bf,4,0) at page_alloc+0x1a slab_zalloc(c05ac500,4,c0daba00,c05ac5e8,c05ac500) at slab_zalloc+0x108 uma_zalloc_internal(c05ac500,0,4,c0daba00) at uma_zalloc_internal+0x13c uma_zalloc_arg(c05ac500,0,4) at uma_zalloc_arg+0x2f4 getnewvnode(c02e070e,c0f4c000,c0dc1100,c49b48b8,90) at getnewvnode+0x3e9 ffs_vget(c0f4c000,486,2,c49b491c,1) at ffs_vget+0x71 ffs_valloc(c1153378,8180,c0f98780,c49b491c) at ffs_valloc+0xed ufs_makeinode(8180,c1153378,c49b4bf8,c49b4c0c) at ufs_makeinode+0x5b ufs_create(c49b4a70,c49b4a90,c01df957,c49b4a70,c02f1260) at ufs_create+0x2b ufs_vnoperate(c49b3a70) at ufs_vnoperate+0x13 VOP_CREATE(c1153378,c49b4bf8,c49b4c0c,c49b4ad4,229) at VOP_CREATE+0x37 vn_open_cred(c49b4be4,c49b4ce4,180,c0f98780,c49b4cd0) at vn_open_cred+0x154 vn_open(c49b4be4,c49b4ce4,180,c1bec3b0,c0de7b04) at vn_open+0x18 kern_open(c05b0680,80ad0c1,0,602,1b6) at kern_open+0x18b open(c05b0680,c49b4d14,3,a83,292) at open+0x18 syscall(2f,2f,2f,80ad0c1,0) at syscall+0x24a Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x08053a43, esp = 0xbfbff73c, ebp = 0xbfbff778 --- db --- ddb output from kernel panic --- * that's no fun * config is identical to before with a kernel rebuild from same sources ( some time last night ). the error i was orginally seeing (over the last week or so) seemed to appear in the vinum_devstrategy but since the various vinum changes it appears to have migrated. -- t t z ---BeginMessage--- got panic from vinum on a small striped drive with small dump/restores -- dump of usr fs to file and restore to vinum volume. dump file is about 120m. kernel built from about -0230 sources but i've been seeing them since first switched current on about 2 weeks ago. don't currently have the kernel trace for this (i'm rebuilding to get one) and the dump's not making it to disk. perhaps someone else could try and verify in the mean time. +++ kernel panic message +++ panic: kmem_malloc(4096): kmem_map to small: 23179264 total allocated syncing disks... panic: allocbuf: buffer not busy Uptime: 18m12s Dumping 48 MB ata1: resetting devices .. panic: free locked buf Uptime: 18m12s Automatice Reboot in 15 seconds - press a key on the console to abort --- kernel panic message --- +++ vinum config +++ # Vinum configuration of eyore.blahdeblah.demon.co.uk, saved at Sat Oct 5 22:02:24 2002 drive snub device /dev/ad0s1h drive junk device /dev/ad2s1h volume var volume usr volume home volume software plex name var.plex0 org striped 534s vol var plex name usr.plex0 org striped 534s vol usr plex name home.plex0 org striped 534s vol home plex name software.plex0 org striped 534s vol software sd name snub.s0 drive snub plex var.plex0 len 163404s driveoffset 265s plexoffset 0s sd name junk.s0 drive junk plex var.plex0 len 163404s driveoffset 265s plexoffset 534s sd name snub.s1 drive snub plex usr.plex0 len 614100s driveoffset 164105s plexoffset 0s sd name junk.s1 drive junk plex usr.plex0 len 614100s driveoffset 164105s plexoffset 534s sd name snub.s2 drive snub plex home.plex0 len 409578s driveoffset 778505s plexoffset 0s sd name junk.s2 drive junk plex home.plex0 len 409578s driveoffset 778505s plexoffset 534s sd name snub.s3 drive snub plex software.plex0 len 1638312s driveoffset 1188083s plexoffset 0s sd name junk.s3 drive junk plex software.plex0 len 1638312s driveoffset 1188083s plexoffset 534s --- vinum config --- -- t t z msg44108/pgp0.pgp Description: PGP signature ---End Message--- msg44108/pgp1.pgp Description: PGP signature
Re: kernel panic from vinum during 'restore'
i have a crash dump for this now if anyone is interested. it's not exactly the same trace as it seems to originate from a VOP_LINK request this time but i guess it's the same problem. On 06.10-16:02, n0g0013 wrote: On 05.10-22:16, n0g0013 wrote: don't currently have the kernel trace for this (i'm rebuilding to get one) and the dump's not making it to disk. perhaps someone else could try and verify in the mean time. don't know if this is related to Mikhail Teterin's post a few hours ago but i have the ddb trace. it may not be exactly accurate because i don't have a serial ddb and therefore have to copy the output from the screen. +++ ddb output from kernel panic +++ panic: kmem_malloc(4096): kmem_map too small: 23134208 total allocated Debugger(panic) Stopped atDebugger+0q45: xchgl %ebx,in_Debugger.0 db trace Debugger(c02cd335) at Debugger+0x45 panic(c02e1402,1000,161,10012,1000) at panic+0x9f kmem_malloc(c0432078,1000,4,c49b47cc,c02759a8) at kmem_malloc+0xcc page_alloc(c05ac500,1000,c49b47bf,4,0) at page_alloc+0x1a slab_zalloc(c05ac500,4,c0daba00,c05ac5e8,c05ac500) at slab_zalloc+0x108 uma_zalloc_internal(c05ac500,0,4,c0daba00) at uma_zalloc_internal+0x13c uma_zalloc_arg(c05ac500,0,4) at uma_zalloc_arg+0x2f4 getnewvnode(c02e070e,c0f4c000,c0dc1100,c49b48b8,90) at getnewvnode+0x3e9 ffs_vget(c0f4c000,486,2,c49b491c,1) at ffs_vget+0x71 ffs_valloc(c1153378,8180,c0f98780,c49b491c) at ffs_valloc+0xed ufs_makeinode(8180,c1153378,c49b4bf8,c49b4c0c) at ufs_makeinode+0x5b ufs_create(c49b4a70,c49b4a90,c01df957,c49b4a70,c02f1260) at ufs_create+0x2b ufs_vnoperate(c49b3a70) at ufs_vnoperate+0x13 VOP_CREATE(c1153378,c49b4bf8,c49b4c0c,c49b4ad4,229) at VOP_CREATE+0x37 vn_open_cred(c49b4be4,c49b4ce4,180,c0f98780,c49b4cd0) at vn_open_cred+0x154 vn_open(c49b4be4,c49b4ce4,180,c1bec3b0,c0de7b04) at vn_open+0x18 kern_open(c05b0680,80ad0c1,0,602,1b6) at kern_open+0x18b open(c05b0680,c49b4d14,3,a83,292) at open+0x18 syscall(2f,2f,2f,80ad0c1,0) at syscall+0x24a Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x08053a43, esp = 0xbfbff73c, ebp = 0xbfbff778 --- db --- ddb output from kernel panic --- * that's no fun * config is identical to before with a kernel rebuild from same sources ( some time last night ). the error i was orginally seeing (over the last week or so) seemed to appear in the vinum_devstrategy but since the various vinum changes it appears to have migrated. -- t t z Date: Sat, 5 Oct 2002 22:16:10 +0100 Subject: kernel panic from vinum during 'restore' From: n0g0013 [EMAIL PROTECTED] To: current [EMAIL PROTECTED] got panic from vinum on a small striped drive with small dump/restores -- dump of usr fs to file and restore to vinum volume. dump file is about 120m. kernel built from about -0230 sources but i've been seeing them since first switched current on about 2 weeks ago. don't currently have the kernel trace for this (i'm rebuilding to get one) and the dump's not making it to disk. perhaps someone else could try and verify in the mean time. +++ kernel panic message +++ panic: kmem_malloc(4096): kmem_map to small: 23179264 total allocated syncing disks... panic: allocbuf: buffer not busy Uptime: 18m12s Dumping 48 MB ata1: resetting devices .. panic: free locked buf Uptime: 18m12s Automatice Reboot in 15 seconds - press a key on the console to abort --- kernel panic message --- +++ vinum config +++ # Vinum configuration of eyore.blahdeblah.demon.co.uk, saved at Sat Oct 5 22:02:24 2002 drive snub device /dev/ad0s1h drive junk device /dev/ad2s1h volume var volume usr volume home volume software plex name var.plex0 org striped 534s vol var plex name usr.plex0 org striped 534s vol usr plex name home.plex0 org striped 534s vol home plex name software.plex0 org striped 534s vol software sd name snub.s0 drive snub plex var.plex0 len 163404s driveoffset 265s plexoffset 0s sd name junk.s0 drive junk plex var.plex0 len 163404s driveoffset 265s plexoffset 534s sd name snub.s1 drive snub plex usr.plex0 len 614100s driveoffset 164105s plexoffset 0s sd name junk.s1 drive junk plex usr.plex0 len 614100s driveoffset 164105s plexoffset 534s sd name snub.s2 drive snub plex home.plex0 len 409578s driveoffset 778505s plexoffset 0s sd name junk.s2 drive junk plex home.plex0 len 409578s driveoffset 778505s plexoffset 534s sd name snub.s3 drive snub plex software.plex0 len 1638312s driveoffset 1188083s plexoffset 0s sd name junk.s3 drive junk plex software.plex0 len 1638312s driveoffset 1188083s plexoffset 534s --- vinum config --- -- t t z -- t t z To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic from vinum during 'restore'
On Sun, 6 Oct 2002, fergus wrote: i have a crash dump for this now if anyone is interested. it's not exactly the same trace as it seems to originate from a VOP_LINK request this time but i guess it's the same problem. To be honest, it sounds like something is simply leaking kernel memory/address space. What you might want to do is have vmstat -m looping with a sleep in the background, writing to a log file, then see if you can figure out which number goes up, but never down.. Maybe something is leaking memory that previously wasn't. You shouldn't even need to crash the machine to figure it out, I think (although with a serious kernel memory leak scenario, that might be unavoidable :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
I can't get more info because crash dumps don't work when this happens, but for what it's worth, here's a traceback which shows what happens when I attempt to use my da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device on an OHCI-based controller. This was working just a few days ago with a UHCI controller, so ... The crash is from an invalid read at 0xbff3e000, which is PTmap plus some offset. The trace as far as I can get it, from a kernel with USB but no options enabled, would be: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic from vinum during 'restore'
On Sunday, 6 October 2002 at 18:25:08 -0400, Robert Watson wrote: On Sun, 6 Oct 2002, fergus wrote: i have a crash dump for this now if anyone is interested. it's not exactly the same trace as it seems to originate from a VOP_LINK request this time but i guess it's the same problem. To be honest, it sounds like something is simply leaking kernel memory/address space. What you might want to do is have vmstat -m looping with a sleep in the background, writing to a log file, then see if you can figure out which number goes up, but never down.. Maybe something is leaking memory that previously wasn't. You shouldn't even need to crash the machine to figure it out, I think (although with a serious kernel memory leak scenario, that might be unavoidable :-). As a reminder, Vinum keeps track of its kernel memory allocation, and you can view it at any time with 'vinum info -v'. In a typical scenario, you'd expect to see about 50 to 100 kB allocated in about 50 chunks. If you see more, send me the list and I'll check if it looks like a memory leak. I haven't seen any for a long time. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic trying to utilize a da(4)/umass(4) device withohci(4)
Hi. See pr kern/43462. Happens to me. I wish it would get fixed :) On Sun, 6 Oct 2002, Brian Fundakowski Feldman wrote: I can't get more info because crash dumps don't work when this happens, but for what it's worth, here's a traceback which shows what happens when I attempt to use my da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device on an OHCI-based controller. This was working just a few days ago with a UHCI controller, so ... The crash is from an invalid read at 0xbff3e000, which is PTmap plus some offset. The trace as far as I can get it, from a kernel with USB but no options enabled, would be: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel panic from vinum during 'restore'
got panic from vinum on a small striped drive with small dump/restores -- dump of usr fs to file and restore to vinum volume. dump file is about 120m. kernel built from about -0230 sources but i've been seeing them since first switched current on about 2 weeks ago. don't currently have the kernel trace for this (i'm rebuilding to get one) and the dump's not making it to disk. perhaps someone else could try and verify in the mean time. +++ kernel panic message +++ panic: kmem_malloc(4096): kmem_map to small: 23179264 total allocated syncing disks... panic: allocbuf: buffer not busy Uptime: 18m12s Dumping 48 MB ata1: resetting devices .. panic: free locked buf Uptime: 18m12s Automatice Reboot in 15 seconds - press a key on the console to abort --- kernel panic message --- +++ vinum config +++ # Vinum configuration of eyore.blahdeblah.demon.co.uk, saved at Sat Oct 5 22:02:24 2002 drive snub device /dev/ad0s1h drive junk device /dev/ad2s1h volume var volume usr volume home volume software plex name var.plex0 org striped 534s vol var plex name usr.plex0 org striped 534s vol usr plex name home.plex0 org striped 534s vol home plex name software.plex0 org striped 534s vol software sd name snub.s0 drive snub plex var.plex0 len 163404s driveoffset 265s plexoffset 0s sd name junk.s0 drive junk plex var.plex0 len 163404s driveoffset 265s plexoffset 534s sd name snub.s1 drive snub plex usr.plex0 len 614100s driveoffset 164105s plexoffset 0s sd name junk.s1 drive junk plex usr.plex0 len 614100s driveoffset 164105s plexoffset 534s sd name snub.s2 drive snub plex home.plex0 len 409578s driveoffset 778505s plexoffset 0s sd name junk.s2 drive junk plex home.plex0 len 409578s driveoffset 778505s plexoffset 534s sd name snub.s3 drive snub plex software.plex0 len 1638312s driveoffset 1188083s plexoffset 0s sd name junk.s3 drive junk plex software.plex0 len 1638312s driveoffset 1188083s plexoffset 534s --- vinum config --- -- t t z msg44044/pgp0.pgp Description: PGP signature
Re: kernel panic from vinum during 'restore'
On Saturday, 5 October 2002 at 22:16:10 +0100, n0g0013 wrote: got panic from vinum on a small striped drive with small dump/restores -- dump of usr fs to file and restore to vinum volume. dump file is about 120m. kernel built from about -0230 sources but i've been seeing them since first switched current on about 2 weeks ago. don't currently have the kernel trace for this (i'm rebuilding to get one) and the dump's not making it to disk. perhaps someone else could try and verify in the mean time. This looks like a resource error, possibly a memory leak. Do you have a message like this in the log files? vinum: can't allocate table space to trace memory allocation In any case, it would be interesting to see Vinum's memory statistics after the crash, if you get another one. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic when booting with USB CF reader
On Sat, Sep 28, 2002 at 07:20:08PM -0700, Lars Eggert wrote: Hi, I'm seeing a kernel panic on -current (9/26) when booting with a SanDisk ImageMate II USB comact flash reader plugged in. The panic occurs after the kernel has loaded when the first rc.d scripts execute (dumpon, vinum, etc). If I boot with the device disconnected, I can plug it in and unplug it without problems later. Attached is a boot trace and a gdb backtrace. (gdb crashed on me, so I couldn't get more information.) Here's the relevant info from the trace: SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/da0s1a Entropy harvesting: interrupts ethernet point_to_point. kernel dumps on /dev/da1s1b vinum: loaded umass0: BBB reset failed, STALLED da2 at umass-sim0 bus 0 target 0 lun 0 da2: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device da2: 1.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present (da2:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da2:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da2:umass-sim0:0:0:0): SCSI Status: Check Condition (da2:umass-sim0:0:0:0): NOT READY asc:3a,0 (da2:umass-sim0:0:0:0): Medium not present (da2:umass-sim0:0:0:0): Unretryable error Fatal trap 18: integer divide fault while in kernel mode cpuid = 1; lapic.id = 0200 instruction pointer = 0x8:0xc0437608 stack pointer = 0x10:0xeb484870 frame pointer = 0x10:0xeb4848f8 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 = 67 (vinum) kernel: type 18 trap, code=0 Stopped at __qdivrem+0x38: divl%ecx,%eax I'm seeing the same with a SCSI mo drive. As a short term work around I inserted a media. src from 31th Aug did run and from 21th Sep does not. -- 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
kernel panic when booting with USB CF reader
Hi, I'm seeing a kernel panic on -current (9/26) when booting with a SanDisk ImageMate II USB comact flash reader plugged in. The panic occurs after the kernel has loaded when the first rc.d scripts execute (dumpon, vinum, etc). If I boot with the device disconnected, I can plug it in and unplug it without problems later. Attached is a boot trace and a gdb backtrace. (gdb crashed on me, so I couldn't get more information.) Here's the relevant info from the trace: SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/da0s1a Entropy harvesting: interrupts ethernet point_to_point. kernel dumps on /dev/da1s1b vinum: loaded umass0: BBB reset failed, STALLED da2 at umass-sim0 bus 0 target 0 lun 0 da2: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device da2: 1.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present (da2:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da2:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da2:umass-sim0:0:0:0): SCSI Status: Check Condition (da2:umass-sim0:0:0:0): NOT READY asc:3a,0 (da2:umass-sim0:0:0:0): Medium not present (da2:umass-sim0:0:0:0): Unretryable error Fatal trap 18: integer divide fault while in kernel mode cpuid = 1; lapic.id = 0200 instruction pointer = 0x8:0xc0437608 stack pointer = 0x10:0xeb484870 frame pointer = 0x10:0xeb4848f8 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 = 67 (vinum) kernel: type 18 trap, code=0 Stopped at __qdivrem+0x38: divl%ecx,%eax Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sat Sep 28 18:54:56 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KERNEL-1.4 Preloaded elf kernel /boot/kernel/kernel at 0xc06c. Preloaded elf module /boot/kernel/snd_maestro3.ko at 0xc06c00b4. Preloaded elf module /boot/kernel/firewire.ko at 0xc06c0168. Preloaded elf module /boot/kernel/acpi.ko at 0xc06c0218. Timecounter i8254 frequency 1193119 Hz CPU: Pentium 4 (2372.79-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf24 Stepping = 4 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 1073180672 (1048028K bytes) avail memory = 1034698752 (1010448K bytes) Changing APIC ID for IO APIC #0 from 0 to 4 on chip Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 2, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 4, version: 0x00178020, at 0xfec0 Pentium Pro MTRR support enabled VESA: v2.0, 65536k memory, flags:0x1, mode table:0xc05aaa62 (122) VESA: ATI RADEON RV250 npx0: math processor on motherboard npx0: INT 16 interface acpi0: DELL WS 530 on motherboard Using $PIR table, 12 entries at 0xc00fb9a0 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_cpu2: CPU on acpi0 acpi_cpu3: 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 17 - irq 13 IOAPIC #0 intpin 23 - irq 16 agp0: Intel 82860 host to AGP bridge mem 0xe800-0xefff 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 17 pci1: display, VGA at device 0.0 (no driver attached) pci1: display at device 0.1 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 2.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 31.0 on pci2 pci3: ACPI PCI bus on pcib3 IOAPIC #0 intpin 20 - irq 18 IOAPIC #0 intpin 21 - irq 19 pci3: base peripheral, interrupt controller at device 0.0 (no driver attached) mpt0: LSILogic 1030 Ultra4 Adapter port 0xdc00-0xdcff mem 0xff6a-0xff6b,0xff6c-0xff6d irq 18 at device 12.0 on pci3 mpt1: LSILogic 1030 Ultra4 Adapter port 0xd800-0xd8ff mem 0xff66-0xff67,0xff68-0xff69 irq 19 at device 12.1 on pci3 pcib4: ACPI PCI-PCI bridge at device 30.0 on pci0 pci4: ACPI PCI bus on pcib4 IOAPIC #0 intpin 18 - irq 20 xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xcc80-0xccff mem 0xff3ffc00-0xff3ffc7f irq 16 at device 11.0 on pci4 /usr/src/sys/vm/uma_core.c:1307: could sleep with xl0 locked from /usr/src/sys/pci/if_xl.c:1264 /usr/src/sys/vm/uma_core.c:1307: could sleep with xl0 locked
Kernel panic
My latest panic.. Sep 25 11:39:48 leeloo kernel: ../../../vm/uma_core.c:1307: could sleep with pcm0:play:1 locked from ../../../dev/sound/pcm/dsp.c:696 Sep 25 11:39:48 leeloo kernel: ../../../vm/uma_core.c:1307: could sleep with pcm0:play:1 locked from ../../../dev/sound/pcm/dsp.c:696 Sep 25 11:39:48 leeloo kernel: ../../../vm/uma_core.c:1307: could sleep with pcm0:play:1 locked from ../../../dev/sound/pcm/dsp.c:748 Sep 25 11:39:48 leeloo kernel: ../../../vm/uma_core.c:1307: could sleep with pcm0:play:1 locked from ../../../dev/sound/pcm/dsp.c:748 Sep 25 11:39:48 leeloo kernel: ../../../vm/uma_core.c:1307: could sleep with pcm0:play:1 locked from ../../../dev/sound/pcm/dsp.c:673 Sep 25 11:49:40 leeloo kernel: acquiring duplicate lock of same type: inp Sep 25 11:49:40 leeloo kernel: 1st inp ../../../netinet/udp_usrreq.c:288 Sep 25 11:49:40 leeloo kernel: 2nd inp ../../../netinet/udp_usrreq.c:288 Sep 25 12:05:19 leeloo syslogd: kernel boot file is /boot/kernel/kernel Sep 25 12:05:19 leeloo kernel: Sep 25 12:05:19 leeloo kernel: Sep 25 12:05:19 leeloo kernel: Fatal trap 12: page fault while in kernel mode Sep 25 12:05:19 leeloo kernel: fault virtual address = 0x4 Sep 25 12:05:19 leeloo kernel: fault code= supervisor read, page not present Sep 25 12:05:19 leeloo kernel: instruction pointer = 0x8:0xc020acd2 Sep 25 12:05:19 leeloo kernel: stack pointer = 0x10:0xe8c64678 Sep 25 12:05:19 leeloo kernel: frame pointer = 0x10:0xe8c6467c Sep 25 12:05:19 leeloo kernel: code segment = base 0x0, limit 0xf, type 0x1b Sep 25 12:05:19 leeloo kernel: = DPL 0, pres 1, def32 1, gran 1 Sep 25 12:05:19 leeloo kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Sep 25 12:05:19 leeloo kernel: current process = 39662 (vim) Sep 25 12:05:19 leeloo kernel: trap number = 12 Sep 25 12:05:19 leeloo kernel: panic: page fault Sep 25 12:05:19 leeloo kernel: Sep 25 12:05:19 leeloo kernel: syncing disks... panic: bremfree: bp 0xd381a080 not locked Sep 25 12:05:19 leeloo kernel: Uptime: 2h22m51s Sep 25 12:05:19 leeloo kernel: pfs_vncache_unload(): 1 entries remaining Sep 25 12:05:19 leeloo kernel: Dumping 1535 MB Sep 25 12:05:19 leeloo kernel: ata0: resetting devicesannel.c:6Copyright (c) 1992-2002 The FreeBSD Project. leeloo# nm kernel.debug | grep c020ac c020ac70 T __setugid c020ac80 T groupmember c020acc0 T suser_cred Please let me know if I could do something to provide more details. I've a kernel.debug file around. BTW, a coredump wasn't written to the disk though there's enough space available. Is there problem with that in current -current? Marc msg43373/pgp0.pgp Description: PGP signature
evoltion makes kernel panic
Hi,
I have been working onder -current for about 4 weeks.
But for some reason evoltion seems to make my system panic
I use the 1.1.1 beta version, I can't clearly remember what
evo 1.0.8 behavior was.
I have include the last panic, i get al lot of panics that include
bremfree, and always under X.
Does anybody have a idea?
Koop
FreeBSD Crash 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Fri Sep 20 21:11:47
CEST 2002 root@Crash:/usr/obj/usr/src/sys/NUTCASE i386
This GDB was configured as i386-undermydesk-freebsd...
panic: bremfree: bp 0xc7799480 not locked
panic messages:
--
Fatal trap 12: page fault while in vm86 mode
fault virtual address = 0xc46b7
fault code = user read, page not present
instruction pointer = 0xc000:0x46b7
stack pointer = 0x0:0xfc2
frame pointer = 0x0:0x0
code segment = base 0x0, limit 0x0, type 0x0
= DPL 0, pres 0, def32 0, gran 0
processor eflags = interrupt enabled, resume, vm86, IOPL = 0
current process = 687 (XFree86)
trap number = 12
panic: page fault
syncing disks... panic: bremfree: bp 0xc7799480 not locked
Uptime: 48m15s
pfs_vncache_unload(): 1 entries remaining
Dumping 255 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
--
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:223
223 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:223
#1 0xc02216b9 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:355
#2 0xc0221903 in panic () at /usr/src/sys/kern/kern_shutdown.c:508
#3 0xc0263877 in bremfree (bp=0xc7799480) at
/usr/src/sys/kern/vfs_bio.c:634
#4 0xc02652a8 in vfs_bio_awrite (bp=0x3) at
/usr/src/sys/kern/vfs_bio.c:1629
#5 0xc01f1775 in spec_fsync (ap=0xc0583e08)
at /usr/src/sys/fs/specfs/spec_vnops.c:406
#6 0xc01f1288 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:124
#7 0xc0309777 in ffs_sync (mp=0xc26d1800, waitfor=2, cred=0xc0ef4e80,
td=0xc03ffc40) at vnode_if.h:597
#8 0xc0276448 in sync (td=0xc03ffc40, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:130
#9 0xc02212cc in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:264
#10 0xc0221903 in panic () at /usr/src/sys/kern/kern_shutdown.c:508
#11 0xc0361c92 in trap_fatal (frame=0xc0583fa8, eva=0)
at /usr/src/sys/i386/i386/trap.c:846
#12 0xc0361972 in trap_pfault (frame=0xc0583fa8, usermode=0, eva=804535)
at /usr/src/sys/i386/i386/trap.c:760
#13 0xc036149d in trap (frame=
{tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi = 32576, tf_esi = 32576,
tf_ebp = 0, tf_isp = -1067958316, tf_ebx = 9, tf_edx = 986, tf_ecx =
64111, tf_eax = 65284, tf_trapno = 12, tf_err = 4, tf_eip = 18103, tf_cs
= 49152, tf_eflags = 72147--Type return to continue, or q return to
quit--
8, tf_esp = 4034, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:446
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: GENERIC kernel panic on boot with latest -current Septembet 11,2002 due to /usr/src/sys/kern/kern_acct.c v 1.49
On Wed, 11 Sep 2002, Nate Lawson wrote: This is being worked on. See msg thread in cvs-all, starting with: [EMAIL PROTECTED]. You can back out the change (1.49) if you need to get running. Sorry, 1.50 fixed the problem. I reverted back to kernel.old anyways which was from a previous -current build before I saw the discussion on the mailing list archives on cvs-all. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
GENERIC kernel panic on boot with latest -current Septembet 11, 2002due to /usr/src/sys/kern/kern_acct.c v 1.49
Revelent info: * $FreeBSD: src/sys/kern/kern_acct.c,v 1.49 2002/09/11 04:10:41 arr Exp $ Console output... Starting syslogd. Sep 11 12:35:51 bigbang syslogd: kernel boot file is /boot/kernel/kernel Starting named. Starting ntpdate. Turning on accounting. recursed on non-recursive lock (sleep mutex) accounting @ /usr/src/sys/kern/kern_acct.c:343 first acquired @ /usr/src/sys/kern/kern_acct.c:160 panic: recurse Debugger(panic) Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0 db trace Debugger(c0434fbc) at Debugger+0x45 panic(c0438e88,0,c690f6f0,da68cb18,c02bb3ef) at panic+0x7c witness_lock(c04e9ce0,8,c0431166,157,0) at witness_lock+0x305 _mtx_lock_flags(c04e9ce0,0,c0431166,157) at _mtx_lock_flags+0x7f acctwatch(0,c04e9ca0,0,c159e200) at acctwatch+0x1f acct(c15a16c0,da68cd14,1,1,296) at acct+0x1c9 syscall(2f,2f,2f,bfbffdd0,bfbffdd4) at syscall+0x243 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (51, FreeBSD ELF32, acct), eip = 0x280a5d17, esp = 0xbfbffd6c, ebp = 0xbfbffd88 --- db output with boot -v Starting syslogd. Sep 11 13:05:50 bigbang syslogd: kernel boot file is /boot/kernel/kernel Started named. Starting ntpdate. Turning on accounting. recursed on non-recursive lock (sleep mutex) accounting @ /usr/src/sys/kern/kern_acct.c:343 first acquired @ /usr/src/sys/kern/kern_acct.c:160 panic: recurse Debugger(panic) Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0 db Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GENERIC kernel panic on boot with latest -current Septembet 11,2002 due to /usr/src/sys/kern/kern_acct.c v 1.49
This is being worked on. See msg thread in cvs-all, starting with: [EMAIL PROTECTED]. You can back out the change (1.49) if you need to get running. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel Panic and reboots - smtpd process ?
Hi Folks, I got this kernel panic yesterday and this has happened twice in the last two days. -- /usr/src/sys/vm/uma_core.c:1332: could sleep with inp locked from /usr/src/sys/netinet/tcp_usrreq.c:1013 Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc3128634 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02a356b stack pointer = 0x10:0xd2e61aa8 frame pointer = 0x10:0xd2e61ab0 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 = 99039 (smtpd) trap number = 12 panic: page fault syncing disks... panic: bremfree: bp 0xc772704c not locked Uptime: 9h14m0s Terminate ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... -- Something already reported ? Thanks Regards Sid -- God gives us relatives; thank goodness we can chose our friends. Sid Carter FreeBSD oder Debian GNU/Linux. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel Panic and reboots - smtpd process ?
An Mon, Aug 12, 2002 at 09:35:34AM +0530, Sid Carter schreib : I got this kernel panic yesterday and this has happened twice in the last two days. -- /usr/src/sys/vm/uma_core.c:1332: could sleep with inp locked from /usr/src/sys/netinet/tcp_usrreq.c:1013 Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc3128634 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02a356b stack pointer = 0x10:0xd2e61aa8 frame pointer = 0x10:0xd2e61ab0 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 = 99039 (smtpd) trap number = 12 panic: page fault syncing disks... panic: bremfree: bp 0xc772704c not locked Uptime: 9h14m0s Terminate ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... -- Sorry. I forgot this info. uname -a FreeBSD calvin 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Aug 10 17:58:11 IST 2002 root@calvin:/usr/obj/usr/src/sys/GENERIC i386 dmesg - FreeBSD 5.0-CURRENT #0: Sat Aug 10 17:58:11 IST 2002 root@calvin:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc061a000. Preloaded elf module /boot/kernel/splash_pcx.ko at 0xc061a0a8. Preloaded elf module /boot/kernel/snd_ich.ko at 0xc061a158. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc061a204. Preloaded elf module /boot/kernel/acpi.ko at 0xc061a2b0. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 996771495 Hz CPU: Pentium III/Pentium III Xeon/Celeron (996.77-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE TIA Regards Sid -- God gives us relatives; thank goodness we can chose our friends. Sid Carter FreeBSD oder Debian GNU/Linux. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel panic on boot, acpica related?
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 Timecounters tick every 10.000 msec Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc4109ac1 stack pointer = 0x10:0xd6855ce4 frame pointer = 0x10:0xd6855d0c code segment= base0x0, limit 0xf, type 0x16 = DPL 0, pres 1, def 32, gran 1 processor eflags= interrupt enabled, resume, IOPL=0 current process = 21 (irq10:fxp0 sn0+++*) kernel: type 9 trap, code=0 Stopped at 0xc4109ac1: lcall $0xc410,0xa040c410 db trace _end (c158d300,d6855d48,c04897b1,356,0) at 9xc4109ac1 fork_exit (c02ae2c0,c158d300,d6855d48) at fork_exit+0xaf fork_trampoline () at fork_trampoline+0x1a -- Michael Nottebrock The circumstance ends uglily in the cruel result. - Babelfish msg41572/pgp0.pgp Description: PGP signature
Re: kernel panic on boot, acpica related?
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 Timecounters tick every 10.000 msec Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc4109ac1 stack pointer = 0x10:0xd6855ce4 frame pointer = 0x10:0xd6855d0c code segment = base0x0, limit 0xf, type 0x16 = DPL 0, pres 1, def 32, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 21 (irq10:fxp0 sn0+++*) kernel: type 9 trap, code=0 Stopped at0xc4109ac1: lcall $0xc410,0xa040c410 db trace _end (c158d300,d6855d48,c04897b1,356,0) at 9xc4109ac1 fork_exit (c02ae2c0,c158d300,d6855d48) at fork_exit+0xaf fork_trampoline () at fork_trampoline+0x1a Hmmm, I don't think so. How about typing unset acpi_load in loader prompt, and see if this panic disappear or still happen? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic on boot, acpica related?
Mitsuru IWASAKI wrote: 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 Timecounters tick every 10.000 msec Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc4109ac1 stack pointer = 0x10:0xd6855ce4 frame pointer = 0x10:0xd6855d0c code segment = base0x0, limit 0xf, type 0x16 = DPL 0, pres 1, def 32, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 21 (irq10:fxp0 sn0+++*) kernel: type 9 trap, code=0 Stopped at0xc4109ac1: lcall $0xc410,0xa040c410 db trace _end (c158d300,d6855d48,c04897b1,356,0) at 9xc4109ac1 fork_exit (c02ae2c0,c158d300,d6855d48) at fork_exit+0xaf fork_trampoline () at fork_trampoline+0x1a Hmmm, I don't think so. How about typing unset acpi_load in loader prompt, and see if this panic disappear or still happen? Hm, right, doesn't go away, slightly different panic now ... Fatal trap 1, but basically same spot. Regards, -- Michael Nottebrock The circumstance ends uglily in the cruel result. - Babelfish msg41575/pgp0.pgp Description: PGP signature
Re: kernel panic on boot, acpica related?
On Thu, Aug 01, 2002 at 10:14:34PM +0900, Mitsuru IWASAKI wrote: Hmmm, I don't think so. How about typing unset acpi_load in loader prompt, and see if this panic disappear or still happen? Where is it documented what to do to stop the autoloading of acpi.ko? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic on boot, acpica related?
Terry Lambert wrote: Michael Nottebrock wrote: I tweaked my BIOS to assign a different irq (9) to the NIC and now the kernel boots and runs my old userland quite nicely. The old kernel ran perfectly well with the NIC on irq10 ... strange. None of your other postings identified the devices also on IRQ10. If I had to guess... USB? Almost everything. sym0, csa0, bktr0, atapci1, drm0 ... and USB, but since I can only change IRQs per 'pin', fxp0 still shares its IRQ with USB now. :] Regards, -- Michael Nottebrock The circumstance ends uglily in the cruel result. - Babelfish msg41610/pgp0.pgp Description: PGP signature
Re: kernel panic on boot, acpica related?
Michael Nottebrock wrote: I tweaked my BIOS to assign a different irq (9) to the NIC and now the kernel boots and runs my old userland quite nicely. The old kernel ran perfectly well with the NIC on irq10 ... strange. None of your other postings identified the devices also on IRQ10. If I had to guess... USB? Almost everything. sym0, csa0, bktr0, atapci1, drm0 ... and USB, but since I can only change IRQs per 'pin', fxp0 still shares its IRQ with USB now. :] I know it's work, but it'd probably be worthwhile to track down which device(s), when sharing the same IRQ, cause the problem, so that it can be fixed, instead of the next person having to work around it, too. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel Panic and Reboot
Hi, I dunno if this is w.r.t. the KSE thingie going on, but my machine got rebooted a while back with this error. I am presently in the old kernel. The syslog shows this Jul 2 18:32:24 calvin syslogd: kernel boot file is /boot/kernel.old/kernel Jul 2 18:32:24 calvin kernel: /var: bad dir ino 18826 at offset 44: mangled entry Jul 2 18:32:24 calvin kernel: panic: ufs_dirbad: bad dir Jul 2 18:32:24 calvin kernel: Jul 2 18:32:24 calvin kernel: syncing disks... panic: bremfree: bp 0xc76b3530 n ot locked Jul 2 18:32:24 calvin kernel: Uptime: 20h16m59s Jul 2 18:32:24 calvin kernel: Terminate ACPI Jul 2 18:32:24 calvin kernel: Automatic reboot in 15 seconds uname -a FreeBSD calvin 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Jun 25 02:09:28 IST 2002 root@calvin:/usr/obj/usr/src/sys/GENERIC i386 Is this related to the KSE thingie ? Does the latest cvsup solve it ? TIA Regards Sid -- I've known him as a man, as an adolescent and as a child -- sometimes on the same day. Sid Carter FreeBSD oder Debian GNU/Linux. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
post-KSE III kernel panic
I'm not sure this is related to Julian's commit,
but the kernel sources are post-kse III commit.
I have the kernel and core file if more info
or access is needed.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
Script started on Sat Jun 29 18:36:22 2002
GNU gdb 5.2.0 (FreeBSD) 20020627
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...
IdlePTD at physical address 0x00474000
initial pcb at physical address 0x0030d5e0
panicstr: bremfree: bp 0xc42aa170 not locked
panic messages:
---
panic: blockable sleep lock (sleep mutex) process lock @
/usr/src/sys/i386/i386/trap.c:726
syncing disks... panic: bremfree: bp 0xc42aa170 not locked
Uptime: 3h48m12s
pfs_vncache_unload(): 3 entries remaining
Dumping 128 MB
16 32 48 64 80 96 112
---
#0 0xc019e78b in doadump ()
(kgdb) bt
#0 0xc019e78b in doadump ()
#1 0xc019ecf0 in boot (howto=260)
#2 0xc019eefb in panic ()
#3 0xc01deb47 in bremfree (bp=0xc42aa170)
#4 0xc01e0906 in vfs_bio_awrite (bp=0xc42aa170)
#5 0xc016f065 in spec_fsync (ap=0xcc2486ec)
#6 0xc016eb58 in spec_vnoperate (ap=0xcc2486ec)
at /usr/src/sys/fs/specfs/spec_vnops.c:837
#7 0xc02354c6 in ffs_sync (mp=0xc0e41400, waitfor=2, cred=0xc0e3c380,
td=0xc02db2c0)
#8 0xc01f0c94 in sync (td=0xc02db2c0, uap=0x0)
#9 0xc019e88f in boot (howto=256)
#10 0xc019eefb in panic ()
#11 0xc01beb57 in witness_lock (lock=0xc1ea8958, flags=8,
file=0xc02c9e49 /usr/src/sys/i386/i386/trap.c, line=726)
#12 0xc0194ef3 in _mtx_lock_flags (m=0xc1ea8958, opts=0,
file=0xc02c9e49 /usr/src/sys/i386/i386/trap.c, line=726)
#13 0xc0284f43 in trap_pfault (frame=0xcc24887c, usermode=0, eva=172)
#14 0xc0284ba3 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1043814600, tf_esi = 0, tf_ebp =
-870020888, tf_isp = -870020952, tf_ebx = -870020860, tf_edx = -870716816, tf_ecx = 0,
tf_eax = -1043814600, tf_trapno = 12, tf_err = 0, tf_eip = -1072069444, tf_cs = 8,
tf_eflags = 66054, tf_esp = -1070728192, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:667
---Type return to continue, or q return to quit---
#15 0xc01984bc in fill_kinfo_proc (p=0xc1c8a738, kp=0xcc248904)
#16 0xc0198a5c in sysctl_out_proc (p=0xc1c8a738, req=0xcc248c10, doingzomb=1)
#17 0xc0198f1e in sysctl_kern_proc (oidp=0xc02e0100, arg1=0x0, arg2=0,
req=0xcc248c10)
#18 0xc01a7f93 in sysctl_root (oidp=0x0, arg1=0xcc248cac, arg2=3,
req=0xcc248c10)
#19 0xc01a820d in userland_sysctl (td=0xc1c77000, name=0xcc248cac, namelen=3,
old=0x0, oldlenp=0xbfbff34c, inkernel=0, new=0x0, newlen=0,
retval=0xcc248ca8)
#20 0xc01a8060 in __sysctl (td=0xc1c77000, uap=0xcc248d14)
#21 0xc02856ba in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = -1077939380, tf_ebp =
-1077939432, tf_isp = -870019724, tf_ebx = 672654268, tf_edx = -1077939328, tf_ecx =
3, tf_eax = 202, tf_trapno = 12, tf_err = 2, tf_eip = 672221579, tf_cs = 31, tf_eflags
= 663, tf_esp = -1077939476, tf_ss = 47})
#22 0xc027691d in syscall_with_err_pushed () at {standard input}:128
#23 0x280d2451 in ?? ()
#24 0x0804b83e in ?? ()
#25 0x0804d346 in ?? ()
#26 0x080492f9 in ?? ()
(kgdb) quit
Script done on Sat Jun 29 18:36:44 2002
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: post-KSE III kernel panic
it definitly looks like one for me
if you have the core file, can you find the line in fill_kinfo_proc
that exploded?
up 15
list
should do
I think I saw this once myself but wasn't able to reproduce it again.
On Sat, 29 Jun 2002, Steven G. Kargl wrote:
I'm not sure this is related to Julian's commit,
but the kernel sources are post-kse III commit.
I have the kernel and core file if more info
or access is needed.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
Script started on Sat Jun 29 18:36:22 2002
GNU gdb 5.2.0 (FreeBSD) 20020627
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...
IdlePTD at physical address 0x00474000
initial pcb at physical address 0x0030d5e0
panicstr: bremfree: bp 0xc42aa170 not locked
panic messages:
---
panic: blockable sleep lock (sleep mutex) process lock @
/usr/src/sys/i386/i386/trap.c:726
syncing disks... panic: bremfree: bp 0xc42aa170 not locked
Uptime: 3h48m12s
pfs_vncache_unload(): 3 entries remaining
Dumping 128 MB
16 32 48 64 80 96 112
---
#0 0xc019e78b in doadump ()
(kgdb) bt
#0 0xc019e78b in doadump ()
#1 0xc019ecf0 in boot (howto=260)
#2 0xc019eefb in panic ()
#3 0xc01deb47 in bremfree (bp=0xc42aa170)
#4 0xc01e0906 in vfs_bio_awrite (bp=0xc42aa170)
#5 0xc016f065 in spec_fsync (ap=0xcc2486ec)
#6 0xc016eb58 in spec_vnoperate (ap=0xcc2486ec)
at /usr/src/sys/fs/specfs/spec_vnops.c:837
#7 0xc02354c6 in ffs_sync (mp=0xc0e41400, waitfor=2, cred=0xc0e3c380,
td=0xc02db2c0)
#8 0xc01f0c94 in sync (td=0xc02db2c0, uap=0x0)
#9 0xc019e88f in boot (howto=256)
#10 0xc019eefb in panic ()
#11 0xc01beb57 in witness_lock (lock=0xc1ea8958, flags=8,
file=0xc02c9e49 /usr/src/sys/i386/i386/trap.c, line=726)
#12 0xc0194ef3 in _mtx_lock_flags (m=0xc1ea8958, opts=0,
file=0xc02c9e49 /usr/src/sys/i386/i386/trap.c, line=726)
#13 0xc0284f43 in trap_pfault (frame=0xcc24887c, usermode=0, eva=172)
#14 0xc0284ba3 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1043814600, tf_esi = 0, tf_ebp
= -870020888, tf_isp = -870020952, tf_ebx = -870020860, tf_edx = -870716816, tf_ecx =
0, tf_eax = -1043814600, tf_trapno = 12, tf_err = 0, tf_eip = -1072069444, tf_cs = 8,
tf_eflags = 66054, tf_esp = -1070728192, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:667
---Type return to continue, or q return to quit---
#15 0xc01984bc in fill_kinfo_proc (p=0xc1c8a738, kp=0xcc248904)
#16 0xc0198a5c in sysctl_out_proc (p=0xc1c8a738, req=0xcc248c10, doingzomb=1)
#17 0xc0198f1e in sysctl_kern_proc (oidp=0xc02e0100, arg1=0x0, arg2=0,
req=0xcc248c10)
#18 0xc01a7f93 in sysctl_root (oidp=0x0, arg1=0xcc248cac, arg2=3,
req=0xcc248c10)
#19 0xc01a820d in userland_sysctl (td=0xc1c77000, name=0xcc248cac, namelen=3,
old=0x0, oldlenp=0xbfbff34c, inkernel=0, new=0x0, newlen=0,
retval=0xcc248ca8)
#20 0xc01a8060 in __sysctl (td=0xc1c77000, uap=0xcc248d14)
#21 0xc02856ba in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = -1077939380, tf_ebp
= -1077939432, tf_isp = -870019724, tf_ebx = 672654268, tf_edx = -1077939328, tf_ecx
= 3, tf_eax = 202, tf_trapno = 12, tf_err = 2, tf_eip = 672221579, tf_cs = 31,
tf_eflags = 663, tf_esp = -1077939476, tf_ss = 47})
#22 0xc027691d in syscall_with_err_pushed () at {standard input}:128
#23 0x280d2451 in ?? ()
#24 0x0804b83e in ?? ()
#25 0x0804d346 in ?? ()
#26 0x080492f9 in ?? ()
(kgdb) quit
Script done on Sat Jun 29 18:36:44 2002
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Kernel Panic and Automagic Reboots
An Tue, Jun 11, 2002 at 09:13:44AM -0700, Edwin Culp schreib : Quoting Sid Carter [EMAIL PROTECTED]: | FreeBSD calvin 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Jun 10 13:55:43 IST | 2002 root@calvin:/usr/obj/usr/src/sys/GENERIC i386 Hi guys, Another reboot. This seems to happen when I have mozilla running or I am just being paranoid Anyway, here are the messages Jun 25 17:45:35 calvin kernel: /usr/src/sys/vm/uma_core.c:1331: could sleep with inp locked from /usr/src/sys/netinet/tcp_usrreq.c:1013 Jun 25 17:52:14 calvin syslogd: kernel boot file is /boot/kernel/kernel Jun 25 17:52:14 calvin kernel: Memory modified after free 0xc2bb6c00(252) Jun 25 17:52:14 calvin kernel: panic: Most recently used by file desc Jun 25 17:52:14 calvin kernel: Jun 25 17:52:14 calvin kernel: Jun 25 17:52:14 calvin kernel: syncing disks... panic: bremfree: bp 0xc7667c20 n ot locked Jun 25 17:52:14 calvin kernel: Uptime: 7h3m50s Jun 25 17:52:14 calvin kernel: pfs_vncache_unload(): 1 entries remaining Jun 25 17:52:14 calvin kernel: Terminate ACPI Jun 25 17:52:14 calvin kernel: Automatic reboot in 15 seconds - press a key on the console to abort Jun 25 17:52:14 calvin kernel: Rebooting... This has happened like.7 or 8 times in the past or probably more. No solution yet ? Regards Sid -- I've known him as a man, as an adolescent and as a child -- sometimes on the same day. Sid Carter FreeBSD oder Debian GNU/Linux. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel panic with suser_cred and rm
Hello everybody, I upgraded to today's -CURRENT and upon reboot with the new kernel, experienced a panic. Since I did not see it reported here yet, here is some info. More available on request, but I do not have a serial console and therefore had to transcribe everything by hand. Also, there was no core dump. (How can I force it?) Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02054bc stack pointer = 0x10:0xceb1db5c frame pointer = 0x10:0xceb1db60 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 = 48 (rm) kernel: type 12 trap, code= 0 Stopped at suser_cred+0x1c:cmpl $0,0x4(%edx) db trace suser_cred chkiq ufs_inactive ufs_vnoperate vput unlink syscall syscall_with_err_pushed --- syscall (10, FreeBSD ELF, unlink) eip = 0x804af7b, esp = 0xbfbffc7c ebp = 0xbfbffd08 db show locks exclusive sleep mutex Giant r= 0 (0xc03ed260) locked @ ../../../vm/vm_fault.c:202 FreeBSD fonix.adamsfamily.xx 5.0-CURRENT FreeBSD 5.0-CURRENT #46: Sat Jun 15 17:57:46 CEST 2002 [EMAIL PROTECTED]:/usr/home/cc/build/freebsd/src/sys/i386/compile/FONIX i386 dmesg is not available from the failing kernel, but the only could sleep with... messages came from the soundcard driver. The panic happens also in single-user mode, in my case most easily triggered with the use of rm(1). If you need any more info, just ask. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Current kernel panic
I get this with a current kernel compiled just a few minute ago (SMP) Can't get to debugger as keystyrokes don't work Kernel from the 19th before UFS2 works fine. Additional routing options:. Mounting NFS file systems:. Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0c00 fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01d4e39 stack pointer = 0x10:0xd19a7b8c frame pointer = 0x10:0xd19a7b8c 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 = 233 (rm) trap number = 12 panic: page fault cpuid = 1; lapic.id = 0c00 boot() called on cpu#1 syncing disks... panic: bdwrite: buffer is not busy cpuid = 1; lapic.id = 0c00 boot() called on cpu#1 Uptime: 13s pfs_vncache_unload(): 1 entries remaining Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset called on cpu#1 cpu_reset: Stopping other CPUs cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 1 == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel Panic and Automagic Reboots
Hi, Today my system rebooted twice automagically. This is what the message log shows. -- Jun 11 19:00:00 calvin kernel: /usr/src/sys/vm/uma_core.c:1327: could sleep with process lock locked from /usr/src/sys/kern/kern_prot.c:511 Jun 11 19:00:00 calvin kernel: /usr/src/sys/vm/uma_core.c:1327: could sleep with process lock locked from /usr/src/sys/kern/kern_prot.c:613 Jun 11 19:02:20 calvin kernel: Memory modified after free 0xd33f5900(252) Jun 11 19:02:20 calvin kernel: panic: Most recently used by kqueue Jun 11 19:02:20 calvin kernel: Jun 11 19:02:20 calvin kernel: Jun 11 19:02:20 calvin kernel: syncing disks... panic: bremfree: bp 0xc76431a0 n ot locked Jun 11 19:02:20 calvin kernel: Uptime: 6h1m9s Jun 11 19:02:20 calvin kernel: pfs_vncache_unload(): 1 entries remaining Jun 11 19:02:20 calvin kernel: Terminate ACPI Jun 11 19:02:20 calvin kernel: Automatic reboot in 15 seconds - press a key on t he console to abort Jun 11 19:02:20 calvin kernel: -- Press a key on the console to reboot, Jun 11 19:02:20 calvin kernel: -- or switch off the system now. Jun 11 19:02:20 calvin kernel: Rebooting... -- This has happened twice and more info about the compiled kernel is -- FreeBSD calvin 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Jun 10 13:55:43 IST 2002 root@calvin:/usr/obj/usr/src/sys/GENERIC i386 Jun 11 19:02:20 calvin kernel: Timecounter i8254 frequency 1193182 Hz Jun 11 19:02:20 calvin kernel: Timecounter TSC frequency 996769599 Hz Jun 11 19:02:20 calvin kernel: CPU: Pentium III/Pentium III Xeon/Celeron (996.77 -MHz 686-class CPU) Jun 11 19:02:20 calvin kernel: Origin = GenuineIntel Id = 0x68a Stepping = 1 0 Jun 11 19:02:20 calvin kernel: Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE ,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE Jun 11 19:02:20 calvin kernel: real memory = 267255808 (260992K bytes) Jun 11 19:02:20 calvin kernel: avail memory = 253108224 (247176K bytes) -- Has anyone else encountered this ? Something wrong with my machine ? TIA Regards Sid -- I've known him as a man, as an adolescent and as a child -- sometimes on the same day. Sid Carter FreeBSD oder Debian GNU/Linux. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel Panic and Automagic Reboots
Quoting Sid Carter [EMAIL PROTECTED]: | Hi, | | Today my system rebooted twice automagically. This is what the message | log shows. | | -- | Jun 11 19:00:00 calvin kernel: /usr/src/sys/vm/uma_core.c:1327: could sleep | with | process lock locked from /usr/src/sys/kern/kern_prot.c:511 | Jun 11 19:00:00 calvin kernel: /usr/src/sys/vm/uma_core.c:1327: could sleep | with | process lock locked from /usr/src/sys/kern/kern_prot.c:613 | Jun 11 19:02:20 calvin kernel: Memory modified after free | 0xd33f5900(252) | Jun 11 19:02:20 calvin kernel: panic: Most recently used by kqueue | Jun 11 19:02:20 calvin kernel: | Jun 11 19:02:20 calvin kernel: | Jun 11 19:02:20 calvin kernel: syncing disks... panic: bremfree: bp | 0xc76431a0 n | ot locked | Jun 11 19:02:20 calvin kernel: Uptime: 6h1m9s | Jun 11 19:02:20 calvin kernel: pfs_vncache_unload(): 1 entries remaining | Jun 11 19:02:20 calvin kernel: Terminate ACPI | Jun 11 19:02:20 calvin kernel: Automatic reboot in 15 seconds - press a | key on t | he console to abort | Jun 11 19:02:20 calvin kernel: -- Press a key on the console to reboot, | Jun 11 19:02:20 calvin kernel: -- or switch off the system now. | Jun 11 19:02:20 calvin kernel: Rebooting... | -- | | This has happened twice and more info about the compiled kernel is | | -- | FreeBSD calvin 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Jun 10 13:55:43 IST | 2002 root@calvin:/usr/obj/usr/src/sys/GENERIC i386 | | Jun 11 19:02:20 calvin kernel: Timecounter i8254 frequency 1193182 Hz | Jun 11 19:02:20 calvin kernel: Timecounter TSC frequency 996769599 Hz | Jun 11 19:02:20 calvin kernel: CPU: Pentium III/Pentium III Xeon/Celeron | (996.77 | -MHz 686-class CPU) | Jun 11 19:02:20 calvin kernel: Origin = GenuineIntel Id = 0x68a | Stepping = 1 | 0 | Jun 11 19:02:20 calvin kernel: | Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE | ,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE | Jun 11 19:02:20 calvin kernel: real memory = 267255808 (260992K bytes) | Jun 11 19:02:20 calvin kernel: avail memory = 253108224 (247176K bytes) | -- | | Has anyone else encountered this ? Something wrong with my machine ? | My laptop is rebooting with todays current/kernel in ifconfig. I just got it up with an old kernel and am checking now. It will run with the new kernel if I don't try to configure the network. I may have something wrong though. ed To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel Panic and Automagic Reboots
On Tue, Jun 11, 2002 at 09:13:44AM -0700, Edwin Culp wrote: My laptop is rebooting with todays current/kernel in ifconfig. I just got it up with an old kernel and am checking now. It will run with the new kernel if I don't try to configure the network. I may have something wrong though. Same thing happens to me, reboot during the startup process when ifoncfig tries to get iself an IP from the dhcp server. I didn't have the time to write down the entire thing, but I'll try to get to it tonight. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel panic in 5.0-20020302-PREVIEW with drm-kmod
Hi, I have a problem with DRM, I have ATI Xpert2000 AGP card, in 4.5-RELEASE I used r128.ko , and all was fine, in current my kernel hangs up saying: malloc type lacks magic number. I have compiled the kernel with 'device agp' so what can be wrong? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel panic after mount_ext2fs
This is a new problem beginning after a buildworld and build kernel yesterday, May 08 (still the old gcc 2.95.4): The system is quite stable until I mount an ext2 partition and attempt to list its directory. Immediately I get this error: syncing disks... panic: bdwrite: buffer is not busy. If I do a 'sync' first before listing the directory the error message changes to this: fatal trap 12: page fault while in kernel mode fault virtual address 0x18 fault code supervisor write, page not present Same thing happens even if the ext2fs is mounted read-only. Any other info I can supply that might be useful? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PPPoE using aue ethernet goes kernel panic
Following are observed with 5-current kernel as of Apr/25/2002. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x6 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01898d1 stack pointer = 0x10:0xc9476b24 frame pointer = 0x10:0xc9476b40 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 = 136 (ppp) trap number = 12 panic: page fault I'm subscribing NTT's ADSL line, and using 'aue' USB ethernet for PPPoE device. The kernel boots fine, detecting my aue0, but while /etc/rc is running, kernel panics. I must provide more detailed information, but here's quick report. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PPPoE using aue ethernet goes kernel panic
matusita I must provide more detailed information, but here's quick report. Using trace command, this panic is caused by: usbd_open_pipe_ival(c40416e0, 1, c8148858, ) at usbd_open_pipe_ival+0x1d usbd_open_pipe(c40416e0, 81, 1, c8148858, c40769c0, c8148880, 2, 1, c8148880, 2) at usbd_open_pipe+0x1a aue_init(...) (this is by hand copy, so it may have some typos). -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ntfs causing kernel panic
Has anyone seen mounting an NTFS drive casing a kernel panic? I'd love to give the output, but I'm not sure how to redirect the output into a file so I can post it here. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntfs causing kernel panic
On Tue, Mar 26, 2002 at 10:08:20AM +1030, Greg 'groggy' Lehey wrote: On Monday, 25 March 2002 at 9:41:09 -0600, David W. Chapman Jr. wrote: Has anyone seen mounting an NTFS drive casing a kernel panic? I'd love to give the output, but I'm not sure how to redirect the output into a file so I can post it here. You need to take a dump and analyse it. There's some stuff in the handbook about how to do it. Unfortunately it has been fixed, but I am still planning on looking at the handbook, thanks! -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntfs causing kernel panic
On Monday, 25 March 2002 at 9:41:09 -0600, David W. Chapman Jr. wrote: Has anyone seen mounting an NTFS drive casing a kernel panic? I'd love to give the output, but I'm not sure how to redirect the output into a file so I can post it here. You need to take a dump and analyse it. There's some stuff in the handbook about how to do it. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntfs causing kernel panic
It could be this problem is a result of the loadable VFS module bug hacked/fixed in the tree this morning. Was the NTFS driver being loaded as a module, or compiled into the kernel? If a loadable module, could you try compiling it into the kernel, or updating past the fix? If already compiled in, follow the directions grog pointed at to generate useful debugging output. Ideally, a copy of the full panic message, stack trace, and information on what kernel options you linked with so that the symbol offsets are useful. The recent vfs fix has fixed it, but thanks for the tips on what information to provide. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
VAIO install, sn0 kernel panic, workaround
Having determined that the last bootable install image was 20020311, I have network booted my Sony VAIO PCG-SRX7E/P using pxeboot and the contents of the boot.flp image on an NFS mount. If the boot process is allowed to progress without interruption, the kernel panics: [...] vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources (port) unknown: PNP0c02 can't assign resources (memory) psmcpnp0: irq resource info is missing: assuming irq 12 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x6d256d24 fault code = supervisor write, page not present instruction pointer = 0x8:0xc164cf00 stack pointer = 0x10:0xcb92cd00 frame pointer = 0x10:0xcb92cd1c 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 = 27 (irq10: sn0) trap number = 12 panic: page fault syncing disks... done Uptime: 0s Automatic reboot in 15 seconds - press a key on the console to abort -- Press a key on the console to reboot. -- or switch off the system now. * Setting 'OK set boot_verbose' indicates that Device configuration finished. bpf: lo0 attached * Setting 'OK set hint.sn.0.disabled=1' resolves the issue and allows the machine to boot into the installer, and complete installation. On reboot, the classic symptoms of pcic unhappiness appear -- the boot process freezes after ad0: is recognized. As in the past, Werner Losh's recommended OK set hw.pcic.intr_path=1 OK set hw.pcic.irq=0 OK boot resolves the issue. (Stay calm, there is a pause while the Memory Stick times-out with the typical 15s SCSI delay.) Now to the psm0 problem... Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VAIO install, sn0 kernel panic, workaround
In message: [EMAIL PROTECTED] Jeff Kletsky [EMAIL PROTECTED] writes: : As in the past, Werner Losh's recommended : OK set hw.pcic.intr_path=1 : OK set hw.pcic.irq=0 : OK boot You might try current after March 16th to see if this is still needed. I just fixed what I think was a problem related to this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel panic... (was Re: Netatalk broken in current? Lock order reversal?)
* Emiel Kollof ([EMAIL PROTECTED]) wrote: exclusive (sleep mutex) Giant (0xc0462c00) locked @ /usr/src/sys/i386/i386/trap.c:1102 panic: system call pwrite returning with mutex(s) held Hmm, erm, go kick Alfred really hard. :) This function locks Giant and then doesn't ever unlock it. This looks to be breakage from his fget() changes perhaps. Alfred? Are you listening? Are you tending to this already? It's not only Samba that makes my machine panic. Also icecast does (when you start to stream to it). Oh, has anyone else seen these panics as well? Just wondering... Cheers, Emiel -- Never let your schooling interfere with your education. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic... (was Re: Netatalk broken in current? Lock order reversal?)
* Emiel Kollof [EMAIL PROTECTED] [020116 13:29] wrote: * Emiel Kollof ([EMAIL PROTECTED]) wrote: exclusive (sleep mutex) Giant (0xc0462c00) locked @ /usr/src/sys/i386/i386/trap.c:1102 panic: system call pwrite returning with mutex(s) held Hmm, erm, go kick Alfred really hard. :) This function locks Giant and then doesn't ever unlock it. This looks to be breakage from his fget() changes perhaps. Alfred? Are you listening? Are you tending to this already? It's not only Samba that makes my machine panic. Also icecast does (when you start to stream to it). Oh, has anyone else seen these panics as well? Just wondering... It would help if someone cc'd me on these. :P -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic... (was Re: Netatalk broken in current? Lock order reversal?)
* Alfred Perlstein [EMAIL PROTECTED] [020116 13:30] wrote: * Emiel Kollof [EMAIL PROTECTED] [020116 13:29] wrote: * Emiel Kollof ([EMAIL PROTECTED]) wrote: exclusive (sleep mutex) Giant (0xc0462c00) locked @ /usr/src/sys/i386/i386/trap.c:1102 panic: system call pwrite returning with mutex(s) held Hmm, erm, go kick Alfred really hard. :) This function locks Giant and then doesn't ever unlock it. This looks to be breakage from his fget() changes perhaps. Alfred? Are you listening? Are you tending to this already? It's not only Samba that makes my machine panic. Also icecast does (when you start to stream to it). Oh, has anyone else seen these panics as well? Just wondering... It would help if someone cc'd me on these. :P Fix should be in now. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic... (was Re: Netatalk broken in current? Lock order reversal?)
* Alfred Perlstein ([EMAIL PROTECTED]) wrote: It would help if someone cc'd me on these. :P Fix should be in now. Great! Thanks! Remind me to buy you a beer if I ever get to meet you in real life :-) Right.. cvsup it is... Cheers, Emiel -- If you can survive death, you can probably survive anything. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic
On Mon, 19 Nov 2001, Bob Vaughan wrote: sources from yesterday evening. rebuild with kernel sources from tonight. same results. vt0: unknown trident VGA, 80 columns, color, 8 screens, unknown keyboard Warning: Driver mistake: repeat make_dev (ttyv0) panic: don't do that Debugger (panic stopped at debugger+0x44 pushl %ebx ... Ok.. this apparently is caused by having both sc0 and vt0 defined in the kernel config. maybe a comment in GENERIC might be in order.. This was a supported configuration. It used to be possible to switch between consoles using userconfig. When consoles use the same resources, the first one that happens the be attached should allocate the resources and the others should fail to attach when they can't allocate the resources. Things might work better if pcattach() actually checked for success of its resource allocations. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel panic
sources from yesterday evening. rebuild with kernel sources from tonight.
same results.
vt0: unknown trident VGA, 80 columns, color, 8 screens, unknown keyboard
Warning: Driver mistake: repeat make_dev (ttyv0)
panic: don't do that
Debugger (panic
stopped at debugger+0x44 pushl %ebx
trace
Debugger(c02d977b) at Debugger+0x44
panic(c02d6b10,c02d6ae0,c0354e3c,0,c12a7b80) at panic+0x70
make_dev(c03404c0,0,0,0,180,c02f9e0d,0,c0398420) at make_dev+0xfb
pcvt_attach(c12a7b80,c12a7b80,c12b2000,18,1) at pcvt_attach+0x1fe
device_probe_and_attach(c12a7b80) at device_probe_and_attach+0x9a
isa_probe_children(c1299580,c0441d98,c01bb0dc,0,43ec00) at isa_probe_children+0xf7
configure(0,43ec00,43e000,0,c012739c) at configure+0x39
mi_startup() at mi_startup+0x90
begin() at begin+0x43
--
-- Welcome My Son, Welcome To The Machine --
Bob Vaughan | techie@{w6yx|tantivy}.stanford.edu | [EMAIL PROTECTED]
| P.O. Box 19792, Stanford, Ca 94309
-- I am Me, I am only Me, And no one else is Me, What could be simpler? --
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kernel panic
Bob Vaughan [EMAIL PROTECTED] wrote: sources from yesterday evening. rebuild with kernel sources from tonight. same results. vt0: unknown trident VGA, 80 columns, color, 8 screens, unknown keyboard Warning: Driver mistake: repeat make_dev (ttyv0) Does this only happen with a recent -current? I'm a long-time pcvt user, but have never seen the warning (that it used to be). The only test machine here cannot reproduce it either. make_dev(c03404c0,0,0,0,180,c02f9e0d,0,c0398420) at make_dev+0xfb pcvt_attach(c12a7b80,c12a7b80,c12b2000,18,1) at pcvt_attach+0x1fe Quick review shows that pcvt_attach() is the only pcvt function that ever would call make_dev(). It is not supposed to be called twice... Do you incidentally have both gfx console drivers (sc0 and vt0) in your configuration? That would perhaps explain it. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
