Re: Change in loader or kernel: won't boot with kfreebsd in grub2
> On Sat, Aug 24, 2013 at 08:53:31PM -0700, Thomas Mueller wrote: > > Some updates: > > I could see what happens if I try to boot the FreeBSD boot partition on the > > hard drive using the Super Grub Disk with chainloader. > > If that works, it would boot FreeBSD 9.0-BETA1, but I would see if it works. > > That failed (invalid signature). > You probably need to chainload a freebsd-boot partition, _if_ you > want to chainload at all. I was trying to chainload the freebsd-boot partition! But grub2 didn't like it. > > I could also try > > kfreebsd /boot/kernel/kernel > > That failed to boot the proper partition, went to the debugger (db>), > > whereupon all I could type was "reboot". > You didn't get a mountroot prompt? If you did you can try typing a > question mark and return, that should list possible partitions to mount > root from. If you didn't, or you don't want to do this manually you > need to set kFreeBSD.vfs.root.mountfrom=ufs:/dev/ada0p1 from grub2, > or wherever your root partition is. I remember pressing a key, but then the system rushed past the mountroot prompt into the debugger prompt. > > Now can I safely install boot into the partition to be booted, as I did > > with NetBSD on USB stick? > > gpart -p /boot/boot -i 3 > > That would be for /dev/ada0p3, but I am afraid of damaging something. > That would need to be on a freebsd-boot partition, and you want > /boot/gptboot not /boot/boot. I believe bsdlabel can be used to install boot code to a partition, but believe that is not for GPT. I could try bsdlabel on a giant floppy image as I used installboot on a giant floppy image for NetBSD. > Tom > HTH, > Juergen Tom ___ 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: Change in loader or kernel: won't boot with kfreebsd in grub2
On Sat, Aug 24, 2013 at 08:53:31PM -0700, Thomas Mueller wrote: > Some updates: > > I could see what happens if I try to boot the FreeBSD boot partition on the > hard drive using the Super Grub Disk with chainloader. > > If that works, it would boot FreeBSD 9.0-BETA1, but I would see if it works. > > That failed (invalid signature). > You probably need to chainload a freebsd-boot partition, _if_ you want to chainload at all. > I could also try > kfreebsd /boot/kernel/kernel > > That failed to boot the proper partition, went to the debugger (db>), > whereupon all I could type was "reboot". > You didn't get a mountroot prompt? If you did you can try typing a question mark and return, that should list possible partitions to mount root from. If you didn't, or you don't want to do this manually you need to set kFreeBSD.vfs.root.mountfrom=ufs:/dev/ada0p1 from grub2, or wherever your root partition is. > Now can I safely install boot into the partition to be booted, as I did with > NetBSD on USB stick? > > gpart -p /boot/boot -i 3 > > That would be for /dev/ada0p3, but I am afraid of damaging something. > That would need to be on a freebsd-boot partition, and you want /boot/gptboot not /boot/boot. > Tom > HTH, Juergen ___ 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"
[panic] vm_page_unwire: page 0xfffffe02377e42a0's wire count is zero
Finally I got some hard data in the "stopping amd causes a freeze" case. I turned off xdm and reproduced the panic a couple of times by creating high tmpfs load (building chromium on tmpfs) and sending SIGTERM to amd. I got a couple of panics that produced many screens of output but instantly rebooted. Note that nothing was actually mounted by amd, when SIGTERM was sent. But once the system froze instead. I took a picture, but it turned out I was actually rewarded with a textdump, which I am willing to mail to all interested parties. I still don't get cores (the system is set up for minidumps), but that's much better than just saying that the system freezes/reboots when I do a, b and c. Any way, here is the juice: FreeBSD 9.2-PRERELEASE #0 r254857: Sun Aug 25 16:28:26 CEST 2013 root@mobileKamikaze.norad:/usr/obj/HP6510b-9/amd64/usr/src/sys/HP6510b-9 db:0:kdb.enter.panic> run lockinfo db:1:lockinfo> show locks No such command db:1:locks> show alllocks No such command db:1:alllocks> show lockedvnods Locked vnodes db:0:kdb.enter.panic> show pcpu cpuid= 1 dynamic pcpu = 0xff807ee89280 curthread= 0xfe01c80fd490: pid 3070 "amd" curpcb = 0xff824f85ad00 fpcurthread = 0xfe01c80fd490: pid 3070 "amd" idlethread = 0xfe000521b000: tid 14 "idle: cpu1" curpmap = 0x813f1e18 tssp = 0x8145fb68 commontssp = 0x8145fb68 rsp0 = 0xff824f85ad00 gs32p= 0x8145dca0 ldt = 0x8145dce0 tss = 0x8145dcd0 db:0:kdb.enter.panic> bt Tracing pid 3070 tid 100138 td 0xfe01c80fd490 kdb_enter() at kdb_enter+0x3b/frame 0xff824f85a850 panic() at panic+0x1c6/frame 0xff824f85a950 vm_page_unwire() at vm_page_unwire+0xf5/frame 0xff824f85a980 vm_fault_unwire() at vm_fault_unwire+0xb2/frame 0xff824f85a9c0 vm_map_delete() at vm_map_delete+0xcf/frame 0xff824f85aa30 vm_map_remove() at vm_map_remove+0x59/frame 0xff824f85aa60 vmspace_exit() at vmspace_exit+0xc7/frame 0xff824f85aa90 exit1() at exit1+0x3e0/frame 0xff824f85ab00 sys_sys_exit() at sys_sys_exit+0xe/frame 0xff824f85ab10 amd64_syscall() at amd64_syscall+0x5ea/frame 0xff824f85ac30 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff824f85ac30 --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x800af5b3c, rsp = 0x7fffd8c8, rbp = 0x7fffdaa8 --- -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: patch to improve AES-NI performance
According to Ollivier Robert: > You are right, I wanted to say r226837 which is the "code" one. FYI I've finally merged r226837,r226839 as r254856 in stable/9 as it is a prerequesite to apply jmg's patch. I've asked re@ whether they would consider this for 9.2. It is very late in the 9.2 release circle but that patch has been in 10 for more than a year now... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ ___ 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: NFS deadlock on 9.2-Beta1
On Sun, Aug 25, 2013 at 7:42 AM, Adrian Chadd wrote: > Does -HEAD have this same problem? If I understood kib@ correctly, this is fixed in -HEAD by r253927. > If so, we should likely just revert the patch entirely from -HEAD and -9 > until it's resolved. It was not too difficult to prepare a releng/9.2 build with r254754 reverted (reverting the revert) and then applying kib@'s suggested backport fix. So far that is running on 9 nodes with no reported problems, but only since last night. We were hesitant to do the significant work involved to push it out to dozens of nodes if nobody was going to consider it for 9.2 anyway. Thanks! ___ 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: NFS deadlock on 9.2-Beta1
Michael Tratz wrote: > > On Aug 15, 2013, at 2:39 PM, Rick Macklem > wrote: > > > Michael Tratz wrote: > >> > >> On Jul 27, 2013, at 11:25 PM, Konstantin Belousov > >> wrote: > >> > >>> On Sat, Jul 27, 2013 at 03:13:05PM -0700, Michael Tratz wrote: > Let's assume the pid which started the deadlock is 14001 (it > will > be a different pid when we get the results, because the machine > has been restarted) > > I type: > > show proc 14001 > > I get the thread numbers from that output and type: > > show thread x > > for each one. > > And a trace for each thread with the command? > > tr > > Anything else I should try to get or do? Or is that not the data > at all you are looking for? > > >>> Yes, everything else which is listed in the 'debugging deadlocks' > >>> page > >>> must be provided, otherwise the deadlock cannot be tracked. > >>> > >>> The investigator should be able to see the whole deadlock chain > >>> (loop) > >>> to make any useful advance. > >> > >> Ok, I have made some excellent progress in debugging the NFS > >> deadlock. > >> > >> Rick! You are genius. :-) You found the right commit r250907 > >> (dated > >> May 22) is the definitely the problem. > >> > >> Here is how I did the testing: One machine received a kernel > >> before > >> r250907, the second machine received a kernel after r250907. Sure > >> enough within a few hours the machine with r250907 went into the > >> usual deadlock state. The machine without that commit kept on > >> working fine. Then I went back to the latest revision (r253726), > >> but > >> leaving r250907 out. The machines have been running happy and rock > >> solid without any deadlocks. I have expanded the testing to 3 > >> machines now and no reports of any issues. > >> > >> I guess now Konstantin has to figure out why that commit is > >> causing > >> the deadlock. Lovely! :-) I will get that information as soon as > >> possible. I'm a little behind with normal work load, but I expect > >> to > >> have the data by Tuesday evening or Wednesday. > >> > > Have you been able to pass the debugging info on to Kostik? > > > > It would be really nice to get this fixed for FreeBSD9.2. > > > > Thanks for your help with this, rick > > Sorry Rick, I wasn't able to get you guys that info quickly enough. I > thought I would have enough time, before my own wedding and > honeymoon came along, but everything went a little crazy and > stressful. I didn't think it would be this nuts. :-) > > I'm caught up with everything and from what I can see from the > discussions is that we know now what the problem is. > > I can report that the machines which I have had without r250907 have > been running without any problems for 27+ days. > > If you need me to test any new patches, please let me know. If I > should test with the partial merge of r253927 I'll be happy to do > so. > It's up to you, but you might want to wait until the other tester (J. David?) reports back on success/failure. Thanks for your help with this, rick > Thanks, > > Michael > > > > > ___ 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: NFS deadlock on 9.2-Beta1
Hi, Does -HEAD have this same problem? If so, we should likely just revert the patch entirely from -HEAD and -9 until it's resolved. -adrian On 24 August 2013 23:51, Michael Tratz wrote: > > On Aug 15, 2013, at 2:39 PM, Rick Macklem wrote: > > > Michael Tratz wrote: > >> > >> On Jul 27, 2013, at 11:25 PM, Konstantin Belousov > >> wrote: > >> > >>> On Sat, Jul 27, 2013 at 03:13:05PM -0700, Michael Tratz wrote: > Let's assume the pid which started the deadlock is 14001 (it will > be a different pid when we get the results, because the machine > has been restarted) > > I type: > > show proc 14001 > > I get the thread numbers from that output and type: > > show thread x > > for each one. > > And a trace for each thread with the command? > > tr > > Anything else I should try to get or do? Or is that not the data > at all you are looking for? > > >>> Yes, everything else which is listed in the 'debugging deadlocks' > >>> page > >>> must be provided, otherwise the deadlock cannot be tracked. > >>> > >>> The investigator should be able to see the whole deadlock chain > >>> (loop) > >>> to make any useful advance. > >> > >> Ok, I have made some excellent progress in debugging the NFS > >> deadlock. > >> > >> Rick! You are genius. :-) You found the right commit r250907 (dated > >> May 22) is the definitely the problem. > >> > >> Here is how I did the testing: One machine received a kernel before > >> r250907, the second machine received a kernel after r250907. Sure > >> enough within a few hours the machine with r250907 went into the > >> usual deadlock state. The machine without that commit kept on > >> working fine. Then I went back to the latest revision (r253726), but > >> leaving r250907 out. The machines have been running happy and rock > >> solid without any deadlocks. I have expanded the testing to 3 > >> machines now and no reports of any issues. > >> > >> I guess now Konstantin has to figure out why that commit is causing > >> the deadlock. Lovely! :-) I will get that information as soon as > >> possible. I'm a little behind with normal work load, but I expect to > >> have the data by Tuesday evening or Wednesday. > >> > > Have you been able to pass the debugging info on to Kostik? > > > > It would be really nice to get this fixed for FreeBSD9.2. > > > > Thanks for your help with this, rick > > Sorry Rick, I wasn't able to get you guys that info quickly enough. I > thought I would have enough time, before my own wedding and honeymoon came > along, but everything went a little crazy and stressful. I didn't think it > would be this nuts. :-) > > I'm caught up with everything and from what I can see from the discussions > is that we know now what the problem is. > > I can report that the machines which I have had without r250907 have been > running without any problems for 27+ days. > > If you need me to test any new patches, please let me know. If I should > test with the partial merge of r253927 I'll be happy to do so. > > Thanks, > > Michael > > > > > ___ > 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" > ___ 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: NFS deadlock on 9.2-Beta1
On Aug 15, 2013, at 2:39 PM, Rick Macklem wrote: > Michael Tratz wrote: >> >> On Jul 27, 2013, at 11:25 PM, Konstantin Belousov >> wrote: >> >>> On Sat, Jul 27, 2013 at 03:13:05PM -0700, Michael Tratz wrote: Let's assume the pid which started the deadlock is 14001 (it will be a different pid when we get the results, because the machine has been restarted) I type: show proc 14001 I get the thread numbers from that output and type: show thread x for each one. And a trace for each thread with the command? tr Anything else I should try to get or do? Or is that not the data at all you are looking for? >>> Yes, everything else which is listed in the 'debugging deadlocks' >>> page >>> must be provided, otherwise the deadlock cannot be tracked. >>> >>> The investigator should be able to see the whole deadlock chain >>> (loop) >>> to make any useful advance. >> >> Ok, I have made some excellent progress in debugging the NFS >> deadlock. >> >> Rick! You are genius. :-) You found the right commit r250907 (dated >> May 22) is the definitely the problem. >> >> Here is how I did the testing: One machine received a kernel before >> r250907, the second machine received a kernel after r250907. Sure >> enough within a few hours the machine with r250907 went into the >> usual deadlock state. The machine without that commit kept on >> working fine. Then I went back to the latest revision (r253726), but >> leaving r250907 out. The machines have been running happy and rock >> solid without any deadlocks. I have expanded the testing to 3 >> machines now and no reports of any issues. >> >> I guess now Konstantin has to figure out why that commit is causing >> the deadlock. Lovely! :-) I will get that information as soon as >> possible. I'm a little behind with normal work load, but I expect to >> have the data by Tuesday evening or Wednesday. >> > Have you been able to pass the debugging info on to Kostik? > > It would be really nice to get this fixed for FreeBSD9.2. > > Thanks for your help with this, rick Sorry Rick, I wasn't able to get you guys that info quickly enough. I thought I would have enough time, before my own wedding and honeymoon came along, but everything went a little crazy and stressful. I didn't think it would be this nuts. :-) I'm caught up with everything and from what I can see from the discussions is that we know now what the problem is. I can report that the machines which I have had without r250907 have been running without any problems for 27+ days. If you need me to test any new patches, please let me know. If I should test with the partial merge of r253927 I'll be happy to do so. Thanks, Michael ___ 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"
