Re: a panic on uart_z8530_class?
On Sat, May 8, 2010 at 10:27 PM, Yuri Pankov wrote: > On Sat, May 08, 2010 at 09:59:23PM -0500, Brandon Gooch wrote: >> On Sat, May 8, 2010 at 3:35 PM, ben wilber wrote: >> > On Sat, May 08, 2010 at 04:11:49PM -0400, Benjamin Kaduk wrote: >> >> > [r...@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 >> >> > 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 "amd64-marcel-freebsd"... >> >> > Cannot access memory at address 0xff0127e0 >> >> > (kgdb) bt >> >> > #0 0x in ?? () >> >> > Cannot access memory at address 0x0 >> >> > (kgdb) q >> >> >> >> >> >> I have seen this behavior from kgdb --- it doesn't seem to be able to >> >> handle coredumps I've made recently. At first I thought that I managed to >> >> trash either my kernel image or kgdb binary with all the unclean >> >> shutdowns I've been having, but if you're seeing kgdb failures, maybe it's >> >> not just my local system. >> >> >> >> Yet I am assuming that this is not broken for *everyone*, or we would have >> >> heard more noise about it. >> >> >> >> I'm running a current snapshot from April 4th; maybe I will try updating >> >> to a new snapshot tonight and see if kgdb behaves better after everything >> >> is rebuilt. >> > >> > Same here, for the last couple months maybe. >> >> I'll chime in here with a "me too". >> >> Since at early April, I've been trying to figure out why my laptop >> locks up overnight (something about the CPUs going into C3). I can >> nearly always get it to coredump, but the vmcore files I generate are >> unusable... >> >> -Brandon > > Just another "me too". May be we have something common in our setup? > (I'm dumping to /dev/gpt/swap 8Gb GPT partition, using ahci(4) on a ATI > IXP700 AHCI SATA controller). > > Another issue - dump is written extremely slow (1.5Gb in ~5 minutes). I'm dumping to /dev/gpt/swap0 and yes, the dump is VERY slow. I've only recently began doing dumps, so I have little to compare the experience to -- although it does seem to have been slowing down now for a while :( I'm actually in the middle of doadump() right now, and it's been about 4 minutes, and I'm not even halfway done... --Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: a panic on uart_z8530_class?
On Sun, 9 May 2010, Yuri Pankov wrote: On Sat, May 08, 2010 at 09:59:23PM -0500, Brandon Gooch wrote: Since at early April, I've been trying to figure out why my laptop locks up overnight (something about the CPUs going into C3). I can nearly always get it to coredump, but the vmcore files I generate are unusable... My cores are not *completely* unuseable -- I can (e.g.) walk the process tree starting at allproc, and things look sane, but kgdb's 'proc' command claims that all PIDs are invalid, and doesn't give me backtraces. -Brandon Just another "me too". May be we have something common in our setup? (I'm dumping to /dev/gpt/swap 8Gb GPT partition, using ahci(4) on a ATI IXP700 AHCI SATA controller). Another issue - dump is written extremely slow (1.5Gb in ~5 minutes). I am more inclined to believe that this is a kgdb bug than a problem with the dump itself, but I am running on atapci0: AHCI v1.20 (Intel ICH9 family). (Old-ish) dmesg and pciconf may be found in http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/glossolalia/ -Ben ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: a panic on uart_z8530_class?
On Sat, May 08, 2010 at 09:59:23PM -0500, Brandon Gooch wrote: > On Sat, May 8, 2010 at 3:35 PM, ben wilber wrote: > > On Sat, May 08, 2010 at 04:11:49PM -0400, Benjamin Kaduk wrote: > >> > [r...@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 > >> > 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 "amd64-marcel-freebsd"... > >> > Cannot access memory at address 0xff0127e0 > >> > (kgdb) bt > >> > #0 0x in ?? () > >> > Cannot access memory at address 0x0 > >> > (kgdb) q > >> > >> > >> I have seen this behavior from kgdb --- it doesn't seem to be able to > >> handle coredumps I've made recently. At first I thought that I managed to > >> trash either my kernel image or kgdb binary with all the unclean > >> shutdowns I've been having, but if you're seeing kgdb failures, maybe it's > >> not just my local system. > >> > >> Yet I am assuming that this is not broken for *everyone*, or we would have > >> heard more noise about it. > >> > >> I'm running a current snapshot from April 4th; maybe I will try updating > >> to a new snapshot tonight and see if kgdb behaves better after everything > >> is rebuilt. > > > > Same here, for the last couple months maybe. > > I'll chime in here with a "me too". > > Since at early April, I've been trying to figure out why my laptop > locks up overnight (something about the CPUs going into C3). I can > nearly always get it to coredump, but the vmcore files I generate are > unusable... > > -Brandon Just another "me too". May be we have something common in our setup? (I'm dumping to /dev/gpt/swap 8Gb GPT partition, using ahci(4) on a ATI IXP700 AHCI SATA controller). Another issue - dump is written extremely slow (1.5Gb in ~5 minutes). Yuri ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: a panic on uart_z8530_class?
On Sat, May 8, 2010 at 3:35 PM, ben wilber wrote: > On Sat, May 08, 2010 at 04:11:49PM -0400, Benjamin Kaduk wrote: >> > [r...@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 >> > 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 "amd64-marcel-freebsd"... >> > Cannot access memory at address 0xff0127e0 >> > (kgdb) bt >> > #0 0x in ?? () >> > Cannot access memory at address 0x0 >> > (kgdb) q >> >> >> I have seen this behavior from kgdb --- it doesn't seem to be able to >> handle coredumps I've made recently. At first I thought that I managed to >> trash either my kernel image or kgdb binary with all the unclean >> shutdowns I've been having, but if you're seeing kgdb failures, maybe it's >> not just my local system. >> >> Yet I am assuming that this is not broken for *everyone*, or we would have >> heard more noise about it. >> >> I'm running a current snapshot from April 4th; maybe I will try updating >> to a new snapshot tonight and see if kgdb behaves better after everything >> is rebuilt. > > Same here, for the last couple months maybe. I'll chime in here with a "me too". Since at early April, I've been trying to figure out why my laptop locks up overnight (something about the CPUs going into C3). I can nearly always get it to coredump, but the vmcore files I generate are unusable... -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: a panic on uart_z8530_class?
On Sat, 8 May 2010, Weongyo Jeong wrote: Hello, Anyone encountered this panic on recent CURRENT kernel? [r...@test ~]# uname -a FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Sun May 2 00:24:12 PDT 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 [r...@test /home/freebsd/sys/modules/bwn]# ifconfig wlan0 create wlandev bwn0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xff8073cdd810 frame pointer = 0x28:0xff8073cdd8e0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1795 (ifconfig) [ thread pid 1795 tid 100096 ] Stopped at 0: *** error reading from address 0 *** db> bt Tracing pid 1795 tid 100096 td 0xff0003d8b390 uart_z8530_class() at 0 ifc_simple_create() at ifc_simple_create+0x89 if_clone_createif() at if_clone_createif+0x64 ifioctl() at ifioctl+0x685 can you give me l *ifc_simple_create+0x89 l *if_clone_createif+0x64 l *ifioctl+0x685 -- Bjoern A. Zeeb (from 21) Micky Rosa: But as we've all said, this game is about the past and the future, and tonight we forget about the past. We just focus on the future. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: a panic on uart_z8530_class?
On Sat, May 08, 2010 at 04:11:49PM -0400, Benjamin Kaduk wrote: > > [r...@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 > > 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 "amd64-marcel-freebsd"... > > Cannot access memory at address 0xff0127e0 > > (kgdb) bt > > #0 0x in ?? () > > Cannot access memory at address 0x0 > > (kgdb) q > > > I have seen this behavior from kgdb --- it doesn't seem to be able to > handle coredumps I've made recently. At first I thought that I managed to > trash either my kernel image or kgdb binary with all the unclean > shutdowns I've been having, but if you're seeing kgdb failures, maybe it's > not just my local system. > > Yet I am assuming that this is not broken for *everyone*, or we would have > heard more noise about it. > > I'm running a current snapshot from April 4th; maybe I will try updating > to a new snapshot tonight and see if kgdb behaves better after everything > is rebuilt. Same here, for the last couple months maybe. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: a panic on uart_z8530_class?
On May 8, 2010, at 1:00 PM, Weongyo Jeong wrote: > Hello, > > Anyone encountered this panic on recent CURRENT kernel? > > [r...@test ~]# uname -a > FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Sun May 2 00:24:12 PDT > 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 > > [r...@test /home/freebsd/sys/modules/bwn]# ifconfig wlan0 create wlandev bwn0 > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read instruction, page not present > instruction pointer = 0x20:0x0 > stack pointer = 0x28:0xff8073cdd810 > frame pointer = 0x28:0xff8073cdd8e0 > code segment= base 0x0, limit 0xf, type 0x1b >= DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 1795 (ifconfig) > [ thread pid 1795 tid 100096 ] > Stopped at 0: *** error reading from address 0 *** > db> bt > Tracing pid 1795 tid 100096 td 0xff0003d8b390 > uart_z8530_class() at 0 > ifc_simple_create() at ifc_simple_create+0x89 > if_clone_createif() at if_clone_createif+0x64 > ifioctl() at ifioctl+0x685 > kern_ioctl() at kern_ioctl+0xc5 > ioctl() at ioctl+0xfd > syscall() at syscall+0x102 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b86d0c, rsp = > 0x7fffe2e8, rbp = 0x7fffee36 --- I think what you have is a simple NULL function pointer dereference (i.e. calling a function pointer that's NULL). The uart_z8530_class shows first in the backtrace because that symbol has address 0 (it's weak and you typically don't have the Z8530 SCC driver on amd64), so it's being returned when DDB looks up symbols at address 0. This then implies that ifc_simple_create() called a NULL function pointer. FYI, -- Marcel Moolenaar xcl...@mac.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: a panic on uart_z8530_class?
On Sat, May 08, 2010 at 01:00:32PM -0700, Weongyo Jeong wrote: > Hello, > > Anyone encountered this panic on recent CURRENT kernel? > > [r...@test ~]# uname -a > FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Sun May 2 00:24:12 PDT > 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 > > [r...@test /home/freebsd/sys/modules/bwn]# ifconfig wlan0 create wlandev bwn0 > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read instruction, page not present > instruction pointer = 0x20:0x0 > stack pointer = 0x28:0xff8073cdd810 > frame pointer = 0x28:0xff8073cdd8e0 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 1795 (ifconfig) > [ thread pid 1795 tid 100096 ] > Stopped at 0: *** error reading from address 0 *** > db> bt > Tracing pid 1795 tid 100096 td 0xff0003d8b390 > uart_z8530_class() at 0 uartXXX there is collateral, actual panic happen in the ifc_simple_create(). > ifc_simple_create() at ifc_simple_create+0x89 > if_clone_createif() at if_clone_createif+0x64 > ifioctl() at ifioctl+0x685 > kern_ioctl() at kern_ioctl+0xc5 > ioctl() at ioctl+0xfd > syscall() at syscall+0x102 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b86d0c, rsp = > 0x7fffe2e8, rbp = 0x7fffee36 --- > db> call doadump > Physical memory: 3916 MB > Dumping 1239 MB: 1224 1208 1192 1176 1160 1144 1128 1112 1096 1080 1064 1048 > 1032 1016 1000 984 968 952 936 920 904 888 872 856 840 824 808 792 776 760 > 744 728 712 696 680 664 648 632 616 600 584 568 552 536 520 504 488 472 456 > 440 424 408 392 376 360 344 328 312 296 280 264 248 232 216 200 184 168 152 > 136 120 104 88 72 56 40 24 8 > Dump complete > = 0 > db> reset > > [r...@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 > 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 "amd64-marcel-freebsd"... > Cannot access memory at address 0xff0127e0 > (kgdb) bt > #0 0x in ?? () > Cannot access memory at address 0x0 > (kgdb) q > > regards, > Weongyo Jeong > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" pgp4CisxNoGtU.pgp Description: PGP signature
Re: a panic on uart_z8530_class?
On Sat, 8 May 2010, Weongyo Jeong wrote: Hello, Anyone encountered this panic on recent CURRENT kernel? db> bt Tracing pid 1795 tid 100096 td 0xff0003d8b390 uart_z8530_class() at 0 ifc_simple_create() at ifc_simple_create+0x89 if_clone_createif() at if_clone_createif+0x64 ifioctl() at ifioctl+0x685 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b86d0c, rsp = 0x7fffe2e8, rbp = 0x7fffee36 --- I haven't seen that particular panic, but I have seen uart_z8530_class (or something superficially similar to it) in stack traces that I can't see touching a uart device. [r...@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 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 "amd64-marcel-freebsd"... Cannot access memory at address 0xff0127e0 (kgdb) bt #0 0x in ?? () Cannot access memory at address 0x0 (kgdb) q I have seen this behavior from kgdb --- it doesn't seem to be able to handle coredumps I've made recently. At first I thought that I managed to trash either my kernel image or kgdb binary with all the unclean shutdowns I've been having, but if you're seeing kgdb failures, maybe it's not just my local system. Yet I am assuming that this is not broken for *everyone*, or we would have heard more noise about it. I'm running a current snapshot from April 4th; maybe I will try updating to a new snapshot tonight and see if kgdb behaves better after everything is rebuilt. -Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
a panic on uart_z8530_class?
Hello, Anyone encountered this panic on recent CURRENT kernel? [r...@test ~]# uname -a FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Sun May 2 00:24:12 PDT 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 [r...@test /home/freebsd/sys/modules/bwn]# ifconfig wlan0 create wlandev bwn0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xff8073cdd810 frame pointer = 0x28:0xff8073cdd8e0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1795 (ifconfig) [ thread pid 1795 tid 100096 ] Stopped at 0: *** error reading from address 0 *** db> bt Tracing pid 1795 tid 100096 td 0xff0003d8b390 uart_z8530_class() at 0 ifc_simple_create() at ifc_simple_create+0x89 if_clone_createif() at if_clone_createif+0x64 ifioctl() at ifioctl+0x685 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b86d0c, rsp = 0x7fffe2e8, rbp = 0x7fffee36 --- db> call doadump Physical memory: 3916 MB Dumping 1239 MB: 1224 1208 1192 1176 1160 1144 1128 1112 1096 1080 1064 1048 1032 1016 1000 984 968 952 936 920 904 888 872 856 840 824 808 792 776 760 744 728 712 696 680 664 648 632 616 600 584 568 552 536 520 504 488 472 456 440 424 408 392 376 360 344 328 312 296 280 264 248 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Dump complete = 0 db> reset [r...@test ~]# kgdb /boot/kernel/kernel /var/crash/vmcore.1 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 "amd64-marcel-freebsd"... Cannot access memory at address 0xff0127e0 (kgdb) bt #0 0x in ?? () Cannot access memory at address 0x0 (kgdb) q regards, Weongyo Jeong ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
