Re: 8.0-RC1 panic attaching ppc
On Thu, 24 Sep 2009, John Baldwin wrote: Can you try this patch perhaps: Index: sys/amd64/isa/isa_dma.c === --- isa_dma.c (revision 197430) +++ isa_dma.c (working copy) This patch fixes the panic for me. I haven't tried printing (don't have any device handy here). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
USB problems with 8.0-RC1 ATI SB6000
Hi, I am having an odd problem with USB on a Gigabyte MA785GM-US2H board. Initially it worked fine (tested with a mouse), over several reboots, however I recently applied a patch to fix a crash in ppc and when I rebooted I got.. Sep 25 17:08:45 midget kernel: usb_alloc_device:1586: set address 2 failed (USB_ERR_TIMEOUT, ignored) Sep 25 17:08:46 midget kernel: usb_alloc_device:1624: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! Sep 25 17:08:48 midget kernel: usbd_req_re_enumerate:1539: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Sep 25 17:08:49 midget kernel: usbd_req_re_enumerate:1553: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! Sep 25 17:08:51 midget kernel: usbd_req_re_enumerate:1539: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Sep 25 17:08:52 midget kernel: usbd_req_re_enumerate:1553: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! Sep 25 17:08:52 midget kernel: ugen0.2: (null) at usbus0 (disconnected) I tried reverting to the old kernel but it behaves exactly the same now.. Another difference was that I loaded the sound driver in the loader, but I reverted that to no effect (unless loading it has some how stuffed it over reboots..) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C Copyright (c) 1992-2009 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.0-RC1 #1 r197448M: Fri Sep 25 16:00:12 CST 2009 r...@midget.gsoft.com.au:/usr/obj/usr/src/sys/MIDGET Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) II X2 240 Processor (2812.73-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f62 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3974762496 (3790 MB) ACPI APIC Table: GBTGBTUACPI FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: GBT GBTUACPI on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, cfce (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 32-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xee00-0xeeff mem 0xd800-0xdfff,0xfdfe-0xfdfe,0xfde0-0xfdef irq 18 at device 5.0 on pci1 hdac0: ATI (Unknown) High Definition Audio Controller mem 0xfdffc000-0xfdff irq 19 at device 5.1 on pci1 hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] pcib2: ACPI PCI-PCI bridge irq 18 at device 10.0 on pci0 pci2: ACPI PCI bus on pcib2 re0: RealTek 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP PCIe Gigabit Ethernet port 0xde00-0xdeff mem 0xfdaff000-0xfdaf,0xfdae-0xfdae irq 18 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:24:1d:d1:92:cc re0: [FILTER] atapci0: ATI IXP700/800 SATA300 controller port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 6 3Gbps ports, PM supported ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 ata3: [ITHREAD] ata4: ATA channel 2 on atapci0 ata4: [ITHREAD] ata5: ATA channel 3 on atapci0 ata5: [ITHREAD] ata6: ATA channel 4 on atapci0 ata6: [ITHREAD] ata7: ATA channel 5 on atapci0 ata7: [ITHREAD] ohci0: OHCI (generic) USB controller mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: [ITHREAD] usbus0: OHCI (generic) USB controller on ohci0 ohci1: OHCI (generic) USB controller mem
May running megarc still cause memory corruption on 7.X?
Hi,
Previously sysutils/megarc port was marked as broken with the statement:
running megarc may cause memory corruption/system instability.
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/128082
But recently it has been re-enabled:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/137938
Gerrit Beine (the maintainer) said that he verified on 7.2 and it worked.
But yesterday we had the panic on 7.1-RELEASE-p5 that looked like was caused
by megarc with bt identical to reported in ports/128082.
Unread portion of the kernel message buffer:
TPTE at 0xbfd20830 IS ZERO @ VA 4820c000
panic: bad pte
cpuid = 0
Uptime: 10h19m56s
Physical memory: 3059 MB
Dumping 225 MB: 210 194 178 162 146 130 114 98 82 66 50 34 18 2
(kgdb) backtrace
#0 doadump () at pcpu.h:196
#1 0xc07910a7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2 0xc0791379 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0xc0aa37f6 in pmap_remove_pages (pmap=0xc69ae6e4) at
/usr/src/sys/i386/i386/pmap.c:3084
#4 0xc09cf79c in vmspace_exit (td=0xc64f68c0) at /usr/src/sys/vm/vm_map.c:404
#5 0xc076b6ad in exit1 (td=0xc64f68c0, rv=0) at
/usr/src/sys/kern/kern_exit.c:305
#6 0xc076ca0d in sys_exit (td=Could not find the frame base for sys_exit.
) at /usr/src/sys/kern/kern_exit.c:109
#7 0xc0aa81a5 in syscall (frame=0xe8d6ed38) at
/usr/src/sys/i386/i386/trap.c:1090
#8 0xc0a8e6e0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255
#9 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) allpcpu
cpuid= 3
curthread= 0xc6ae3d20: pid 48975 sh
curpcb = 0xe8ea1d90
fpcurthread = none
idlethread = 0xc633daf0: pid 11 idle: cpu3
switchticks = 37193321
cpuid= 2
curthread= 0xc633d8c0: pid 12 idle: cpu2
curpcb = 0xe4f10d90
fpcurthread = none
idlethread = 0xc633d8c0: pid 12 idle: cpu2
switchticks = 37193374
cpuid= 1
curthread= 0xc633d690: pid 13 idle: cpu1
curpcb = 0xe4f13d90
fpcurthread = none
idlethread = 0xc633d690: pid 13 idle: cpu1
switchticks = 37193374
cpuid= 0
curthread= 0xc64f68c0: pid 48980 sh
curpcb = 0xe8d6ed90
fpcurthread = none
idlethread = 0xc633d460: pid 14 idle: cpu0
switchticks = 37193321
(kgdb) ps
pid ppid pgrp uid state wmesg wchancmd
48980 48975 48975 0 RE CPU 0 sh
48978 48976 48976 0 R megarc
48976 48973 48976 0 Ss wait 0xc826e570 sh
48975 48972 48975 0 Rs CPU 3 sh
48973 705 705 0 S piperd 0xc8303318 cron
48972 705 705 0 S piperd 0xc674a18c cron
48267 18141 1814180 S lockf0xc83922c0 httpd
48266 18141 1814180 S lockf0xc7d62400 httpd
48265 18141 1814180 S select 0xc0c4ecb8 httpd
48264 18141 1814180 S lockf0xc7ceb240 httpd
...
At the moment of the crash megarc was run by cron (48973) at the same time
other cron job was started (we have the following script set up to run in the
same time:
if [ -x /usr/local/bin/vnstat ] [ `ls -l /var/db/vnstat/ | wc -l` -ge 1 ];
then /usr/local/bin/vnstat -u; fi)
and this sh process caused panic on its exit when kernel was trying to remove
its address space due to corrupted memory.
Should I add the comment to ports/137938 about this? I cc to Gerrit. Please
note, we are using 7.1-RELEASE-p5 while in ports/137938 it is said that it was
checked on 7.2. But it might be that Gerrit just did not test long enough? We
had megarc enabled on several 7.1 hosts for some times and saw only this one
panic (well, there was another one about a week ago, but it looked hardly
related, because megarc was not running at the moment of the crash and the
panic was when removing an entry from the namecache, I reported it to
hackers@).
Below some details from gdb session in case someone is interested to look at
this closer.
(kgdb) allchains
# no output
(kgdb) fr 5
#5 0xc076b6ad in exit1 (td=0xc64f68c0, rv=0) at
/usr/src/sys/kern/kern_exit.c:305
305 vmspace_exit(td);
(kgdb) p *td-td_proc
$1 = {p_list = {le_next = 0xc69a2570, le_prev = 0xc0c433f8}, p_threads =
{tqh_first = 0xc64f68c0,
tqh_last = 0xc64f68c8}, p_upcalls = {tqh_first = 0x0, tqh_last =
0xc6502838}, p_slock = {
lock_object = {lo_name = 0xc0b3b5ae process slock, lo_type = 0xc0b3b5ae
process slock,
lo_flags = 720896, lo_witness_data = {lod_list = {stqe_next = 0x0},
lod_witness = 0x0}},
mtx_lock = 4, mtx_recurse = 0}, p_ucred = 0xc708f700, p_fd = 0x0, p_fdtol =
0x0,
p_stats = 0xc64f8000, p_limit = 0xc7c60800, p_limco = {c_links = {sle =
{sle_next = 0x0}, tqe = {
tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0,
c_mtx = 0xc65028b8,
c_flags = 0}, p_sigacts = 0xc7d0, p_flag = 268443648, p_state =
PRS_NORMAL, p_pid = 48980,
p_hash = {le_next = 0x0, le_prev = 0xc632ad50}, p_pglist = {le_next = 0x0,
Re: FreeBSD 7.2-STABLE boot freeze
on 25/09/2009 12:04 kama said the following: On Thu, 24 Sep 2009, kama wrote: I am currently building the source on another machine. Lets see if it will build it any better. Building the the world on another machine and install it on the DL385 machine made it also to freeze. Did you still get the message about unresolved symbol? -- Andriy Gapon ___ 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
Re: USB problems with 8.0-RC1 ATI SB6000
On Fri, 25 Sep 2009, Daniel O'Connor wrote: I tried reverting to the old kernel but it behaves exactly the same now.. Never mind I found the thread on freebsd-usb@ titled sb600/sb700 ohci experimental patch which fixes it for me. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: FreeBSD 7.2-STABLE boot freeze (was: when calibrating clock.)
On Thu, 24 Sep 2009, kama wrote: I am currently building the source on another machine. Lets see if it will build it any better. Building the the world on another machine and install it on the DL385 machine made it also to freeze. /Bjorn ___ 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
Re: 8.0-RC1 panic attaching ppc
On Friday 25 September 2009 3:20:05 am Daniel O'Connor wrote: On Thu, 24 Sep 2009, John Baldwin wrote: Can you try this patch perhaps: Index: sys/amd64/isa/isa_dma.c === --- isa_dma.c (revision 197430) +++ isa_dma.c (working copy) This patch fixes the panic for me. I haven't tried printing (don't have any device handy here). I wonder if pmap_extract(kernel_pmap) doesn't work with direct map addresses for some reason? I kind of find that hard to believe actually. Alan, the original panic was in pmap_extract(kernel_pmap, ...) calls in the isa_dma code. My patch that fixes the panic just changes them to pmap_kextract(). -- John Baldwin ___ 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
Re: Base system's Heimdal with Openldap support?
On Thu, Sep 24, 2009 at 04:45:05PM -0700, Doug Barton wrote: Peter C. Lai wrote: What happens when you portupgrade? You will have to deal with rebuilding that part of world? Not unless the shared library version number changes, that's the beauty of shared libraries. Unfortunatly we're talking about openldap which has seen at least two version bumps in the last 12 months IIRC. -- Brooks pgphkFcsgiaM2.pgp Description: PGP signature
Re: May running megarc still cause memory corruption on 7.X?
Mikolaj Golub wrote:
Hi,
Previously sysutils/megarc port was marked as broken with the statement:
running megarc may cause memory corruption/system instability.
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/128082
But recently it has been re-enabled:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/137938
Gerrit Beine (the maintainer) said that he verified on 7.2 and it worked.
But yesterday we had the panic on 7.1-RELEASE-p5 that looked like was caused
by megarc with bt identical to reported in ports/128082.
Unread portion of the kernel message buffer:
TPTE at 0xbfd20830 IS ZERO @ VA 4820c000
panic: bad pte
cpuid = 0
Uptime: 10h19m56s
Physical memory: 3059 MB
Dumping 225 MB: 210 194 178 162 146 130 114 98 82 66 50 34 18 2
(kgdb) backtrace
#0 doadump () at pcpu.h:196
#1 0xc07910a7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2 0xc0791379 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0xc0aa37f6 in pmap_remove_pages (pmap=0xc69ae6e4) at
/usr/src/sys/i386/i386/pmap.c:3084
#4 0xc09cf79c in vmspace_exit (td=0xc64f68c0) at /usr/src/sys/vm/vm_map.c:404
#5 0xc076b6ad in exit1 (td=0xc64f68c0, rv=0) at
/usr/src/sys/kern/kern_exit.c:305
#6 0xc076ca0d in sys_exit (td=Could not find the frame base for sys_exit.
) at /usr/src/sys/kern/kern_exit.c:109
#7 0xc0aa81a5 in syscall (frame=0xe8d6ed38) at
/usr/src/sys/i386/i386/trap.c:1090
#8 0xc0a8e6e0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255
#9 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) allpcpu
cpuid= 3
curthread= 0xc6ae3d20: pid 48975 sh
curpcb = 0xe8ea1d90
fpcurthread = none
idlethread = 0xc633daf0: pid 11 idle: cpu3
switchticks = 37193321
cpuid= 2
curthread= 0xc633d8c0: pid 12 idle: cpu2
curpcb = 0xe4f10d90
fpcurthread = none
idlethread = 0xc633d8c0: pid 12 idle: cpu2
switchticks = 37193374
cpuid= 1
curthread= 0xc633d690: pid 13 idle: cpu1
curpcb = 0xe4f13d90
fpcurthread = none
idlethread = 0xc633d690: pid 13 idle: cpu1
switchticks = 37193374
cpuid= 0
curthread= 0xc64f68c0: pid 48980 sh
curpcb = 0xe8d6ed90
fpcurthread = none
idlethread = 0xc633d460: pid 14 idle: cpu0
switchticks = 37193321
(kgdb) ps
pid ppid pgrp uid state wmesg wchancmd
48980 48975 48975 0 RE CPU 0 sh
48978 48976 48976 0 R megarc
48976 48973 48976 0 Ss wait 0xc826e570 sh
48975 48972 48975 0 Rs CPU 3 sh
48973 705 705 0 S piperd 0xc8303318 cron
48972 705 705 0 S piperd 0xc674a18c cron
48267 18141 1814180 S lockf0xc83922c0 httpd
48266 18141 1814180 S lockf0xc7d62400 httpd
48265 18141 1814180 S select 0xc0c4ecb8 httpd
48264 18141 1814180 S lockf0xc7ceb240 httpd
...
At the moment of the crash megarc was run by cron (48973) at the same time
other cron job was started (we have the following script set up to run in the
same time:
if [ -x /usr/local/bin/vnstat ] [ `ls -l /var/db/vnstat/ | wc -l` -ge 1 ];
then /usr/local/bin/vnstat -u; fi)
and this sh process caused panic on its exit when kernel was trying to remove
its address space due to corrupted memory.
Should I add the comment to ports/137938 about this? I cc to Gerrit. Please
note, we are using 7.1-RELEASE-p5 while in ports/137938 it is said that it was
checked on 7.2. But it might be that Gerrit just did not test long enough? We
had megarc enabled on several 7.1 hosts for some times and saw only this one
panic (well, there was another one about a week ago, but it looked hardly
related, because megarc was not running at the moment of the crash and the
panic was when removing an entry from the namecache, I reported it to
hackers@).
Below some details from gdb session in case someone is interested to look at
this closer.
(kgdb) allchains
# no output
(kgdb) fr 5
#5 0xc076b6ad in exit1 (td=0xc64f68c0, rv=0) at
/usr/src/sys/kern/kern_exit.c:305
305 vmspace_exit(td);
(kgdb) p *td-td_proc
$1 = {p_list = {le_next = 0xc69a2570, le_prev = 0xc0c433f8}, p_threads = {tqh_first = 0xc64f68c0,
tqh_last = 0xc64f68c8}, p_upcalls = {tqh_first = 0x0, tqh_last = 0xc6502838}, p_slock = {
lock_object = {lo_name = 0xc0b3b5ae process slock, lo_type = 0xc0b3b5ae process slock,
lo_flags = 720896, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}},
mtx_lock = 4, mtx_recurse = 0}, p_ucred = 0xc708f700, p_fd = 0x0, p_fdtol = 0x0,
p_stats = 0xc64f8000, p_limit = 0xc7c60800, p_limco = {c_links = {sle = {sle_next = 0x0}, tqe = {
tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_mtx = 0xc65028b8,
c_flags = 0}, p_sigacts = 0xc7d0, p_flag = 268443648, p_state = PRS_NORMAL, p_pid = 48980,
p_hash = {le_next = 0x0, le_prev = 0xc632ad50}, p_pglist =
8-RC1: ral0: need multicast update callback
On my vanilla RC1 install (from ISO), ral seems to be having issues. About every 1/2 hour it will hang the network when downloading ports, or doing a large rsync transfer. If you ctrl-c on the transfer restart, it fires right up. The only error: ral0: need multicast update callback Exact chipset: ral0: Ralink Technology RT2561S mem 0xf020-0xf0207fff irq 20 at device 0.0 on pci3 ral0: MAC/BBP RT2561C, RF RT2527 ral0: [ITHREAD] I noticed some people having this problem with ndis and iwi in 2008 (!) on the list, but no mention of ral... Best, Steve ___ 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
Re: 8.0-RC1 panic attaching ppc
John Baldwin wrote: On Friday 25 September 2009 3:20:05 am Daniel O'Connor wrote: On Thu, 24 Sep 2009, John Baldwin wrote: Can you try this patch perhaps: Index: sys/amd64/isa/isa_dma.c === --- isa_dma.c (revision 197430) +++ isa_dma.c (working copy) This patch fixes the panic for me. I haven't tried printing (don't have any device handy here). I wonder if pmap_extract(kernel_pmap) doesn't work with direct map addresses for some reason? I kind of find that hard to believe actually. Alan, the original panic was in pmap_extract(kernel_pmap, ...) calls in the isa_dma code. My patch that fixes the panic just changes them to pmap_kextract(). Is this problem occurring on an AMD processor? Alan ___ 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
Re: 8.0-RC1 panic attaching ppc
John Baldwin wrote: On Friday 25 September 2009 3:20:05 am Daniel O'Connor wrote: On Thu, 24 Sep 2009, John Baldwin wrote: Can you try this patch perhaps: Index: sys/amd64/isa/isa_dma.c === --- isa_dma.c (revision 197430) +++ isa_dma.c (working copy) This patch fixes the panic for me. I haven't tried printing (don't have any device handy here). I wonder if pmap_extract(kernel_pmap) doesn't work with direct map addresses for some reason? I kind of find that hard to believe actually. Alan, the original panic was in pmap_extract(kernel_pmap, ...) calls in the isa_dma code. My patch that fixes the panic just changes them to pmap_kextract(). In principle, pmap_extract(kernel_pmap, ...) should work just fine. Alan ___ 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
8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?)
All,
I just got this overnight on my server:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x90
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc05ba39d
stack pointer = 0x28:0xf31077bc
frame pointer = 0x28:0xf31077c8
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 = 928 (NLM: master)
(kgdb) bt
#0 doadump () at pcpu.h:246
#1 0xc05e03f3 in boot (howto=260) at /zmirror/nfs/freebsd/base/stable/
8/sys/kern/kern_shutdown.c:416
#2 0xc05e062d in panic (fmt=Variable fmt is not available.
) at /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_shutdown.c:579
#3 0xc04ac807 in db_panic (addr=Could not find the frame base for
db_panic.
) at /zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c:478
#4 0xc04acd91 in db_command (last_cmdp=0xc0881c3c, cmd_table=0x0,
dopager=1) at /zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c:
445
#5 0xc04aceea in db_command_loop () at /zmirror/nfs/freebsd/base/
stable/8/sys/ddb/db_command.c:498
#6 0xc04aed5d in db_trap (type=12, code=0) at /zmirror/nfs/freebsd/
base/stable/8/sys/ddb/db_main.c:229
#7 0xc0608a14 in kdb_trap (type=12, code=0, tf=0xf310777c) at /
zmirror/nfs/freebsd/base/stable/8/sys/kern/subr_kdb.c:535
#8 0xc07c53af in trap_fatal (frame=0xf310777c, eva=144) at /zmirror/
nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:924
#9 0xc07c5650 in trap_pfault (frame=0xf310777c, usermode=0, eva=144)
at /zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:846
#10 0xc07c5ff2 in trap (frame=0xf310777c) at /zmirror/nfs/freebsd/base/
stable/8/sys/i386/i386/trap.c:528
#11 0xc07ac50b in calltrap () at /zmirror/nfs/freebsd/base/stable/8/
sys/i386/i386/exception.s:165
#12 0xc05ba39d in prison_priv_check (cred=0xc61e4880, priv=334) at /
zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_jail.c:3568
#13 0xc05d39ee in priv_check_cred (cred=0xc61e4880, priv=334, flags=0)
at /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_priv.c:92
#14 0xc09dbffc in secpolicy_fs_owner (mp=0xc4112284, cred=0xc61e4880)
at /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/
compat/opensolaris/kern/opensolaris_policy.c:86
#15 0xc09dc527 in secpolicy_vnode_access (cred=0xc61e4880,
vp=0xc4bb6d9c, owner=501, accmode=128)
at /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/
compat/opensolaris/kern/opensolaris_policy.c:125
#16 0xc0a56c5c in zfs_zaccess (zp=0xd4be8658, mode=2, flags=Variable
flags is not available.
) at /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/
contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2445
#17 0xc0a56edb in zfs_zaccess_rwx (zp=0xd4be8658, mode=Variable mode
is not available.
) at /zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/
contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2484
#18 0xc0a6bfa4 in zfs_freebsd_access (ap=0xf31078d4) at /zmirror/nfs/
freebsd/base/stable/8/sys/modules/zfs/../../cddl/contrib/opensolaris/
uts/common/fs/zfs/zfs_vnops.c:1068
#19 0xc07cfeb2 in VOP_ACCESS_APV (vop=0xc0acfac0, a=0xf31078d4) at
vnode_if.c:571
#20 0xc0718c93 in nlm_get_vfs_state (host=Variable host is not
available.
) at vnode_if.h:254
#21 0xc0718e30 in nlm_do_unlock (argp=0xf31079c8, result=0xf3107a08,
rqstp=0xcb199800, rpcp=0x0) at /zmirror/nfs/freebsd/base/stable/8/sys/
nlm/nlm_prot_impl.c:2227
#22 0xc071ac87 in nlm4_unlock_4_svc (argp=0xf31079c8,
result=0xf3107a08, rqstp=0xcb199800) at /zmirror/nfs/freebsd/base/
stable/8/sys/nlm/nlm_prot_server.c:540
#23 0xc071bce3 in nlm_prog_4 (rqstp=0xcb199800, transp=0xc652de00) at /
zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_svc.c:512
#24 0xc07284bf in svc_run_internal (pool=0xc61e4c80, ismaster=1) at /
zmirror/nfs/freebsd/base/stable/8/sys/rpc/svc.c:893
#25 0xc072943d in svc_run (pool=0xc61e4c80) at /zmirror/nfs/freebsd/
base/stable/8/sys/rpc/svc.c:1233
#26 0xc071a348 in nlm_syscall (td=0xc6551000, uap=0xf3107cf8) at /
zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_impl.c:1593
#27 0xc07c5977 in syscall (frame=0xf3107d38) at /zmirror/nfs/freebsd/
base/stable/8/sys/i386/i386/trap.c:1073
#28 0xc07ac570 in Xint0x80_syscall () at /zmirror/nfs/freebsd/base/
stable/8/sys/i386/i386/exception.s:261
#29 0x0033 in ?? ()
(kgdb) frame 12
#12 0xc05ba39d in prison_priv_check (cred=0xc61e4880, priv=334) at /
zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_jail.c:3568
3568switch (priv) {
(kgdb) l 3567
3562 */
3563if (cred-cr_prison-pr_flags PR_VNET)
3564return (0);
3565}
3566#endif /* VIMAGE */
3567
3568switch (priv) {
3569
3570/*
3571 * Allow ktrace privileges for root in jail.
(kgdb) p cred-cr_prison
$4 = (struct prison *) 0x0
--
Marcel
Re: 8.0-RC1 panic attaching ppc
On Sat, 26 Sep 2009, Alan Cox wrote: John Baldwin wrote: On Friday 25 September 2009 3:20:05 am Daniel O'Connor wrote: On Thu, 24 Sep 2009, John Baldwin wrote: Can you try this patch perhaps: Index: sys/amd64/isa/isa_dma.c = == --- isa_dma.c (revision 197430) +++ isa_dma.c (working copy) This patch fixes the panic for me. I haven't tried printing (don't have any device handy here). I wonder if pmap_extract(kernel_pmap) doesn't work with direct map addresses for some reason? I kind of find that hard to believe actually. Alan, the original panic was in pmap_extract(kernel_pmap, ...) calls in the isa_dma code. My patch that fixes the panic just changes them to pmap_kextract(). Is this problem occurring on an AMD processor? Yes, CPU: AMD Athlon(tm) II X2 240 Processor (2812.73-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f62 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3974762496 (3790 MB) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: 8.0-RC1 panic attaching ppc
On Fri, 25 Sep 2009, John Baldwin wrote: On Friday 25 September 2009 3:20:05 am Daniel O'Connor wrote: On Thu, 24 Sep 2009, John Baldwin wrote: Can you try this patch perhaps: Index: sys/amd64/isa/isa_dma.c = == --- isa_dma.c (revision 197430) +++ isa_dma.c (working copy) This patch fixes the panic for me. I haven't tried printing (don't have any device handy here). I wonder if pmap_extract(kernel_pmap) doesn't work with direct map addresses for some reason? I kind of find that hard to believe actually. Alan, the original panic was in pmap_extract(kernel_pmap, ...) calls in the isa_dma code. My patch that fixes the panic just changes them to pmap_kextract(). Well, if you want to test it some how let me know :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?)
Marcel Moolenaar wrote:
All,
I just got this overnight on my server:
Fatal trap 12: page fault while in kernel mode
fault virtual address= 0x90
fault code= supervisor read, page not present
instruction pointer= 0x20:0xc05ba39d
stack pointer= 0x28:0xf31077bc
frame pointer= 0x28:0xf31077c8
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= 928 (NLM: master)
(kgdb) bt
#0 doadump () at pcpu.h:246
#1 0xc05e03f3 in boot (howto=260) at
/zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_shutdown.c:416
#2 0xc05e062d in panic (fmt=Variable fmt is not available.
) at /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_shutdown.c:579
#3 0xc04ac807 in db_panic (addr=Could not find the frame base for
db_panic.
) at /zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c:478
#4 0xc04acd91 in db_command (last_cmdp=0xc0881c3c, cmd_table=0x0,
dopager=1) at /zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c:445
#5 0xc04aceea in db_command_loop () at
/zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_command.c:498
#6 0xc04aed5d in db_trap (type=12, code=0) at
/zmirror/nfs/freebsd/base/stable/8/sys/ddb/db_main.c:229
#7 0xc0608a14 in kdb_trap (type=12, code=0, tf=0xf310777c) at
/zmirror/nfs/freebsd/base/stable/8/sys/kern/subr_kdb.c:535
#8 0xc07c53af in trap_fatal (frame=0xf310777c, eva=144) at
/zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:924
#9 0xc07c5650 in trap_pfault (frame=0xf310777c, usermode=0, eva=144) at
/zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:846
#10 0xc07c5ff2 in trap (frame=0xf310777c) at
/zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:528
#11 0xc07ac50b in calltrap () at
/zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/exception.s:165
#12 0xc05ba39d in prison_priv_check (cred=0xc61e4880, priv=334) at
/zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_jail.c:3568
#13 0xc05d39ee in priv_check_cred (cred=0xc61e4880, priv=334, flags=0)
at /zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_priv.c:92
#14 0xc09dbffc in secpolicy_fs_owner (mp=0xc4112284, cred=0xc61e4880) at
/zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_policy.c:86
#15 0xc09dc527 in secpolicy_vnode_access (cred=0xc61e4880,
vp=0xc4bb6d9c, owner=501, accmode=128)
at
/zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_policy.c:125
#16 0xc0a56c5c in zfs_zaccess (zp=0xd4be8658, mode=2, flags=Variable
flags is not available.
) at
/zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2445
#17 0xc0a56edb in zfs_zaccess_rwx (zp=0xd4be8658, mode=Variable mode
is not available.
) at
/zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2484
#18 0xc0a6bfa4 in zfs_freebsd_access (ap=0xf31078d4) at
/zmirror/nfs/freebsd/base/stable/8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1068
#19 0xc07cfeb2 in VOP_ACCESS_APV (vop=0xc0acfac0, a=0xf31078d4) at
vnode_if.c:571
#20 0xc0718c93 in nlm_get_vfs_state (host=Variable host is not available.
) at vnode_if.h:254
#21 0xc0718e30 in nlm_do_unlock (argp=0xf31079c8, result=0xf3107a08,
rqstp=0xcb199800, rpcp=0x0) at
/zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_impl.c:2227
#22 0xc071ac87 in nlm4_unlock_4_svc (argp=0xf31079c8, result=0xf3107a08,
rqstp=0xcb199800) at
/zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_server.c:540
#23 0xc071bce3 in nlm_prog_4 (rqstp=0xcb199800, transp=0xc652de00) at
/zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_svc.c:512
#24 0xc07284bf in svc_run_internal (pool=0xc61e4c80, ismaster=1) at
/zmirror/nfs/freebsd/base/stable/8/sys/rpc/svc.c:893
#25 0xc072943d in svc_run (pool=0xc61e4c80) at
/zmirror/nfs/freebsd/base/stable/8/sys/rpc/svc.c:1233
#26 0xc071a348 in nlm_syscall (td=0xc6551000, uap=0xf3107cf8) at
/zmirror/nfs/freebsd/base/stable/8/sys/nlm/nlm_prot_impl.c:1593
#27 0xc07c5977 in syscall (frame=0xf3107d38) at
/zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/trap.c:1073
#28 0xc07ac570 in Xint0x80_syscall () at
/zmirror/nfs/freebsd/base/stable/8/sys/i386/i386/exception.s:261
#29 0x0033 in ?? ()
(kgdb) frame 12
#12 0xc05ba39d in prison_priv_check (cred=0xc61e4880, priv=334) at
/zmirror/nfs/freebsd/base/stable/8/sys/kern/kern_jail.c:3568
3568switch (priv) {
(kgdb) l 3567
3562 */
3563if (cred-cr_prison-pr_flags PR_VNET)
3564return (0);
3565}
3566#endif /* VIMAGE */
3567
3568switch (priv) {
3569
3570/*
3571 * Allow ktrace privileges for root in jail.
(kgdb) p cred-cr_prison
$4 = (struct prison *) 0x0
It seems to be NFS related. I think the null pointer in question is
from the export's anonymous
Re: 8-RC1: ral0: need multicast update callback
On Fri, Sep 25, 2009 at 08:47:38AM -0700, Steve Franks wrote: On my vanilla RC1 install (from ISO), ral seems to be having issues. About every 1/2 hour it will hang the network when downloading ports, or doing a large rsync transfer. If you ctrl-c on the transfer restart, it fires right up. The only error: ral0: need multicast update callback I noticed some people having this problem with ndis and iwi in 2008 (!) on the list, but no mention of ral... I've been seeing pauses in network connectivity with my iwn in BETA-2 through 4. I hadn't noticed it much until I set wpa_ptk_rekey= down to 600. Then it seemed like it hit me every five minutes. I think it was originally 1800. But the /usr/share/examples/etc/wpa_supplicant.conf, currently has it at 600 in -RC1. I could be remembering incorrectly. It seems like it became much less frequent when I changed wpa_ptk_rekey to 3600. Maybe I just started noticing when I had to start doing a lot of ssh sessions from the house. My sessions would lock up and, usually, continue in a few seconds to a few minutes. If I hadn't been using a session when the network paused, that session would usually be working fine while I waited for my original session to continue. I have not noticed it on my WEP AP, but I normally connect the ethernet cable at that location. I should test there. I have other issues with the iwn and haven't really dug into the problem to try to figure out if it is wpa_supplicant or iwn or a combination. iwn does not function after resume so I've actually run ethernet cables to where I use the laptop now. -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.org ___ 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
Re: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?)
On Sep 25, 2009, at 4:01 PM, Jamie Gritton wrote: (kgdb) p cred-cr_prison $4 = (struct prison *) 0x0 It seems to be NFS related. I think the null pointer in question is from the export's anonymous credential. Try the patch below and see if it helps (which I guess means run it overnight and see if it crashes again). Thanks. I'll give it a spin... -- Marcel Moolenaar xcl...@mac.com ___ 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
Re: 8-RC1: ral0: need multicast update callback
On Fri, Sep 25, 2009 at 11:29 PM, Scott Lambert lamb...@lambertfam.org wrote: iwn does not function after resume so I've actually run ethernet cables to where I use the laptop now. I have to unload the if_iwn module on suspend, and reload it on resume (via /etc/rc.[suspend|resume], of course). Have you tried that? -Brandon ___ 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
