Re: recent current panic
It looks very similar to http://www.freebsd.org/cgi/query-pr.cgi?pr=59576. You can revert to version 1.28 of net/bpf.h if you need tcpdump on lo, tun, ic, plip, disc or gif interface right now. just to note: I ran tcpdump on tunN (which was a pppoe interface) w/o problems two days ago (with a recent world) while debugging and testing other net related things. Do you have options INVARIANTS in your kernel configuration? M_ASSERTVALID(..) (that was added to BPF_MTAP macro) do nothing if you don't have INVARIANTS enabled. Yuriy. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent current panic
On Fri, 28 Nov 2003, Yuriy Tsibizov wrote: It looks very similar to http://www.freebsd.org/cgi/query-pr.cgi?pr=59576. You can revert to version 1.28 of net/bpf.h if you need tcpdump on lo, tun, ic, plip, disc or gif interface right now. just to note: I ran tcpdump on tunN (which was a pppoe interface) w/o problems two days ago (with a recent world) while debugging and testing other net related things. Do you have options INVARIANTS in your kernel configuration? M_ASSERTVALID(..) (that was added to BPF_MTAP macro) do nothing if you don't have INVARIANTS enabled. Yes, I do: makeoptions DEBUG=-g # Debugging for use in -current options DDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent current panic
On Fri, 2003-11-28 at 08:49, Yuriy Tsibizov wrote: It looks very similar to http://www.freebsd.org/cgi/query-pr.cgi?pr=59576. You can revert to version 1.28 of net/bpf.h if you need tcpdump on lo, tun, ic, plip, disc or gif interface right now. just to note: I ran tcpdump on tunN (which was a pppoe interface) w/o problems two days ago (with a recent world) while debugging and testing other net related things. Do you have options INVARIANTS in your kernel configuration? M_ASSERTVALID(..) (that was added to BPF_MTAP macro) do nothing if you don't have INVARIANTS enabled. Im getting the same problem with the realtek driver (also getting lock ups but Ill post something else for that). I removed the error by patching if_re.c with a patch like :- http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_dc.c.diff?r1=1.9.2.53r2=1.9.2.54 (basically pass the mbuf to XX_encap instead of a pointer to it) which was the reason for the INVARIANT in the 1st place. This may not be the correct way to fix it. -- Simon Loader ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent current panic
i got a panic on recent -CURRENT: # tcpdump -i lo0 port 23 [1] 507 listening on lo0 # telnet localhost Trying ::1... Wed Nov 26 14:51:23 MSK 2003 Debugger+0x55: xchgl %ebx,in_Debugger.0 db tr Debugger(c0898daf,0,c087197f,d629d8dc,100) at Debugger+0x55 panic(c087197f,c0854d72,c168bd00,c095c9e0,d629d9fc) at panic+0x156 if_simloop(c2cace00,c168bd00,2,0,1) at if_simloop+0xc5 looutput(c2cace00,c168bd00,c2c86290,c2f31400,14b) at looutput+0xde [] It looks very similar to http://www.freebsd.org/cgi/query-pr.cgi?pr=59576. You can revert to version 1.28 of net/bpf.h if you need tcpdump on lo, tun, ic, plip, disc or gif interface right now. Yuriy. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent current panic
On Wed, Nov 26, 2003 at 03:00:35PM +0300, ?? ? ?? wrote: i got a panic on recent -CURRENT: # tcpdump -i lo0 port 23 [1] 507 listening on lo0 This is a known bug; silby@ is working to fix lo and the rest of the affected network drivers. See PR kern/59576. Here's the local patch to if_loop.c I'm using until this gets fixed. I've patched if_tun.c similarly. Index: if_loop.c === RCS file: /home/ncvs/src/sys/net/if_loop.c,v retrieving revision 1.92 diff -u -r1.92 if_loop.c --- if_loop.c 20 Nov 2003 20:07:37 - 1.92 +++ if_loop.c 27 Nov 2003 08:18:33 - @@ -262,6 +262,7 @@ * will only read from the mbuf (i.e., it won't * try to free it or keep a pointer a to it). */ + bzero(m0, sizeof(m0)); m0.m_next = m; m0.m_len = 4; m0.m_data = (char *)af; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent current panic
On Thu, 27 Nov 2003, Yuriy Tsibizov wrote: Hi, i got a panic on recent -CURRENT: # tcpdump -i lo0 port 23 [1] 507 listening on lo0 # telnet localhost Trying ::1... Wed Nov 26 14:51:23 MSK 2003 Debugger+0x55: xchgl %ebx,in_Debugger.0 [] It looks very similar to http://www.freebsd.org/cgi/query-pr.cgi?pr=59576. You can revert to version 1.28 of net/bpf.h if you need tcpdump on lo, tun, ic, plip, disc or gif interface right now. just to note: I ran tcpdump on tunN (which was a pppoe interface) w/o problems two days ago (with a recent world) while debugging and testing other net related things. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent current panic
On Thursday 27 November 2003 06:38 am, Bjoern A. Zeeb wrote: On Thu, 27 Nov 2003, Yuriy Tsibizov wrote: Hi, i got a panic on recent -CURRENT: # tcpdump -i lo0 port 23 [1] 507 listening on lo0 # telnet localhost Trying ::1... Wed Nov 26 14:51:23 MSK 2003 Debugger+0x55: xchgl %ebx,in_Debugger.0 [] It looks very similar to http://www.freebsd.org/cgi/query-pr.cgi?pr=59576. You can revert to version 1.28 of net/bpf.h if you need tcpdump on lo, tun, ic, plip, disc or gif interface right now. just to note: I ran tcpdump on tunN (which was a pppoe interface) w/o problems two days ago (with a recent world) while debugging and testing other net related things. As was noted earlier, the issue is the addition of M_ASSERTVALID to the BPF_MTAP macro. This fails in numerous cases because existing practice was to allocate a fake mbuf on the stack for passing local data in to bpf. If this mbuf is not zero'd (or at least m_flags) then the assertion may trip. It's arguable what the correct solution is for these problems but you should be able to safely remove the assert until we can make a sweep over the drivers as the existing code has been around for a while (not to imply this makes it right :)). Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
recent current panic
i got a panic on recent -CURRENT: # tcpdump -i lo0 port 23 [1] 507 listening on lo0 # telnet localhost Trying ::1... Wed Nov 26 14:51:23 MSK 2003 Debugger+0x55: xchgl %ebx,in_Debugger.0 db tr Debugger(c0898daf,0,c087197f,d629d8dc,100) at Debugger+0x55 panic(c087197f,c0854d72,c168bd00,c095c9e0,d629d9fc) at panic+0x156 if_simloop(c2cace00,c168bd00,2,0,1) at if_simloop+0xc5 looutput(c2cace00,c168bd00,c2c86290,c2f31400,14b) at looutput+0xde ip_output(c168bd00,0,0,0,0) at ip_output+0xce1 tcp_output(c2f53000,c1687800,c08a4a60,29e,0) at tcp_output+0xcd0 tcp_usr_send(c2f23000,0,c1687800,0,0) at tcp_usr_send+0x1bd sosend(c2f23000,0,d629dc80,c1687800,0) at sosend+0x44d soo_write(c2dafd48,d629dc80,c310f280,0,c2caedc0) at soo_write+0x70 dofilewrite(c2caedc0,c2dafd48,0,805e640,2b) at dofilewrite+0xfb write(c2caedc0,d629dd14,c08b7a15,3ee,3) at write+0x6e syscall(2f,2f,2f,805f1a7,) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (4, FreeBSD ELF32, write), eip = 0x282c50af, esp = 0xbfbfe9ec, ebp = 0xbfbfea08 --- db ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent current panic
On Wednesday 26 November 2003 04:00 am,wrote: i got a panic on recent -CURRENT: # tcpdump -i lo0 port 23 [1] 507 listening on lo0 # telnet localhost Trying ::1... Wed Nov 26 14:51:23 MSK 2003 Debugger+0x55: xchgl %ebx,in_Debugger.0 db tr Debugger(c0898daf,0,c087197f,d629d8dc,100) at Debugger+0x55 panic(c087197f,c0854d72,c168bd00,c095c9e0,d629d9fc) at panic+0x156 if_simloop(c2cace00,c168bd00,2,0,1) at if_simloop+0xc5 looutput(c2cace00,c168bd00,c2c86290,c2f31400,14b) at looutput+0xde ip_output(c168bd00,0,0,0,0) at ip_output+0xce1 tcp_output(c2f53000,c1687800,c08a4a60,29e,0) at tcp_output+0xcd0 tcp_usr_send(c2f23000,0,c1687800,0,0) at tcp_usr_send+0x1bd sosend(c2f23000,0,d629dc80,c1687800,0) at sosend+0x44d soo_write(c2dafd48,d629dc80,c310f280,0,c2caedc0) at soo_write+0x70 dofilewrite(c2caedc0,c2dafd48,0,805e640,2b) at dofilewrite+0xfb write(c2caedc0,d629dd14,c08b7a15,3ee,3) at write+0x6e syscall(2f,2f,2f,805f1a7,) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (4, FreeBSD ELF32, write), eip = 0x282c50af, esp = 0xbfbfe9ec, ebp = 0xbfbfea08 --- Thanks, I've got a fix for this. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
recent current panic: ic: bio_offset 0 wrong, should be 16844800
Recent i386 CURRENT panic at boot diskless PC: Mounting root from nfs: NFS ROOT: 1.1.1.1:/i386/netboot Interface fxp0 IP-Address 1.1.1.2 Broadcast 1.1.1.255 Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point. Starting file system checks: cp: utmp: Read-only file system /etc/rc.d/cleanvar: cannot create /var/run/clean_var: Read-only file system +++ mount_md of /var +++ populate /var using /etc/mtree/BSD.var.dist +++ create log files based on the contents of /etc/newsyslog.conf +++ create lastlog ic: bio_offset 0 wrong, should be 16844800 Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db tr Debugger(c083a924,c08fc1c0,c084129f,d628b774,100) at Debugger+0x54 panic(c084129f,0,0,1010800,0) at panic+0xd5 dev_strategy(c79f59e0,0,8100,d628b7b0,c0614d68) at dev_strategy+0xb8 spec_freeblks(d628b808,d628b834,c0751488,d628b808,0) at spec_freeblks+0xb2 spec_vnoperate(d628b808,0,1008,0,2b3) at spec_vnoperate+0x18 ffs_blkfree(c2c46000,c2d9d618,2021,0,800) at ffs_blkfree+0x1e8 handle_workitem_freeblocks(c2d7a400,0,0,d628b918,0) at handle_workitem_freeblock s+0x328 softdep_setup_freeblocks(c2dd4230,0,0,800,c79f59e0) at softdep_setup_freeblocks+ 0x8a3 ffs_truncate(c2dfee38,0,0,0,c1672d00) at ffs_truncate+0x6ff handle_workitem_remove(c2ca7ee0,0,c2dd4230,1,d628bb8c) at handle_workitem_remove +0x1ab softdep_setup_remove(c79f4388,c2dd4ec4,c2dd4230,1,d628bbb4) at softdep_setup_rem ove+0xcc ufs_dirremove(c2de0e38,c2dd4230,800c,1,d628bbc0) at ufs_dirremove+0x16d ufs_rmdir(d628bc20,d628bccc,c06b4424,d628bc20,d628bc1c) at ufs_rmdir+0xef ufs_vnoperate(d628bc20,d628bc1c,2,c2ca6400,c08d2400) at ufs_vnoperate+0x18 kern_rmdir(c2c8ba00,bfbfef56,0,d628bd40,c07d0bb0) at kern_rmdir+0x1b4 rmdir(c2c8ba00,d628bd10,c0855704,3ee,1) at rmdir+0x22 syscall(2f,2f,2f,0,0) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (137, FreeBSD ELF32, rmdir), eip = 0x280bd1af, esp = 0xbfbfee7c, ebp = 0xbfbfee98 --- db Thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent current panic: ic: bio_offset 0 wrong, should be 16844800
This should be fixed now. In message [EMAIL PROTECTED], Alex Deiter writes: Recent i386 CURRENT panic at boot diskless PC: Mounting root from nfs: NFS ROOT: 1.1.1.1:/i386/netboot Interface fxp0 IP-Address 1.1.1.2 Broadcast 1.1.1.255 Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point. Starting file system checks: cp: utmp: Read-only file system /etc/rc.d/cleanvar: cannot create /var/run/clean_var: Read-only file system +++ mount_md of /var +++ populate /var using /etc/mtree/BSD.var.dist +++ create log files based on the contents of /etc/newsyslog.conf +++ create lastlog ic: bio_offset 0 wrong, should be 16844800 Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db tr Debugger(c083a924,c08fc1c0,c084129f,d628b774,100) at Debugger+0x54 panic(c084129f,0,0,1010800,0) at panic+0xd5 dev_strategy(c79f59e0,0,8100,d628b7b0,c0614d68) at dev_strategy+0xb8 spec_freeblks(d628b808,d628b834,c0751488,d628b808,0) at spec_freeblks+0xb2 spec_vnoperate(d628b808,0,1008,0,2b3) at spec_vnoperate+0x18 ffs_blkfree(c2c46000,c2d9d618,2021,0,800) at ffs_blkfree+0x1e8 handle_workitem_freeblocks(c2d7a400,0,0,d628b918,0) at handle_workitem_freeblock s+0x328 softdep_setup_freeblocks(c2dd4230,0,0,800,c79f59e0) at softdep_setup_freeblocks+ 0x8a3 ffs_truncate(c2dfee38,0,0,0,c1672d00) at ffs_truncate+0x6ff handle_workitem_remove(c2ca7ee0,0,c2dd4230,1,d628bb8c) at handle_workitem_remove +0x1ab softdep_setup_remove(c79f4388,c2dd4ec4,c2dd4230,1,d628bbb4) at softdep_setup_rem ove+0xcc ufs_dirremove(c2de0e38,c2dd4230,800c,1,d628bbc0) at ufs_dirremove+0x16d ufs_rmdir(d628bc20,d628bccc,c06b4424,d628bc20,d628bc1c) at ufs_rmdir+0xef ufs_vnoperate(d628bc20,d628bc1c,2,c2ca6400,c08d2400) at ufs_vnoperate+0x18 kern_rmdir(c2c8ba00,bfbfef56,0,d628bd40,c07d0bb0) at kern_rmdir+0x1b4 rmdir(c2c8ba00,d628bd10,c0855704,3ee,1) at rmdir+0x22 syscall(2f,2f,2f,0,0) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (137, FreeBSD ELF32, rmdir), eip = 0x280bd1af, esp = 0xbfbfee7c, ebp = 0xbfbfee98 --- db Thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Recent -CURRENT panic (New interrupt code related?); backtrace included
Yes I have device apic enabled, and after setting options NO_MIXED_MODE, the problem persists. However, fortunatelly, the spurious.patch seemed to solved the problem, and the system has been up for 9 hours without panic'ing as I described before. Do you need me to test atpic.patch as well? -Original Message- From: John Baldwin [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 12:29 AM To: Xin LI/ Cc: [EMAIL PROTECTED] Subject: RE: Recent -CURRENT panic (New interrupt code related?); backtrace included Do you have 'device apic' enabled? If so, can you try using 'options NO_MIXED_MODE'. Barring that, can you try http://www.FreeBSD.org/~jhb/patches/spurious.patch and if that doesn't work http://www.FreeBSD.org/~jhb/patches/atpic.patch? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Recent -CURRENT panic (New interrupt code related?); backtrace included
On 13-Nov-2003 Xin LI/ÀîöÎ wrote: Yes I have device apic enabled, and after setting options NO_MIXED_MODE, the problem persists. However, fortunatelly, the spurious.patch seemed to solved the problem, and the system has been up for 9 hours without panic'ing as I described before. Do you need me to test atpic.patch as well? No, that is fine, thanks. I will have a better patch later today that should hopefully work both with and without mixed mode. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Recent -CURRENT panic (New interrupt code related?); backtrace included
On 12-Nov-2003 Xin LI/李鑫 wrote: Hello, On recently compiled kernels, I often get panics which seemed to be interrupt related. Among other things, almost all of them claims that Kernel trap 30, which seemd to be strange. The kernel I am currently running, namely, FreeBSD servers.frontfree.net 5.1-CURRENT FreeBSD 5.1-CURRENT #5: Sat Oct 25 22:27:05 CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVERS i386 seemed to be ok, however, when I am trying the new kernels (you see, 14 compile and run attempts:), it exhibits incredible instablity. FreeBSD 5.1-CURRENT #19: Wed Nov 12 12:17:28 CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVERS Here is one of the crashdumps I caught. The machine was configured with a UP kernel, with DEVICE_POLLING enabled. There are two networking adapters attached to it, a fxp and a dc, and the machine itself act as a NAT gateway. The network load is not very heavy. If you think the backtrace helpful, or need any more information, please write me and I will try everything I can to help. Do you have 'device apic' enabled? If so, can you try using 'options NO_MIXED_MODE'. Barring that, can you try http://www.FreeBSD.org/~jhb/patches/spurious.patch and if that doesn't work http://www.FreeBSD.org/~jhb/patches/atpic.patch? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Recent -CURRENT panic (New interrupt code related?); backtrace included
Hello,
On recently compiled kernels, I often get panics which seemed to be interrupt related.
Among other things, almost all of them claims that Kernel trap 30, which seemd to be
strange.
The kernel I am currently running, namely,
FreeBSD servers.frontfree.net 5.1-CURRENT FreeBSD 5.1-CURRENT #5: Sat Oct 25 22:27:05
CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVERS i386
seemed to be ok, however, when I am trying the new kernels (you see, 14 compile and
run attempts:), it exhibits incredible instablity.
FreeBSD 5.1-CURRENT #19: Wed Nov 12 12:17:28 CST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVERS
Here is one of the crashdumps I caught. The machine was configured with a UP kernel,
with DEVICE_POLLING enabled. There are two networking adapters attached to it, a fxp
and a dc, and the machine itself act as a NAT gateway. The network load is not very
heavy. If you think the backtrace helpful, or need any more information, please write
me and I will try everything I can to help.
servers# gdb -k /usr/obj/usr/src/sys/SERVERS/kernel.debug vmcore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: from debugger
panic messages:
---
panic: from debugger
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc0639654
stack pointer = 0x10:0xc6305a98
frame pointer = 0x10:0xc6305aa4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 11 (idle)
panic: from debugger
Uptime: 23m22s
Dumping 63 MB
16 32 48
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc04e8b41 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc04e8ed7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0464252 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc04641b2 in db_command (last_cmdp=0xc06cc440, cmd_table=0x0,
aux_cmd_tablep=0xc069d338,
aux_cmd_tablep_end=0xc069d33c) at /usr/src/sys/ddb/db_command.c:346
#5 0xc04642f5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc04672e5 in db_trap (type=30, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc063939c in kdb_trap (type=30, code=0, regs=0xc6305ca0) at
/usr/src/sys/i386/i386/db_interface.c:171
#8 0xc064cda6 in trap_fatal (frame=0xc6305ca0, eva=0) at
/usr/src/sys/i386/i386/trap.c:816
#9 0xc064c822 in trap (frame=
{tf_fs = 24, tf_es = 1075970064, tf_ds = -1636237296, tf_edi = 0, tf_esi =
-1059059840, tf_ebp = -969909024, tf_isp = -969909044, tf_ebx = -1059063048, tf_edx =
0, tf_ecx = 2, tf_eax = 0, tf_trapno = 30, tf_err = 0, tf_eip = -1067175531, tf_cs =
8, tf_eflags = 582, tf_esp = -969909016, tf_ss = -1067175489})
at /usr/src/sys/i386/i386/trap.c:618
#10 0xc063ad58 in calltrap () at {standard input}:94
#11 0xc06431bf in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:1071
#12 0xc04d449c in idle_proc (dummy=0x0) at /usr/src/sys/kern/kern_idle.c:86
#13 0xc04d41d4 in fork_exit (callout=0xc04d4460 idle_proc, arg=0x0, frame=0x0)
at /usr/src/sys/kern/kern_fork.c:793
(kgdb) bt full
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
No locals.
#1 0xc04e8b41 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
No locals.
#2 0xc04e8ed7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
td = (struct thread *) 0xc0e00780
bootopt = 260
newpanic = 0
ap = 0xc6305ae0 \230[0AF2251d?
buf = from debugger, '\0' repeats 242 times
#3 0xc0464252 in db_panic () at /usr/src/sys/ddb/db_command.c:450
No locals.
#4 0xc04641b2 in db_command (last_cmdp=0xc06cc440, cmd_table=0x0,
aux_cmd_tablep=0xc069d338,
aux_cmd_tablep_end=0xc069d33c) at /usr/src/sys/ddb/db_command.c:346
cmd = (struct command *) 0xc06658c0
t = 0
modif =
\0\231r?[0r\0\0\0qr\0\0\0\001\0\0\0H[0200\214qaK\0
$rp\0\0\0l\231r[0`F\234h200^F0\0\0\0\020\0\0\0h\231rWF200\0\0\0\020\0\0
addr = -1067175531
count = -1
have_addr = 0
result = 0
#5 0xc04642f5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
No locals.
#6 0xc04672e5 in db_trap (type=30, code=0) at /usr/src/sys/ddb/db_trap.c:73
bkpt = 0
#7 0xc063939c in kdb_trap (type=30, code=0, regs=0xc6305ca0) at
/usr/src/sys/i386/i386/db_interface.c:171
ef = 582
ddb_mode = 1
#8 0xc064cda6 in trap_fatal (frame=0xc6305ca0, eva=0) at
/usr/src/sys/i386/i386/trap.c:816
code = 16
type = 30
ss =
recent -CURRENT panic: trap: memory address not aligned
Got folowing panic on Netra T1 sparc64: Timecounters tick every 10.000 msec panic: trap: memory address not aligned Debugger(panic) Stopped at Debugger+0x1c: ta %xcc, 1 db trace panic() at panic+0xf0 trap() at trap+0x394 -- memory address not aligned sfar=0xc037e7c1 sfsr=0x40029 %o7=0xc00d2740 -- rijndael_blockEncrypt() at rijndael_blockEncrypt+0xe4 yarrow_encrypt() at yarrow_encrypt+0x14 read_random_real() at read_random_real+0x88 read_random() at read_random+0x10 arc4_randomstir() at arc4_randomstir+0x8 arc4rand() at arc4rand+0x40 arc4random() at arc4random+0xc syncache_init() at syncache_init+0x30 tcp_init() at tcp_init+0x250 net_init_domain() at net_init_domain+0x78 net_add_domain() at net_add_domain+0x44 mi_startup() at mi_startup+0x12c btext() at btext+0x34 Thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent -CURRENT panic: trap: memory address not aligned
On Wed, Oct 15, 2003 at 12:04:57PM +0400, ?? ? ?? wrote: Got folowing panic on Netra T1 sparc64: Timecounters tick every 10.000 msec panic: trap: memory address not aligned Debugger(panic) Stopped at Debugger+0x1c: ta %xcc, 1 db trace panic() at panic+0xf0 trap() at trap+0x394 -- memory address not aligned sfar=0xc037e7c1 sfsr=0x40029 %o7=0xc00d2740 -- rijndael_blockEncrypt() at rijndael_blockEncrypt+0xe4 I think that's due to a recent commit of ume. It might not yet be fixed. Kris pgp0.pgp Description: PGP signature
Re: recent -CURRENT panic: trap: memory address not aligned
I think that's due to a recent commit of ume. It might not yet be fixed. I'm sorry, my src/sys/crypto/rijndael/rijndael-api-fst.c have a version 1.8. But last commit ume: Fix alignment problem on 64 bit arch. I only tested if it doesn't break anything on i368. Since I have no 64 bit machine, I cannot test it, actually. Reported by:jmallett Revision ChangesPath 1.9 +49 -0 src/sys/crypto/rijndael/rijndael-api-fst.c Thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent -CURRENT panic: trap: memory address not aligned
On Wed, Oct 15, 2003 at 01:13:17PM +0400, ?? ? ?? wrote: I think that's due to a recent commit of ume. It might not yet be fixed. I'm sorry, my src/sys/crypto/rijndael/rijndael-api-fst.c have a version 1.8. But last commit ume: Fix alignment problem on 64 bit arch. I only tested if it doesn't break anything on i368. Since I have no 64 bit machine, I cannot test it, actually. Reported by:jmallett Revision ChangesPath 1.9 +49 -0 src/sys/crypto/rijndael/rijndael-api-fst.c Thanks! Yes, and it was claimed by someone else that this approach doesn't actually fix the alignment problem. Kris pgp0.pgp Description: PGP signature
