spontaneous reboots on 8.2-PRERELEASE
Hi list, I've installed PC-BSD 8.2-BETA1 aka FreeBSD 8.2-PRERELEASE on a machine that was running FreeBSD 7.3 rock solid and now I get random reboots of the machine, mostly when under the load. ACPI/no ACPI makes no difference and unfortunately, I'm unable to get reliable thermal readings (apci_thermal doesn't get loaded and healthd tends to give some bogus occasionaly, thus not very reliable source either). Sometimes, I also get some USB-related errors like this: usbus4: port reset timeout usbd_req_re_enumerate: addr=3, port reset failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=3, port reset failed, USB_ERR_TIMEOUT ugen4.3: Unknown at usbus4 (disconnected) uhub_reattach_port: could not allocate new device ugen4.3: Unknown at usbus4 (disconnected) uhub_reattach_port: could not allocate new device ugen4.3: Unknown at usbus4 (disconnected) uhub_reattach_port: could not allocate new device usbus4: port reset timeout usbd_req_re_enumerate: addr=3, port reset failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=3, port reset failed, USB_ERR_TIMEOUT and Root mount waiting for: usbus4 dumpdev=AUTO and getting nothing in /var/crash, just plain reboots. Any clues how to debug this_ Dmesg is below. Thanks, Petr --- Copyright (c) 1992-2010 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-PRERELEASE #3: Mon Dec 13 08:50:49 PST 2010 r...@build8x32.pcbsd.org:/usr/obj/usr/local_storage/pcbsd-build82/fbsd-source/8.2/sys/PCBSD i386 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.40GHz (3412.09-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf43 Family = f Model = 4 Stepping = 3 Features=0xbfebfbffFPU,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,PBE Features2=0x649dSSE3,DTES64,MON,DS_CPL,EST,CNXT-ID,CX16,xTPR AMD Features=0x2000LM TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 1018896384 (971 MB) MPTable: INTEL ioapic0: Assuming intbase of 0 ioapic1: Assuming intbase of 24 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard Cuse4BSD v0.1.13 @ /dev/cuse kbd1 at kbdmux0 cryptosoft0: software crypto on motherboard pcib0: MPTable Host-PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: MPTable PCI-PCI bridge irq 16 at device 1.0 on pci0 pci6: PCI bus on pcib1 vgapci0: VGA-compatible display port 0xcc00-0xcc7f mem 0xfd00-0xfdff,0xd000-0xdfff,0xfc00-0xfcff irq 16 at device 0.0 on pci6 nvidia0: GeForce 7900 GT/GTO on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [ITHREAD] pci0: multimedia, HDA at device 27.0 (no driver attached) pcib2: PCI-PCI bridge irq 16 at device 28.0 on pci0 pci4: PCI bus on pcib2 pcib3: MPTable PCI-PCI bridge at device 0.0 on pci4 pci5: PCI bus on pcib3 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.3 port 0xbc00-0xbc3f mem 0xfa9e-0xfa9f,0xfa98-0xfa9b irq 24 at device 1.0 on pci5 em0: [FILTER] em0: Ethernet address: 00:04:23:c3:90:83 pcib4: MPTable PCI-PCI bridge irq 16 at device 28.4 on pci0 pci3: PCI bus on pcib4 mskc0: Marvell Yukon 88E8062CU Gigabit Ethernet port 0xa800-0xa8ff mem 0xfa7fc000-0xfa7f irq 16 at device 0.0 on pci3 msk0: Marvell Technology Group Ltd. Yukon XL Id 0xb3 Rev 0x01 on mskc0 msk0: Ethernet address: 00:15:f2:eb:7d:f4 miibus0: MII bus on msk0 e1000phy0: Marvell 88E1112 Gigabit PHY PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow msk1: Marvell Technology Group Ltd. Yukon XL Id 0xb3 Rev 0x01 on mskc0 msk1: Ethernet address: 00:15:f2:eb:7d:f5 miibus1: MII bus on msk1 e1000phy1: Marvell 88E1112 Gigabit PHY PHY 0 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto mskc0: [ITHREAD] pcib5: MPTable PCI-PCI bridge irq 17 at device 28.5 on pci0 pci2: PCI bus on pcib5 atapci0: Marvell 88SX6141 UDMA133 controller port 0x9c00-0x9c07,0x9880-0x9883,0x9800-0x983f,0x9480-0x949f mem 0xfa6ffc00-0xfa6f irq 17 at device 0.0 on pci2 atapci0: [ITHREAD] ahci0: Marvell 88SX6141 AHCI SATA controller on atapci0 ahci0: [ITHREAD] ahci0: AHCI v1.00 with 4 3Gbps ports, Port Multiplier supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: AHCI channel at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: AHCI channel at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: AHCI channel at channel 3 on ahci0 ahcich3: [ITHREAD] ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] uhci0: Intel 82801G (ICH7) USB controller USB-A port
RE: update on kern/145064?
Dear stable list, is there any update on bug hunting of the issue described here? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/145064 I've attempted to install PC BSD 8.1-RC1 on my desktop and I'm facing the same problem with the Marvell SATA driver. Therefore, PC BSD is not installable on my machine as it deterministically panics on boot. The same machine runs FreeBSD 7.3 just fine. FYI, Alexander Motin provided me with a patch on ata-pci.c that makes 8.1-PRERELEASE boot OK on my machine. The patch is available on the PR page: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/145064 Would it be possible to include this patch into the 8.1-RELEASE and PCBSD 8.1-RELEASE? Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
update on kern/145064?
Dear stable list, is there any update on bug hunting of the issue described here? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/145064 I've attempted to install PC BSD 8.1-RC1 on my desktop and I'm facing the same problem with the Marvell SATA driver. Therefore, PC BSD is not installable on my machine as it deterministically panics on boot. The same machine runs FreeBSD 7.3 just fine. Thanks, Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
7.2-RELEASE kernel panic on Atheros card insert on T61p
Hi all, I'm getting deterministic kernel panics on Lenovo T61p laptop when inserting Athreos-based wifi card. Details are given below. Let me know if you need something more to debug the panic. Thanks, Petr GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd... Unread portion of the kernel message buffer: cardbus0: Expecting link target, got 0x0 ath0: Atheros 5212 mem 0xbfeb-0xbfeb irq 16 at device 0.0 on cardbus0 ath0: [ITHREAD] Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xc6b919fc frame pointer = 0x28:0xc6b91a10 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 = 40 (cbb0 event thread) trap number = 12 panic: page fault cpuid = 0 Uptime: 40s Physical memory: 3050 MB Dumping 104 MB: 89 73 57 41 25 9 Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/ntfs.ko...Reading symbols from /boot/kernel/ntfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/ntfs.ko #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07e25a7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e2879 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0ae3ebc in trap_fatal (frame=0xc6b919bc, eva=0) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0ae4140 in trap_pfault (frame=0xc6b919bc, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0ae4aec in trap (frame=0xc6b919bc) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0ac91fb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0x in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) info threads 78 Thread 100104 (PID=912: getty) sched_switch (td=0xc73cb690, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 77 Thread 100101 (PID=901: getty) sched_switch (td=0xc73cbd20, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 76 Thread 100100 (PID=900: getty) sched_switch (td=0xc7666000, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 75 Thread 100099 (PID=899: getty) sched_switch (td=0xc7666230, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 74 Thread 100098 (PID=898: getty) sched_switch (td=0xc7666460, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 73 Thread 100097 (PID=897: getty) sched_switch (td=0xc790, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 72 Thread 100096 (PID=896: getty) sched_switch (td=0xc76668c0, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 71 Thread 100095 (PID=895: getty) sched_switch (td=0xc7666af0, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 70 Thread 100092 (PID=892: sleep) sched_switch (td=0xc7667230, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 69 Thread 100091 (PID=891: sh) sched_switch (td=0xc7667460, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 68 Thread 100063 (PID=890: logger) sched_switch (td=0xc7233230, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 67 Thread 100087 (PID=889: sh) sched_switch (td=0xc73c9690, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 66
RE: panics on 6.3-RELEASE in IP stack
Yes, there's an off-by-one reference count bug in the multicast stuff. You need 1.85.2.10 of sys/netinet/in.c: I can confirm that RAT can be restarted many times now with this patch applied (at least when RAT doesn't touch audio devices as I may be also reporting some sound related panic soon ;-) ). I'd also propose to release errata on this. Thanks Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panics in 6.3-RELEASE in sound system
Hi all,
this time I'm reporting panics in sound system :). I'm having
M-Audio Audiophile 192 sound card which got supported with the
new revision of sound system, so I have
sound
snd_envy24ht
The panic is reproducible when I start kcontrol (from fluxbox),
try to enable and configure soundsystem and then push the Test
button. I get the following crash (hand retyped DDB part as the
machine doesn't have serial port and I can't do it over firewire
as of now):
Sleeping thread (tid 100112, pid 1391) owns a non-sleepable lock
sched_switch(c5619300,0,1) at sched_switch+0x14b
mi_switch(1,0,c5468400,e62fca44,c06cac56,...) at mi_switch+0x1ba
sleepq_switch(c5468400) at sleepq_switch+0x86
sleepq_timedwait_sig(c5468400) at sleepq_timedwait_sig+0x1e
msleep(c5468400,c544e940,14c,c0bf2307,64,...) at msleep+0x200
chn_sleep(64,c5468400,a000,a,c5450980,...) at chn_sleep+0x17
chn_flush(c5450080,c5450080,,c544e940,0,...) at chn_flush+0xb3
dsp_close(c5467600,7,2000,c5619300) at dsp_close+0xc4
giant_close(c5467600,7,2000,c5619300,c071289c,...) at giant_close+0x4b
devfs_close(e62fcb70) at devfs_close+0x402
VOP_CLOSE_APV(c0a096e0,e62fcb70) at VOP_CLOSE_APV+0x38
vn_close(c5d7bdd0,7,c5946780,c5619300) at vn_close+0x5a
vn_closefile(c6421900,c5619300,e62fcc28,c0689fe0,c6421900,...) at
vn_closefile+0
xea
devfs_close_f(c6421900,c5619300) at devfs_close_f+0xf
fdrop_locked(c6421900,c5619300,c64c5000,e62fcca8,c0688537,...) at
fdrop_locked+0
xd0
fdrop(c6421900,c5619300,c6421900,e62fcc70,0,...) at fdrop+0x41
closef(c6421900,c5619300,0,e62fcd38,c6134a78,...) at closef+0x41f
kern_close(c5619300,b,e62fcd30,c0918033,c5619300,...) at kern_close+0x20b
close(c5619300,e62fcd04) at close+0x10
syscall(2891003b,285f003b,bfbf003b,807f000,8082d80,...) at syscall+0x2b7
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (6, FreeBSD ELF32, close), eip = 0x288f5a23, esp = 0xbfbfe4fc,
ebp =
0xbfbfe528 ---
panic: sleeping thread
KDB: enter: panic
dbbt
Tracing pid 31 tid 100035 td 0xc52b0480
kdb_enter(...) at kdb_enter+0x2b
panic(...) at panic+0xbb
propagate_priority(...) at propagate_priority0x54
turnstile_wait(...) at turnstile_wait+0x28d
_mtx_lock_sleep(...) at mtx_lock_sleep+0xb6
_mtx_lock_flags(...) at _mtx_lock_flags+0x30
envy24ht_intr(c5457000) at envy24ht_intr+0x20
ithread_execute_handlers(...) at ithread_execute_handlers+0x121
ithread_loop(...) at ithread_loop+0x54
fork_exit(...) at fork_exit+0x70
fork_trampoline(...) at fork_trampoline+0x8
I'm unable to do show alllocks (unsupported on 6.x?).
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc04768ab in db_fncall (dummy1=-472982908, dummy2=0,
dummy3=-1064325877,
dummy4=0xe3ceda70 ) at /usr/src/sys/ddb/db_command.c:493
#2 0xc04766b0 in db_command (last_cmdp=0xc0a62ea4, cmd_table=0x0,
aux_cmd_tablep=0xc09bb530, aux_cmd_tablep_end=0xc09bb54c)
at /usr/src/sys/ddb/db_command.c:408
#3 0xc0476778 in db_command_loop () at /usr/src/sys/ddb/db_command.c:459
#4 0xc0478399 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222
#5 0xc06c4ddb in kdb_trap (type=3, code=0, tf=0xe3cedbb0)
at /usr/src/sys/kern/subr_kdb.c:473
#6 0xc09177bc in trap (frame=
{tf_fs = -473038840, tf_es = -103896, tf_ds = -1063714776, tf_edi
= 1,
tf_esi = -1063673537, tf_ebp = -472982544, tf_isp = -472982564, tf_ebx =
-47298
2500, tf_edx = 0, tf_ecx = -1048489984, tf_eax = 18, tf_trapno = 3, tf_err =
0,
tf_eip = -1066644641, tf_cs = 32, tf_eflags = 150, tf_esp = -472982512,
tf_ss =
-1066747481}) at /usr/src/sys/i386/i386/trap.c:594
#7 0xc090433a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#8 0xc06c4b5f in kdb_enter (msg=0x12 Address 0x12 out of bounds)
at cpufunc.h:60
#9 0xc06ab9a7 in panic (fmt=0xc099a13f sleeping thread)
at /usr/src/sys/kern/kern_shutdown.c:549
#10 0xc06cc804 in propagate_priority (td=0xc5619300)
at /usr/src/sys/kern/subr_turnstile.c:209
#11 0xc06cd0b5 in turnstile_wait (lock=0xc5466240, owner=0xc5619300,
queue=0)
---Type return to continue, or q return to quit---
at /usr/src/sys/kern/subr_turnstile.c:715
#12 0xc06a2366 in _mtx_lock_sleep (m=0xc5466240, tid=3307930752, opts=0,
file=0xc0c04da9
/usr/src/sys/modules/sound/driver/envy24ht/../../../../dev/
sound/pci/envy24ht.c, line=1970) at /usr/src/sys/kern/kern_mutex.c:579
#13 0xc06a21a0 in _mtx_lock_flags (m=0xc1815000, opts=0,
file=0xc0c04da9
/usr/src/sys/modules/sound/driver/envy24ht/../../../../dev/
sound/pci/envy24ht.c, line=1970) at /usr/src/sys/kern/kern_mutex.c:288
#14 0xc0c03498 in ?? ()
#15 0xc5466240 in ?? ()
#16 0x in ?? ()
#17 0xc0c04da9 in ?? ()
#18 0x07b2 in ?? ()
#19 0x in ?? ()
#20 0x in ?? ()
#21 0x in ?? ()
#22 0xc5466180 in ?? ()
#23 0x0004 in ?? ()
#24 0xc52a7300 in ?? ()
#25 0xe3cedcec in ?? ()
#26 0xc0694f15 in ithread_execute_handlers (p=0xc5457000, ie=0xc52a7300)
at /usr/src/sys/kern/kern_intr.c:682
Previous frame identical to this frame (corrupt stack?)
(kgdb) up 13
#13 0xc06a21a0 in _mtx_lock_flags
panics on 6.3-RELEASE in IP stack
Hi all,
I started to play with RAT application (ports: mbone/rat + an SVN version)
and
it seems to crash my 6.3-RELEASE-p1 box in rather deterministic way. Crash
details are shown below. Has anyone seen a problem like this?
Thanks,
Petr
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0713a7f
stack pointer = 0x28:0xe8583b38
frame pointer = 0x28:0xe8583b40
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 = 9460 (rat-4.4.01)
trap number = 12
panic: page fault
Uptime: 35m41s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1023MB (261760 pages) 1007 991 975 959 943 927 911 895 879 863
847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559
543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255
239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc06a4ad6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc06a4d6c in panic (fmt=0xc096ba63 %s)
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc090d0d4 in trap_fatal (frame=0xe8583af8, eva=0)
at /usr/src/sys/i386/i386/trap.c:838
#4 0xc090ce3b in trap_pfault (frame=0xe8583af8, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:745
#5 0xc090ca79 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = -983498712, tf_edi = -396870780,
tf_esi = -396870780, tf_ebp = -396870848, tf_isp = -396870876, tf_ebx =
-972494912, tf_edx = -975435904, tf_ecx = 0, tf_eax = 0, tf_trapno = 12,
tf_err = 0, tf_eip = -1066321281, tf_cs = 32, tf_eflags = 66183, tf_esp =
-396870780, tf_ss = -985987072}) at /usr/src/sys/i386/i386/trap.c:435
#6 0xc08f9f0a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc0713a7f in if_findmulti (ifp=0x0, sa=0xe8583b84)
at /usr/src/sys/net/if.c:1893
#8 0xc0713c1f in if_addmulti (ifp=0xc53b0800, sa=0xe8583b84,
retifma=0xe8583b80) at /usr/src/sys/net/if.c:2001
#9 0xc073f6bb in in_addmulti (ap=0xe8583bb8, ifp=0xc53b0800)
at /usr/src/sys/netinet/in.c:982
#10 0xc0748898 in ip_setmoptions (inp=0xc58a3d5c, sopt=0xc5dc0780)
at /usr/src/sys/netinet/ip_output.c:1897
#11 0xc0747cc7 in ip_ctloutput_pcbinfo (so=0xc60469bc, sopt=0xe8583c90,
pcbinfo=0xc0a746a0) at /usr/src/sys/netinet/ip_output.c:1314
#12 0xc0747f74 in ip_ctloutput (so=0xc60469bc, sopt=0xe8583c90)
at /usr/src/sys/netinet/ip_output.c:1516
#13 0xc06dfcf0 in sosetopt (so=0xc60469bc, sopt=0xe8583c90)
at /usr/src/sys/kern/uipc_socket.c:1575
#14 0xc06e5071 in kern_setsockopt (td=0xc5dc0780, s=4, level=0, name=0,
val=0x0, valseg=UIO_USERSPACE, valsize=3319531392)
at /usr/src/sys/kern/uipc_syscalls.c:1351
#15 0xc06e4f92 in setsockopt (td=0xc5dc0780, uap=0x0)
at /usr/src/sys/kern/uipc_syscalls.c:1307
#16 0xc090d3eb in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134598976, tf_esi =
47000, tf_ebp = -1077942872, tf_isp = -396870300, tf_ebx = -1077942896,
tf_edx = -270598176, tf_ecx = 23, tf_eax = 105, tf_trapno = 12, tf_err = 2,
tf_eip = 672253131, tf_cs = 51, tf_eflags = 658, tf_esp = -1077942980, tf_ss
= 59})
at /usr/src/sys/i386/i386/trap.c:984
#17 0xc08f9f5f in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:200
#18 0x0033 in ?? ()
(kgdb) bt full
#0 doadump () at pcpu.h:165
No locals.
#1 0xc06a4ad6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
first_buf_printf = 1
#2 0xc06a4d6c in panic (fmt=0xc096ba63 %s)
at /usr/src/sys/kern/kern_shutdown.c:565
td = (struct thread *) 0xc5dc0780
bootopt = 260
newpanic = 0
ap = 0xc5dc0780 H6ÜĹŔYEĹ
buf = page fault, '\0' repeats 245 times
#3 0xc090d0d4 in trap_fatal (frame=0xe8583af8, eva=0)
at /usr/src/sys/i386/i386/trap.c:838
code = 40
ss = 40
esp = 0
type = 12
softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27,
ssd_dpl = 0, ssd_p = 1, ssd_xx = 6, ssd_xx1 = 3, ssd_def32 = 1,
ssd_gran = 1}
msg = 0x0
#4 0xc090ce3b in trap_pfault (frame=0xe8583af8, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:745
va = 0
vm = (struct vmspace *) 0x0
map = 0xc5fbc000
rv = 1
ftype = 1 '\001'
RE: 6.3-RELEASE panic
Hi all,
I've encountered the panic on 6.3-RELEASE once again - this time with
prepared debug kernel, so here you go. It seems like the panic is usually
initiated when firefox exits. Let me know if any further information is
Petr
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x9ef418
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc07f2348
stack pointer = 0x28:0xea61cb08
frame pointer = 0x28:0xea61cb14
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 = 1808 (firefox-bin)
trap number = 12
panic: page fault
Uptime: 4d23h12m54s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1023MB (261760 pages) 1007 991 975 959 943 927 911 895 879 863
847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575
(CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) 559 543 527 511 495
479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191
175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc06a4ad6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc06a4d6c in panic (fmt=0xc096ba63 %s)
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc090d0d4 in trap_fatal (frame=0xea61cac8, eva=10417176)
at /usr/src/sys/i386/i386/trap.c:838
#4 0xc090ce3b in trap_pfault (frame=0xea61cac8, usermode=0, eva=10417176)
at /usr/src/sys/i386/i386/trap.c:745
#5 0xc090ca79 in trap (frame=
{tf_fs = -1066532856, tf_es = -648871896, tf_ds = -949551064, tf_edi =
2590720, tf_esi = 0, tf_ebp = -362689772, tf_isp = -362689804, tf_ebx = 0,
tf_edx = 2590720, tf_ecx = 10417152, tf_eax = -981897076, tf_trapno = 12,
tf_err = 0, tf_eip = -1065409720, tf_cs = 32, tf_eflags = 2163206, tf_esp =
-981897076, tf_ss = 132}) at /usr/src/sys/i386/i386/trap.c:435
#6 0xc08f9f0a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc07f2348 in pagedep_find (pagedephd=0xc579708c, ino=2590720, lbn=)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:1165
#8 0xc07f23ea in pagedep_lookup (ip=0xc771f7bc, lbn=0, flags=1,
pagedeppp=0xea61cb64) at /usr/src/sys/ufs/ffs/ffs_softdep.c:1204
#9 0xc07f620b in newdirrem (bp=0xd953e678, dp=0xc771f7bc, ip=0xc6736084,
isrmdir=0, prevdirremp=0xea61cb90)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:3301
#10 0xc07f5fc0 in softdep_setup_remove (bp=0xd953e678, dp=0xc771f7bc,
ip=0xc6736084, isrmdir=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3230
#11 0xc0806bb6 in ufs_dirremove (dvp=0xc719b440, ip=0xc6736084,
flags=83918860, isrmdir=0) at /usr/src/sys/ufs/ufs/ufs_lookup.c:1020
#12 0xc0809b93 in ufs_remove (ap=0x278800)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:798
#13 0xc091e8b0 in VOP_REMOVE_APV (vop=0xc579708c, a=0xea61cc3c)
at vnode_if.c:1077
#14 0xc070401f in kern_unlink (td=0xc7678480,
path=0xbc29288 Address 0xbc29288 out of bounds, pathseg=UIO_USERSPACE)
at vnode_if.h:563
#15 0xc0703e8e in unlink (td=0xc7678480, uap=0xc579708c)
at /usr/src/sys/kern/vfs_syscalls.c:1642
#16 0xc090d3eb in syscall (frame=
{tf_fs = 134611003, tf_es = 134742075, tf_ds = -1078001605, tf_edi =
197300736, tf_esi = 17, tf_ebp = -1077950232, tf_isp = -362689180, tf_ebx =
673223176, tf_edx = 197300736, tf_ecx = 197300736, tf_eax = 10, tf_trapno =
0, tf_err = 2, tf_eip = 684230759, tf_cs = 51, tf_eflags = 2097810, tf_esp =
-1077950388, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:984
#17 0xc08f9f5f in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:200
#18 0x0033 in ?? ()
(kgdb) bt full
#0 doadump () at pcpu.h:165
No locals.
#1 0xc06a4ad6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
first_buf_printf = 1
#2 0xc06a4d6c in panic (fmt=0xc096ba63 %s)
at /usr/src/sys/kern/kern_shutdown.c:565
td = (struct thread *) 0xc7678480
bootopt = 260
newpanic = 0
ap = 0xc7678480 0t%ČŕzĺĹ\200'[EMAIL PROTECTED]'`ÇězĺĹ
buf = page fault, '\0' repeats 245 times
#3 0xc090d0d4 in trap_fatal (frame=0xea61cac8, eva=10417176)
at /usr/src/sys/i386/i386/trap.c:838
code = 40
ss = 40
esp = 0
type = 12
softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27,
ssd_dpl = 0, ssd_p = 1, ssd_xx = 4, ssd_xx1 = 3, ssd_def32 = 1,
ssd_gran = 1}
msg = 0x0
#4 0xc090ce3b in
6.3-RELEASE kernel panic
Hi, just another kernel panic: it may be due to a buggy IBM USB keyboard with integrated touchpad. I got random generation of ESC ^G characters. When unplugging this keyboard from the box for the second time, I got the following panic (admitting that it doesn't look like a keyboard related crash): [root@ /var/crash]# kgdb /boot/kernel/kernel ./vmcore.11 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Unde fined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd. (no debugging symbols found)...Attempt to extract a component of a value that is not a structure pointer. (kgdb) bt #0 0xc06a46a6 in doadump () #1 0xc06a4b76 in boot () #2 0xc06a4e0c in panic () #3 0xc090d1b4 in trap_fatal () #4 0xc090cf1b in trap_pfault () #5 0xc090cb59 in trap () #6 0xc08f9fea in calltrap () #7 0xc07f8a7c in handle_written_filepage () #8 0xc07f7f60 in softdep_disk_write_complete () #9 0xc06ef5e4 in bufdone () #10 0xc066c057 in g_vfs_done () #11 0xc06ef2cb in biodone () #12 0xc0669fc2 in g_io_schedule_up () #13 0xc066a20e in g_up_procbody () #14 0xc068dd74 in fork_exit () #15 0xc08fa04c in fork_trampoline () (kgdb) bt full #0 0xc06a46a6 in doadump () No symbol table info available. #1 0xc06a4b76 in boot () No symbol table info available. #2 0xc06a4e0c in panic () No symbol table info available. #3 0xc090d1b4 in trap_fatal () No symbol table info available. #4 0xc090cf1b in trap_pfault () No symbol table info available. #5 0xc090cb59 in trap () No symbol table info available. #6 0xc08f9fea in calltrap () No symbol table info available. #7 0xc07f8a7c in handle_written_filepage () No symbol table info available. #8 0xc07f7f60 in softdep_disk_write_complete () No symbol table info available. #9 0xc06ef5e4 in bufdone () No symbol table info available. #10 0xc066c057 in g_vfs_done () No symbol table info available. #11 0xc06ef2cb in biodone () No symbol table info available. #12 0xc0669fc2 in g_io_schedule_up () No symbol table info available. #13 0xc066a20e in g_up_procbody () No symbol table info available. #14 0xc068dd74 in fork_exit () No symbol table info available. #15 0xc08fa04c in fork_trampoline () No symbol table info available. Alas, no debugging symbols kernel in default installation :( Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: snd_emu10k1.ko after 6.2 to 6.3 upgrade
What does 'nm /boot/kernel/sound.ko | grep midi' show? sound.ko seems to be OK as it was properly updated by freebsd-update: [EMAIL PROTECTED] ~]# ls -l /boot/kernel/sound.ko -r-xr-xr-x 1 root wheel 139075 Jan 21 15:42 /boot/kernel/sound.ko [EMAIL PROTECTED] ~]# sha256 /boot/kernel/sound.ko SHA256 (/boot/kernel/sound.ko) = a61572cc74e3b00088a824765d7291c91d4ff52fe8709aa77abcade626fbece8 [EMAIL PROTECTED] ~]# nm /boot/kernel/sound.ko | grep midi snd_emu10k1.ko however was not updated for some reason and it has some dependencies: [EMAIL PROTECTED] ~]# ls -l /boot/kernel/snd_emu10k1.ko -r-xr-xr-x 1 root wheel 30008 Feb 20 2007 /boot/kernel/snd_emu10k1.ko [EMAIL PROTECTED] ~]# sha256 /boot/kernel/snd_emu10k1.ko SHA256 (/boot/kernel/snd_emu10k1.ko) = 13a0e7f03d354f57517d17ea52b5c7fa5a3c153cefcbf2cf8831d91204f0b2a3 [EMAIL PROTECTED] ~]# nm /boot/kernel/snd_emu10k1.ko | grep midi 4a04 r __set_modmetadata_set_sym__mod_metadata_md_snd_emu10k1_on_midi 5090 d _mod_metadata_md_snd_emu10k1_on_midi 50a0 d _snd_emu10k1_depend_on_midi When I compile new GENERIC-based snd_emu10k1.ko, it shows no such depends: [EMAIL PROTECTED] ~]# nm /sys/i386/compile/GENERIC/modules/usr/src/sys/modules/sou nd/driver/emu10k1/snd_emu10k1.ko | grep midi Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: snd_emu10k1.ko after 6.2 to 6.3 upgrade
Did you kldload sound.ko before snd_emu10k1.ko? It maybe that freebsd-upgrade didn't run kldxref on your kernel dir to update the /boot/kernel/linker.hints file that is used to autoload dependencies. Yes I did, sound.ko is loaded. Actually, I can use sound.ko from the freebsd-update'd tree together with snd_emu10k1.ko built from source and it works without any apparent problem. You can try doing a 'kldxref /boot/kernel' to see if that fixes the dependency loading. That hasn't helped: # kldload snd_emu10k1 kldload: can't load snd_emu10k1: No such file or directory dmesg says again: KLD snd_emu10k1.ko: depends on midi - not available Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZMasaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-549493944 fax: +420-541212747 e-mail: [EMAIL PROTECTED] -Original Message- From: John Baldwin [mailto:[EMAIL PROTECTED] Sent: Friday, January 25, 2008 9:10 PM To: Petr Holub Cc: freebsd-stable@freebsd.org Subject: Re: snd_emu10k1.ko after 6.2 to 6.3 upgrade On Friday 25 January 2008 11:16:19 am Petr Holub wrote: Do you have an error message in the dmesg after this? Yes, I do - sorry, haven't thought it will end up in dmesg and not in the terminal. It says: KLD snd_emu10k1.ko: depends on midi - not available -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: snd_emu10k1.ko after 6.2 to 6.3 upgrade
Do you have an error message in the dmesg after this? Yes, I do - sorry, haven't thought it will end up in dmesg and not in the terminal. It says: KLD snd_emu10k1.ko: depends on midi - not available Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
snd_emu10k1.ko after 6.2 to 6.3 upgrade
Hi, I've found a problem after updating from 6.2-RELEASE to 6.3-RELEASE using freebsd-update as described on daemonology blog. It looks like if the snd_emu10k1.ko along with a few others was not appropriately updated: # ls -l snd_* -r-xr-xr-x 1 root wheel 16566 Feb 20 2007 snd_ad1816.ko -r-xr-xr-x 1 root wheel 17731 Feb 20 2007 snd_als4000.ko -r-xr-xr-x 1 root wheel 20004 Jan 21 15:42 snd_atiixp.ko -r-xr-xr-x 1 root wheel 19192 Feb 20 2007 snd_cmi.ko -r-xr-xr-x 1 root wheel 18594 Feb 20 2007 snd_cs4281.ko -r-xr-xr-x 1 root wheel 30814 Feb 20 2007 snd_csa.ko -r-xr-xr-x 1 root wheel 11098 Jan 21 15:42 snd_driver.ko -r-xr-xr-x 1 root wheel 45839 Feb 20 2007 snd_ds1.ko -r-xr-xr-x 1 root wheel 30008 Feb 20 2007 snd_emu10k1.ko -r-xr-xr-x 1 root wheel 59398 Feb 20 2007 snd_emu10kx.ko -rwxr-xr-x 1 root wheel 31223 Jan 21 15:42 snd_envy24.ko -rwxr-xr-x 1 root wheel 30504 Jan 21 15:42 snd_envy24ht.ko -r-xr-xr-x 1 root wheel 32005 Feb 20 2007 snd_es137x.ko -r-xr-xr-x 1 root wheel 20075 Feb 20 2007 snd_ess.ko -r-xr-xr-x 1 root wheel 15636 Feb 20 2007 snd_fm801.ko -rwxr-xr-x 1 root wheel 77423 Jan 21 15:42 snd_hda.ko -r-xr-xr-x 1 root wheel 23812 Jan 21 15:42 snd_ich.ko -r-xr-xr-x 1 root wheel 31117 Feb 20 2007 snd_maestro.ko -r-xr-xr-x 1 root wheel 42945 Jan 21 15:42 snd_maestro3.ko -r-xr-xr-x 1 root wheel 46976 Feb 20 2007 snd_mss.ko -r-xr-xr-x 1 root wheel 68790 Feb 20 2007 snd_neomagic.ko -r-xr-xr-x 1 root wheel 14783 Feb 20 2007 snd_null.ko -r-xr-xr-x 1 root wheel 16934 Feb 20 2007 snd_sb16.ko -r-xr-xr-x 1 root wheel 15418 Feb 20 2007 snd_sb8.ko -r-xr-xr-x 1 root wheel 15397 Feb 20 2007 snd_sbc.ko -r-xr-xr-x 1 root wheel 19397 Feb 20 2007 snd_solo.ko -r-xr-xr-x 1 root wheel 7240 Jan 21 15:42 snd_spicds.ko -r-xr-xr-x 1 root wheel 18856 Jan 21 15:42 snd_t4dwave.ko -r-xr-xr-x 1 root wheel 36300 Jan 21 15:42 snd_uaudio.ko -r-xr-xr-x 1 root wheel 21918 Jan 21 15:42 snd_via8233.ko -r-xr-xr-x 1 root wheel 16075 Jan 21 15:42 snd_via82c686.ko -r-xr-xr-x 1 root wheel 18707 Feb 20 2007 snd_vibes.ko Those modules dated Feb 20 2007 are not loadable actually: # kldload snd_emu10k1.ko kldload: can't load snd_emu10k1.ko: No such file or directory When I build the module from source, it loads just fine. Maybe some bug in the freebsd-update list of what to update? Just for your reference, sound.ko has been updated properly and can be loaded fine. Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 6.3-RELEASE panic
I thought we shipped the debugging symbols in /boot precisely for the reason of making panics with default installs not report useless traces :( I think building GENERIC kernel from sources with tag=RELENG_6_3_0_RELEASE will help. I tried to build it from the sources that come from the freebsd-update and thus I assume they are actually RELENG_6_3_0_RELEASE. Still I was unable to run gdb with the given vmcore against such a kernel. Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.3-RELEASE panic
Hi, I've just updated the 6.2-RELEASE to 6.3-RELEASE using freebsd-update as described in daemonology blog. While removing the old packages using pkg_delete -af I've tried to stop all the deamons from /usr/local/etc/rc.d and got the following panic (hand transcribed from a photo - I don't have that machine enabled for remote debugging). Panic seems to be deterministic when stopping those scripts (verified by subsequent attempts while pkg_delete was not running). Stopping mdnsd. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x5a fault code = supervisor read, page ont present instruction pointer = 0x20:0xc073fa6f stack pointer = 0x28:0xe625db9c frame pointer = 0x28:0xe625dba4 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 = 1177 (mdnsd) trap number = 12 panic: page fault [root@ /var/crash]# cat info.10 Dump header from device /dev/ad4s1b Architecture: i386 Architecture Version: 2 Dump Length: 1072824320B (1023 MB) Blocksize: 512 Dumptime: Mon Jan 21 17:26:26 2008 Hostname: evenstar.ics.muni.cz Magic: FreeBSD Kernel Dump Version String: FreeBSD 6.3-RELEASE #0: Wed Jan 16 04:18:52 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Panic String: page fault Dump Parity: 2784976745 Bounds: 10 Dump Status: good [root@ /var/crash]# kgdb /boot/kernel/kernel vmcore.10 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd. (no debugging symbols found)...Attempt to extract a component of a value that is not a structure pointer. (kgdb) bt #0 0xc06a46a6 in doadump () #1 0xc06a4b76 in boot () #2 0xc06a4e0c in panic () #3 0xc090d1b4 in trap_fatal () #4 0xc090cf1b in trap_pfault () #5 0xc090cb59 in trap () #6 0xc08f9fea in calltrap () #7 0xc073fa6f in in_delmulti () #8 0xc0748e15 in ip_freemoptions () #9 0xc07414cc in in_pcbdetach () #10 0xc075a0ee in udp_detach () #11 0xc06de0b8 in soclose () #12 0xc06cd83b in soo_close () #13 0xc0683ffc in fdrop_locked () #14 0xc0683f25 in fdrop () #15 0xc0682553 in closef () #16 0xc067f8e7 in kern_close () #17 0xc067f6d8 in close () #18 0xc090d4cb in syscall () #19 0xc08fa03f in Xint0x80_syscall () #20 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) Petr PS: please cc me in the replies as I'm not regular subscribed to the stable@ list. Thanks a lot. Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZMasaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-549493944 fax: +420-541212747 e-mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 6.3-RELEASE panic
Can you obtain a trace against the kernel.symbols? Is it possible to do it with this vmcore? Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 6.3-RELEASE panic
Kris, Yes, the kernel.debug or kernel.symbols should either be in your /boot/kernel or in your kernel compile directory (unless you built your kernel without -g, but I think it is on by default). as I've said in my previous email (outside the list), I've got the kernel through freebsd-update and it seems there is no kernel.debug nor kernel.symbols present. Would it be possible to get the .symbols or .debug for that kernel? (See my previuous email with more detailed info). Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 6.3-RELEASE panic
I'm afraid not -- FreeBSD Update is just distributing the bits from the release ISO image, and the release ISO doesn't include kernel debug bits (at least, not on 6.3-RELEASE -- I think it does on 7.0-RC1). I thought we shipped the debugging symbols in /boot precisely for the reason of making panics with default installs not report useless traces :( If you can build it ex post, I will be more than happy to send you the trace back. Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.2-RELEASE panic when blanking CD-RW media
Hi, I've encountered a deterministic kernel panic when blanking one specific CD-RW media using cdrecord. # cdrecord -scanbus Cdrecord-Clone 2.01 (i386-unknown-freebsd6.2) Copyright (C) 1995-2004 Jörg Schil ling Using libscg version 'schily-0.8'. scsibus2: 2,0,0 200) 'PIONEER ' 'DVD-RW DVR-111 ' '1.23' Removable CD-ROM 2,1,0 201) * 2,2,0 202) * 2,3,0 203) * 2,4,0 204) * 2,5,0 205) * 2,6,0 206) * 2,7,0 207) * # cdrecord dev=2,0,0 blank=fast The kernel panic details follow and dmesg is at the end of this email. Though I understand there's something wrong with the media, I think it shouldn't panic the kernel either. Thanks in advance for looking into this, Petr # cat info.9 Dump header from device /dev/ad4s1b Architecture: i386 Architecture Version: 2 Dump Length: 1072824320B (1023 MB) Blocksize: 512 Dumptime: Tue Feb 20 14:18:54 2007 Hostname: evenstar.ics.muni.cz Magic: FreeBSD Kernel Dump Version String: FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Panic String: page fault Dump Parity: 801179006 Bounds: 9 Dump Status: good # kgdb /boot/kernel/kernel vmcore.9 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd. (no debugging symbols found)...Attempt to extract a component of a value that is not a structure pointer. (kgdb) bt #0 0xc067262e in doadump () #1 0xc0672afe in boot () #2 0xc0672d94 in panic () #3 0xc0885a04 in trap_fatal () #4 0xc088576b in trap_pfault () #5 0xc08853a9 in trap () #6 0xc0873a7a in calltrap () #7 0xc04e5e2e in acd_geom_detach () #8 0xc06388f9 in one_event () #9 0xc06389d1 in g_run_events () #10 0xc0639de5 in g_event_procbody () #11 0xc065cd34 in fork_exit () #12 0xc0873adc in fork_trampoline () (kgdb) x 0xc067262e 0xc04e5e2e acd_geom_detach+18:0x03b0b0ff (kgdb) q dmesg: Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.40GHz (3412.10-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf43 Stepping = 3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMO V,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x649dSSE3,RSVD2,MON,DS_CPL,EST,CNTX-ID,CX16,b14 AMD Features=0x2000LM Logical CPUs per core: 2 real memory = 1073217536 (1023 MB) avail memory = 1032843264 (984 MB) MPTable: INTEL ioapic0: Assuming intbase of 0 ioapic1: Assuming intbase of 24 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) cpu0 on motherboard pcib0: MPTable Host-PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: MPTable PCI-PCI bridge irq 16 at device 1.0 on pci0 pci6: PCI bus on pcib1 nvidia0: GeForce 7900 GT/GTO port 0xcc00-0xcc7f mem 0xfd00-0xfdff,0xd000-0xdfff,0xfc00-0xfcff irq 16 at device 0.0 on pci6 nvidia0: [GIANT-LOCKED] pci0: multimedia at device 27.0 (no driver attached) pcib2: PCI-PCI bridge irq 16 at device 28.0 on pci0 pci4: PCI bus on pcib2 pcib3: MPTable PCI-PCI bridge at device 0.0 on pci4 pci5: PCI bus on pcib3 em0: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0xbc00-0xbc3f mem 0xfa9e-0xfa9f,0xfa98-0xfa9b irq 24 at device 1.0 on pci5 em0: Ethernet address: 00:04:23:c3:90:83 pcib4: MPTable PCI-PCI bridge irq 16 at device 28.4 on pci0 pci3: PCI bus on pcib4 pci3: network, ethernet at device 0.0 (no driver attached) pcib5: MPTable PCI-PCI bridge irq 17 at device 28.5 on pci0 pci2: PCI bus on pcib5 pci2: mass storage at device 0.0 (no driver attached) uhci0: UHCI (generic) USB controller port 0xe480-0xe49f irq 20 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0xe800-0xe81f irq 17 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: UHCI (generic) USB controller on uhci1
RE: freebsd-update to track release engineering
Hi Colin, To avoid repeating myself too many times, I'm just going to point to my latest blog entry: http://www.daemonology.net/blog/2006-11-26-freebsd-6.1-to-6.2-binary-u pgrade.html I've tested it (ok, one day later than I assumed) and resulted in a kernel panic after reboot when attempting to start mountd. Basically it looks like the new kernel hasn't been installed (/boot/kernel/kernel is dated Aug 30). May it be because I'm tracking 6.1-SECURITY using freebsd-update and the binary diff fails then? Maybe just an idea for improvement: it would be helpful if you can put the update candidates for changed config files (/etc) into /etc/upgrade in a way binary update from sysinstall does that. I understand why you want to avoid doing mergemaster from your script, but it would be fine to have the files at least ready so that user can diff them and decide what to do. Petr Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZMasaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-549493944 fax: +420-541212747 e-mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.1-RELEASE with Xorg crashes when using Radeon driver on ThinkPad T41p
Hi Phil, If you are facing the problem I am thinking about, you have to set in your xorg.conf file something like : option noaccel true (sorry I do not have it at hand to confirm) no, it has the same problem with NoAccel set to True. Alas. :( Thanks anyway for the idea, Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: a few problems with 6.0-RELEASE on IBM T41p
Not if you're using any third party modules. What does 'kldstat' tell you? kernel + acpi.ko + linux.ko, as I already mentioned in another email. Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
a few problems with 6.0-RELEASE on IBM T41p
Hi, since I've upgraded from 6.0-BETA4 to 6.0-RELEASE (using binary upgrade on contrary to 6.0-BETA4, which was binary from BETA2, which was clean install ;-) ), I'm experiencing multiple problems which were not present on BETA4: 1) when rebooting, the system freezes on message Shutting down ACPI and looks like intending to never reboot 2) I get rather regular freezes in X when running GL with drm acceleration; I've rebuilt both xorg-server-snap and dri-devel from sources but it freezes still after couple of seconds of glxgears (while it worked fine on BETA4 achieving slightly above 2100 fps) 3) psm0: unable to allocate IRQ when both psm and acpi_ibm are present in the kernel; this is also described also in one of my recent posts: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=607372+0+archive/2005/freebsd-stabl e/20051113.freebsd-stable 4) ipw (with internal 2100B card) can freeze the machine under load on rather rare occasions There are also other problems with ipw, as it sometimes ceases to work under heavier load (without freezing the system). But that was also occuring on BETA2 - BETA4. Alas none of those situations produces kernel panic, so there is no dump to send :( Any ideas? Looks to me like there is some significant problem with ACPI... (should I cross-post this to acpi@ ?) Thanks, Petr Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZMasaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-549493944 fax: +420-541212747 e-mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: a few problems with 6.0-RELEASE on IBM T41p
Did you remember to rebuild any modules you are using when you upgraded? cd /sys/i386/conf/ config KLOBOUCEK cd ../compile/KLOBOUCEK make cleandepend; make depend make make install as usual. I assume that's sufficient. The only thing I'm not sure of now is the linux emulation... Thanks, Petr Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZMasaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-549493944 fax: +420-541212747 e-mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: a few problems with 6.0-RELEASE on IBM T41p
2) I get rather regular freezes in X when running GL with drm acceleration; I've rebuilt both xorg-server-snap and dri-devel from sources but it freezes still after couple of seconds of glxgears (while it worked fine on BETA4 achieving slightly above 2100 fps) Did you remember to rebuild any modules you are using when you upgraded? I've checked that linux.ko has been rebuilt as well, I have no modules in /boot/modules and also at the time of freezing X with glxgears, only kernel+acpi.ko+linux.ko are loaded. Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: usbd.conf
usbd is deprecated. Please use devd. OK, it works with devd. (BTW, wouldn't it be better to either fix usbd or to remove it?...) Thanks a lot, Petr Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZMasaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-549493944 fax: +420-541212747 e-mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
usbd.conf
Hi,
I've found that usbd on 6.0-RELEASE doesn't react on detach event properly:
usbd.conf:
device iKey 3000 Series Token
vendor 0x04b9
product 0x1300
detach /usr/local/etc/rc.d/openct.sh stop
attach /usr/local/etc/rc.d/openct.sh start
what happens (usbd -d -):
usbd: opened /dev/usb0
usbd: opened /dev/usb1
usbd: opened /dev/usb2
usbd: opened /dev/usb3
usbd: reading configuration file /etc/usbd.conf
usbd: action 1: ActiveWire board, firmware download
vndr=0x0854 prdct=0x0100 rlse=0x
attach='/usr/local/bin/ezdownload -f
/usr/local/share/usb/firmware/0854.0100.0_01.hex ${DEVNAME}'
usbd: action 2: Entrega Serial with UART
vndr=0x1645 prdct=0x8001 rlse=0x0101
attach='/usr/sbin/ezdownload -v -f /usr/share/usb/firmware/1645.8001.0101
/dev/${DEVNAME}'
usbd: action 3: Handspring Visor
vndr=0x082d prdct=0x0100 rlse=0x0100
devname: ugen[0-9]+
attach='/usr/local/bin/coldsync -md -p /dev/${DEVNAME} -t usb'
usbd: action 4: iKey 3000 Series Token
vndr=0x04b9 prdct=0x1300
attach='/usr/local/etc/rc.d/openct.sh start'
detach='/usr/local/etc/rc.d/openct.sh stop'
usbd: action 5: USB device
usbd: 5 actions
usbd: opened /dev/usb
usbd: processing event queue on /dev/usb
usbd: device-attach event at 1131639766.674323000, iKey 3000 Series Token,
vendor 0x04b9:
vndr=0x04b9 prdct=0x1300 rlse=0x0100 clss=0x00ff subclss=0x prtcl=0x
device names: ugen0
=== match attempt: ugen0
usbd: Found action 'iKey 3000 Series Token' for iKey 3000 Series Token, vendor
0x04b9 at ugen0
usbd: action 0: iKey 3000 Series Token
vndr=0x04b9 prdct=0x1300
attach='/usr/local/etc/rc.d/openct.sh start'
detach='/usr/local/etc/rc.d/openct.sh stop'
usbd: Setting DEVNAME='ugen0'
usbd: Executing '/usr/local/etc/rc.d/openct.sh start'
Starting smart card terminal framework: OpenCTDebug: ifd_scan_usb: BSD:
ifd_scan_usb
Debug: ifd_scan_usb: BSD: ifd_scan_usb: ifd_driver_for(vendor
0x04b9[0x04b9].iKey 3000 Series Token[0x1300)
Debug: ifd_spawn_handler: driver=ikey3k, device=/dev/ugen0, index=-1
usbd: '/usr/local/etc/rc.d/openct.sh start' is ok
usbd: processing event queue on /dev/usb
usbd: device-detach event at 1131639769.712468000, product 0x1300, vendor
0x04b9:
vndr=0x04b9 prdct=0x1300 rlse=0x0100 clss=0x00ff subclss=0x prtcl=0x
So attach event works correctly, but even though detach is noted by
usbd, it doesn't launch the action. Any hint before diving into
sources and ktracing?
Thanks,
Petr
Petr Holub
CESNET z.s.p.o. Supercomputing Center Brno
Zikova 4 Institute of Compt. Science
162 00 Praha 6, CZMasaryk University
Czech Republic Botanicka 68a, 60200 Brno, CZ
e-mail: [EMAIL PROTECTED] phone: +420-549493944
fax: +420-541212747
e-mail: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
psm0 broken with acpi_ibm on 6.0-RELEASE
Hi all, I've found the following problem on my IBM T41p when running 6.0-RELEASE: when both psm and acpi_ibm are compiled in the kernel, the psm0 device (touchpad) doesn't initialize properly - with verbose logging it says psm0: unable to allocate IRQ When acpi_ibm is removed from the kernel, psm0 works OK. However, combination of both psm and acpi_ibm used to work at least till 6.0-BETA4, which is what I had previously on this laptop. Best, Petr Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZMasaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-549493944 fax: +420-541212747 e-mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
powerd problem on ASUS T9400 with 6.0RC1
Dear all, I've encountered a problem with powerd which seems to be specific to ASUS T9400 laptop. Powerd crashes after arbitrary amount of time saying that its impossible to configure (usually, but not necessarily) the maximum processor speed: # powerd -v -p 200 idle time 90%, decreasing clock speed from 787 MHz to 700 MHz idle time 90%, decreasing clock speed from 787 MHz to 700 MHz idle time 90%, decreasing clock speed from 612 MHz to 525 MHz idle time 65%, increasing clock speed from 700 MHz to 900 MHz idle time 90%, decreasing clock speed from 787 MHz to 700 MHz idle time 90%, decreasing clock speed from 700 MHz to 612 MHz idle time 90%, decreasing clock speed from 612 MHz to 525 MHz idle time 65%, increasing clock speed from 787 MHz to 900 MHz idle time 65%, increasing clock speed from 787 MHz to 900 MHz idle time 90%, decreasing clock speed from 612 MHz to 525 MHz idle time 65%, increasing clock speed from 525 MHz to 700 MHz idle time 90%, decreasing clock speed from 612 MHz to 525 MHz idle time 65%, increasing clock speed from 612 MHz to 787 MHz idle time 90%, decreasing clock speed from 612 MHz to 525 MHz idle time 65%, increasing clock speed from 612 MHz to 787 MHz idle time 90%, decreasing clock speed from 700 MHz to 612 MHz idle time 65%, increasing clock speed from 700 MHz to 900 MHz powerd: error setting CPU frequency 900: Device not configured and dmesg shows: acpi_perf0: Px transition to 900 failed acpi_perf0: set freq failed, err 6 Interesting thing is it looks like sometimes it succeeds setting the frequency 900 MHz and sometimes not. Kernel config and dmesg is below. (BTW, there is also another problem obvious from the dmesg: Interrupt storm detected on irq11: cbb0 cbb1+; throttling interrupt source wi0: Lucent Technologies WaveLAN/IEEE at port 0xd000-0xd03f irq 11 function 0 however, I will perhaps describe this in another mail). Thanks, Petr Kernel config: machine i386 cpu I686_CPU ident KLOBOLD # 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 SCHED_ULE # ULE scheduler # options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption 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 /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # 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. options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic# I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device
libcrypto.so.2 missing in compat4x
Hi all, I've installed compat4x from package (compat4x-i386-5.3_2) on my 6.0RC1 there is no libcrypto.so.2, which is used by quite a few of my legacy 4.x apps. I've checked 5.4 and this library used to be part of compat suite in /usr/lib/compat. Is it feature or bug? Thanks, Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: kernel panic on 5.4-RELEASE-p6
You need to follow the instructions in the chapter on kernel debugging in the developers handbook in order for anyone to be able to begin investigating this. I though that - alas at the time of the panic, that machine didn't have dump partition configured. :(( Anyway, I've configured that partition, built kernel.debug and I'm just waiting if that happens again. Thanks, Petr Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZMasaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-549493944 fax: +420-541212747 e-mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel panic on 5.4-RELEASE-p6
Hi all, I've encoutnered the follwing kernel panic on 5.4-RELEASE-p6. However, as the machine is production and not development one, I don't have debugger analysis. The panic might *theoretically* be due to problems accessing faulty CD-R media in the ATAPI DVD/CD-RW drive (that was the only unusual thing which happened before the panic). Kernel config and dmesg are attached below, the machine is IBM T41p laptop. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x300f0 fault code = supervisor read, page not present instruction pointer = 0x8:0x300f0 stack pointer = 0x10:0xe67cdb1c frame pointer = 0x10:0xe67cdb34 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 = 1337 (vim) trap number = 12 panic: page fault Uptime: 14m43s. Best, Petr Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZMasaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-549493944 fax: +420-541212747 e-mail: [EMAIL PROTECTED] machine i386 cpu I686_CPU ident KLOBOUCEK # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler # options SCHED_ULE 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 /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. 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. options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic# I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device
rc.resume with ACPI
Hi, I've tried to use rc.resume for restarting moused after resuming from ACPI S3 state on my T41p and it seems that this script is just ignored on my 5.3-RELEASE. As for the mouse, I've sorted out that problem via setting hint.psm.0.flags=0x3000 in /boot/device.hints, but I still think the rc.resume is useful and should work. Does it work for somebody else? If it has already been discussed and solved somewhere, it'd be great if somebody can send me a short pointer where. Thanks, Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: trouble with UDMA66 drive on Abit BP6: READ timeout
Hi all,
I'd like to add some of my experiences with BP6. I tried to create
software RAID using vinum (I tried RAID-1 and RAID-5) on 4x14GB drives
connected to HighPoint ATA66 in UDMA66 mode. I experienced
serious problems until I overclocked the bus to 78 MHz. I wasn't
able even to do newfs on that vinum device - it always froze the
box (usually with message "resetting devices"). After overclocking
it runs pretty stable - although I know overclocking is highly
unadvisable. I think making newfs on RAID-1 is high load operation
and it seems bus doesn't catch up on normal frequency. I'm using
BIOS of 11/17/1999. I'm runnig FreeBSD 4.0 Release.
Petr
Petr Holub
Masaryk University
Dept. Physical Chemistry Supercomputing Centre Brno
Faculty of Science Institute of Compt. Science
Kotlarska 2, 61137 Brno, CZBotanicka 68a, 60200 Brno, CZ
phone: +420-5-41129312phone: +420-5-41512278
e-mail: [EMAIL PROTECTED]e-mail: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
