Re: ZFS server has gone crazy slow
> On Apr 12, 2020, at 01:48, Eugene Grosbein wrote: > > There is very simple way to prevent such problem, use: zfs set reservation=1G > for single "root" file system of the pool. > > This way ZFS won't allow applications to fill the pool to the point it starts > crawling. > Instead, writing applications would obtain ENOSPC error when pool's free > space hits the limit. Done. Thank you for that good advice! In case this system develops the same issue in another year or three and I’ve forgotten this, it will yell at me before getting so logged down. - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS server has gone crazy slow
> On Apr 11, 2020, at 14:33, Eugene Grosbein wrote: > > 12.04.2020 0:36, Chris Ross wrote: > >> I have a FreeBSD 11.3-STABLE server that is my router, using a ZFS mirror >> (of two GPT disks) as it’s disk. It’s many years old, and has only been >> misbehaving like this for a day or so. I’m trying to figure out what’s >> wrong. >> >> […] >> >> I _think_ this is a filesystem problem. It’s very hard to diagnose because >> logging in, and doing anything, takes many seconds per command. zpool >> status shows my mirror as online, so I’m not sure where I should check. >> >> I’d appreciate any help! Thanks much… > > First of all you should check if any of your ZFS pools is low on space. Wow. I’m so embarrassed that I didn’t notice that myself. You mentioned it, and now I look back at df output and see that the filesystems are all very nearly full! It’s very slowly booting now, but assumedly after it comes online, I’ll be able to rectify that situation and hopefully that will be the issue. Thanks, and sorry that I hadn’t seen that myself! - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS server has gone crazy slow
I have a FreeBSD 11.3-STABLE server that is my router, using a ZFS mirror (of two GPT disks) as it’s disk. It’s many years old, and has only been misbehaving like this for a day or so. I’m trying to figure out what’s wrong. I confirmed that internet connectivity isn’t the problem, and a reboot didn’t fix it. (The reboot took 10-15 minutes to finish going multi-user, starting daemons, due to the underlying problem described below.) Truss’ing a very basic command (date), I can see that close() and exit() calls are taking 1-2 seconds. All of the files being opened are on ZFS, but I don’t know if that’s for sure related. Similarly, using shell builtin “echo foo” always is immediate, but “/bin/echo” sometimes works quickly, but sometimes the close() on /var/run/ld-elf.so.hints takes 3-5 seconds. I _think_ this is a filesystem problem. It’s very hard to diagnose because logging in, and doing anything, takes many seconds per command. zpool status shows my mirror as online, so I’m not sure where I should check. I’d appreciate any help! Thanks much… - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UEFI ISO boot not working in 12.1 ?
> On Nov 9, 2019, at 16:07, Toomas Soome wrote: >> On 9. Nov 2019, at 22:42, Chris Ross wrote: >> >> On Sat, Nov 09, 2019 at 11:24:49AM -0600, Kyle Evans wrote: >>> Hi, >>> >>> That helps- thanks! I'm CC'ing tsoome@, as this is basically just >>> r353501 in that range. Can you give the latest -CURRENT snapshot boot >>> as another data point? >> >> Thanks. And yeah, happily, I was already in the process of building >> a -current to test. I am happy (in a way?) to report that it fails in >> the same way as 12.1-RELEASE and stable-12 after Oct 15. >> >> Thanks. >> >> - Chris >> >> for tsoome, the description of boot messages from the top of the thread: >> https://u13739864.ct.sendgrid.net/wf/click?upn=hQ0vnUG1MhNJP-2B3V0tQS3X7emL4YkSUT2tPN1FH-2B97trcjJ-2BpJTmk0YS1Syuo2dzEgthbm6esr-2F7g51EhfIu-2FRKPX9ALsGd2rGBcgTMu-2ByHTR5seO4J-2BMjDv1jXVelnC_Q1G7K8cYCrLWsp3rtsmPRmehVLbUy52d-2BfbfYGlvl9NQI4m-2FwzZopJkgCxdhMRbWmFftXh2uS-2B-2BSajUZUYeDDKIqa-2BkmcDAEvzUwBDvIkJ68RHhHwrawZGSusvYISZywqilQnr9pHQM76aMYLdRwAVYqyTEPcAf5A5HUkYd-2BCJMlUHK2yaZZCEthT1ABNUcX5NJKB-2B9bcz-2B5MfT94enkwpJ0wn19Bm-2BHJ58K1WRS9QQ-3D > > Going to investigate tomorrow with fresh head as it is getting close to > midnight here… I had some email server problems lately, but I haven’t seen any more about this. Any update, Toomas? - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?
On Sat, Nov 09, 2019 at 04:51:38PM -0500, Chris Ross wrote: > > > Can you provide some guidance of what I need to do to get the mrsas > > > driver to identify it when booting the install ISO? > > > > See the "PRIORITY" section of > > > > https://www.freebsd.org/cgi/man.cgi?query=mrsas&sektion=4 > > > > You can also set that tunable via the loader > > Hmm. Okay. I know I was messing with that parameter on one of these > machines, I though I'd tried it on this one. But, maybe that was the > older box with the HBA in it. Alright, my bad. Apologies to all. So, it turns out that this controller is not recognized in 12.0, but is recognized by later stable-12 builds. I have another problem that prevented 12.1 from booting at all, and I tried investigating both at the same time. This caused me to confuse things. My error. Thanks to all, and this seems to be working in stable-12 in the neighborhood of Oct 2019, perhaps earlier. - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?
On Sat, Nov 09, 2019 at 04:48:10PM +, Gary Palmer wrote: > > Hi Doug! Thanks. Okay, I infer from that that the mpr driver is for > > HBAs that aren't raid? Grepping through the sources for 3516 found me > > only mpr. Looking more carefully, at mrsas while knowing specifically > > what I'm looking for, I find the PCI device ID (0x0014) as "AVAGO Ventura > > SAS Controller". And, that code (mrsas) is about the same in stable-12 as > > is it in -current. > > > > Can you provide some guidance of what I need to do to get the mrsas > > driver to identify it when booting the install ISO? > > See the "PRIORITY" section of > > https://www.freebsd.org/cgi/man.cgi?query=mrsas&sektion=4 > > You can also set that tunable via the loader Hmm. Okay. I know I was messing with that parameter on one of these machines, I though I'd tried it on this one. But, maybe that was the older box with the HBA in it. While I try that, I have a question. I understood that tunable to be a way to get the mfi(4) driver to allow the mrsas(4) driver to be used for devices they both would recognize. But, in this case, it's clear that the mfi(4) driver has now knowledge of this device. Is that tunable being set necessary to have the mrsas(4) driver even find the devices it knows how to support that mfi(4) doesn't? If so, that's a very unfortunate situation. Because there will be a significant set of controllers, like the one I have in this system, that totally fail to present themselves when installing from the install media. Maybe this is a political issue, and I should stop thinking about it, but. Let me know if I'm understanding the technical side, that there are cards mfi(4) has no support for, but this tunable prevents mrsas(4) from attaching them? - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UEFI ISO boot not working in 12.1 ?
On Sat, Nov 09, 2019 at 11:24:49AM -0600, Kyle Evans wrote: > Hi, > > That helps- thanks! I'm CC'ing tsoome@, as this is basically just > r353501 in that range. Can you give the latest -CURRENT snapshot boot > as another data point? Thanks. And yeah, happily, I was already in the process of building a -current to test. I am happy (in a way?) to report that it fails in the same way as 12.1-RELEASE and stable-12 after Oct 15. Thanks. - Chris for tsoome, the description of boot messages from the top of the thread: https://docs.freebsd.org/cgi/getmsg.cgi?fetch=98224+0+current/freebsd-stable ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UEFI ISO boot not working in 12.1 ?
On Thu, Nov 07, 2019 at 02:53:25PM -0500, Chris Ross wrote: > > > On Thu, Nov 7, 2019 at 9:46 AM Julian Elischer wrote: > > >> You could try some bisection back along the 12 branch.. > > Yeah. I was hoping for an easier path, but. I can try slogging back > through stable-12 a month or two at a time. Okay. I spent a bunch of time moving around stable-12 by date, and an ISO build from stable-12 as of 2019-10-14 works (rev 353483), and 2019-10-15 (rev 353541) does not. The svn update across that day shows: Updating '.': Ustand/efi/boot1/boot1.c Ustand/efi/include/efilib.h Ustand/efi/libefi/devpath.c Ustand/efi/libefi/efinet.c Ustand/efi/libefi/efipart.c Ustand/efi/libefi/libefi.c Ustand/efi/loader/arch/i386/efimd.c Ustand/efi/loader/efi_main.c Ustand/efi/loader/framebuffer.c Ustand/efi/loader/main.c Ustand/libsa/stand.h Ustand/libsa/zalloc.c Ustand/libsa/zalloc_defs.h Ustand/libsa/zalloc_malloc.c Ustand/libsa/zalloc_mem.h Ustand/libsa/zalloc_protos.h U . Updated to revision 353541. So, there's the commit/commits. Can someone else who knows the intra-branch process better help me determine where the original change came from, what it was meant to accomplish, then hopefully we can find out what went wrong for at least my hardware? Thanks all! - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?
On Fri, Nov 08, 2019 at 02:28:17PM -0800, Doug Ambrisko wrote: > On Tue, Nov 05, 2019 at 09:44:36PM +0100, Miroslav Lachman wrote: > | Chris Ross wrote on 11/05/2019 21:19: > | > On Tue, Nov 05, 2019 at 08:20:15PM +0100, Miroslav Lachman wrote: > | >> Chris Ross wrote on 11/05/2019 19:34: > | >>> Hello. I have a Cisco UCS C220-M5 with a RAID controller. It calls > itself > | >>> "Cisco 12G Modular Raid Controller with 2GB cache", PPID UCSC-RAID-M5. > | >>> Looking at the CIMC, it shows the PCI vendor/device ids 1000:0014, which > | >>> looks to be an LSI MegaRAID Tri-Mode SAS3516. It looks like this should > | >>> be supported by the mpr(4) driver, but it doesn't seem to recognize it > | >>> at boot time. > | > | mpr_load="YES" goes to /etc/loader.conf > | > | If you need to load mpr manually in boot prompt I am not sure if it > | should be: > | load mpr > | or > | load mpr.ko > | of full path > | load /boot/kernel/mpr.ko > > This should be a mrsas card and not an HBA! mrsas supports all current > UCS RAID cards ... and the next unreleased UCS system :-) You might need > the one in -current for that. I'm not sure what is in 12.1. Hi Doug! Thanks. Okay, I infer from that that the mpr driver is for HBAs that aren't raid? Grepping through the sources for 3516 found me only mpr. Looking more carefully, at mrsas while knowing specifically what I'm looking for, I find the PCI device ID (0x0014) as "AVAGO Ventura SAS Controller". And, that code (mrsas) is about the same in stable-12 as is it in -current. Can you provide some guidance of what I need to do to get the mrsas driver to identify it when booting the install ISO? - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UEFI ISO boot not working in 12.1 ?
On Thu, Nov 07, 2019 at 10:56:00AM +1000, George Michaelson wrote: > On Thu, Nov 7, 2019 at 10:21 AM Julian Elischer wrote: > > > > I suspect a separate bug because the OP specified that it worked in > > 12.0 where those bugs go back to 9.x > > Oh, I didn't realize I updated a PXE boot PR. I am not PXE: I tested > with real media in a Dell, and with Dell iDRAC virtualized media, and > with USB. > > I absolutely represent a user who has h/w which I can reproducably > show cannot load UEFI from true and virtualized local media, not PXE. > > And, this state has existed for some time. Yeah, but I think it's not related. That bug and the screenshots show a kernel booting, then failing to mount. Are you seeing a failure in the initial loader, George? And as noted, the issue I'm seeing is new in 12.1, as compared to the loader in 12.0 > > On Thu, Nov 7, 2019 at 9:46 AM Julian Elischer wrote: > >> You could try some bisection back along the 12 branch.. Yeah. I was hoping for an easier path, but. I can try slogging back through stable-12 a month or two at a time. Is moving through svn by date the easiest path, or are there [stable] revision tags that would make it easier? Thanks all. - Chris ps, somewhere earlier in this thread that I lost right now someone asked if I could put an alternate versions loader on an ISO. I don't know that I know how, but I'd be happy to try it. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cisco 12G SAS RAID support ?
On Tue, Nov 05, 2019 at 05:04:41PM -0500, Chris Ross wrote: > > However, if you've already placed > > mpr_load="YES" in your /etc/loader.conf and rebooted your device, then you > > probably need to move into a diagnostic phase. > > Yeah. I think I see what PCI id is missing in the driver, after digging > around in the sources. I was just hoping it was a process/human error. > I'll get another machine running a build, and see if I can stub it in. Okay. Well, the simple try didn't magically work. I added a few lines in dev/mpr/mpr_pci.c in releng/12.0, built a new ISO, and booted. Now it recognizes the part, but says the following: pcib7: [...] pci7: numa-domain 0 on pcib7 mpr0: port 0x7000-0x70ff mem 0xb800-0xb80f,0xb7f0-0xb7ff,0xb7e0-0xb7ef at device 0.0 numa-domain 0 on pci7 mpr0: IOC in fault state 0x0, resetting mpr0: IOC in fault state 0x0, resetting mpr0: IOC in fault state 0x0, resetting mpr0: IOC in fault state 0x0, resetting mpr0: IOC in fault state 0x0, resetting mpr0: IOC in fault state 0x0, resetting There is about a 4 second pause between each of the "in fault state, resetting" lines. This may not be a freebsd-stable converstion any longer. I'm going to switch over to freebsd-drivers, unless someone has a suggestion of a better list for trying to figure out if small adjustments can be made to the mpr driver to accept this device. Thanks all. - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UEFI ISO boot not working in 12.1 ?
On Wed, Nov 06, 2019 at 02:17:11PM -0500, Chris Ross wrote: > > Hi there. I tried booting FreeBSD-12.1-RELEASE-amd64-disc1.iso on a system > here, which didn't work, and I found that FreeBSD-12.0-RELEASE-amd64-disc1.iso > did work on that same system. [Systems were configured to boot in UEFI mode] > > And continues on from there. However, the attempt to boot 12.1-RELEASE > never loads the loader and allows it to boot. The console output > for 12.1-RELEASE is below. Can anyone help me figure out if it's something > I need to do? How has 12.1 changed w.r.t. 12.0 for UEFI? More information. A stable/12 ISO that I built fails in the same way the 12.1-RELEASE ISO did. But, I just grabbed releng/12.0, and built a release ISO, and it boots. So, something seems definately to have changed in the way the UEFI bits are on the boot ISOs? Or maybe a change in the loader? Is okay in releng/12.0, but broken in 12.1-RELEASE and stable/12. Let me know what to try next. - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
UEFI ISO boot not working in 12.1 ?
Hi there. I tried booting FreeBSD-12.1-RELEASE-amd64-disc1.iso on a system here, which didn't work, and I found that FreeBSD-12.0-RELEASE-amd64-disc1.iso did work on that same system. Another [older] system I had was working with FreeBSD-12.1-RELEASE-amd64-disc1.iso, but after I had reason to change that older system to UEFI boot mode, I found it also would not boot the 12.1 ISO any longer A successul UEFI boot of 12.0-RELEASE-amd64-disc1 shows many lines of EFI information to the console, and nearing the bottom: BootOrder: 0001 0002 0003 0004[*] BootInfo Path: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x3)/CDROM(0x1) BootInfo Path: VenHw(,) Ignoring Boot0004: No Media Path Trying ESP: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x3) Setting currdev to cd3: - And, that last line is a spinning cursor, after which becomes: Loading /boot/defaults/loader.conf And continues on from there. However, the attempt to boot 12.1-RELEASE never loads the loader and allows it to boot. The console output for 12.1-RELEASE is below. Can anyone help me figure out if it's something I need to do? How has 12.1 changed w.r.t. 12.0 for UEFI? The 12.1-RELEASE shows the same as above until starting with "Trying ESP": Trying ESP: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x3)/CDROM(0x1) Setting currdev to cd4: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x1) Setting currdev to cd0: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x2) Setting currdev to cd1: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x3) Setting currdev to cd2: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x3)/CDROM(0x0) Setting currdev to cd3: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x4) Setting currdev to cd5: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x5) Setting currdev to cd6: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x6) Setting currdev to cd7: Trying: PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x0)/USB(0x2,0x0)/Unit(0x7) Setting currdev to cd8: Failed to bind bootable partition press any key to interrupt reboot in 5 seconds Let me know why 12.1-RELEASE is not behaving the same way on my systems... Thank you. - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?
On Wed, Nov 06, 2019 at 08:44:35AM +1100, Dewayne Geraghty wrote: > Chris, > After you've booted the kernel, the correct way to load a module that isn't > already in the kernel, is to: > kldload mpr > To check if mpr is loaded, try > kldstat -v|grep mpr Thanks for this. I was able to boot and verify that pci/mpr is already loaded, and trying "kldload mpr" reports that it's already loaded from the kernel. So, device just not recognized. > However, if you've already placed > mpr_load="YES" in your /etc/loader.conf and rebooted your device, then you > probably need to move into a diagnostic phase. Yeah. I think I see what PCI id is missing in the driver, after digging around in the sources. I was just hoping it was a process/human error. I'll get another machine running a build, and see if I can stub it in. Thanks all. - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?
On Tue, Nov 05, 2019 at 12:29:00PM -0800, Freddie Cash wrote: > > I tried "load", but wasn't able to devine how to load the mpr module with > > that. Is that needed, or should 'mpr_load="YES"' have accomplished the > > desired result? > > modulename_load="YES" is the syntax used in the loader.conf file. > "load modulename" (without the quotes) is the syntax used at the loader > prompt. > > So at the loader prompt, try the following: load mpr > Or possibly: load mpr.ko > Or, to get right finicky: load /boot/kernel/mpr.ko Thanks Freddie and Miroslav. I tried "load mpr" earler, but it complained it couldn't find it. I tried again a few minutes ago using "load /boot/kernel/mpr.ko", which spun for a bit then complained it couldn't load it before the kernel. I then loaded the kernel (by full path), and tried again, with no response. Just an immediate prompt. I tried "load /boot/kernel/zfs.ko" as well, in case mpr.ko was already still in memory, but that also returned an immediate prompt without saying anything. So, I think I still have something wrong with my attempts to "load". Should loading the mpr.ko before the kernel work? It didn't with my last attempt (which I realize now was 12.0-RELEASE, not 12.1-RELEASE). - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?
On Tue, Nov 05, 2019 at 08:20:15PM +0100, Miroslav Lachman wrote: > Chris Ross wrote on 11/05/2019 19:34: > > Hello. I have a Cisco UCS C220-M5 with a RAID controller. It calls itself > > "Cisco 12G Modular Raid Controller with 2GB cache", PPID UCSC-RAID-M5. > > Looking at the CIMC, it shows the PCI vendor/device ids 1000:0014, which > > looks to be an LSI MegaRAID Tri-Mode SAS3516. It looks like this should > > be supported by the mpr(4) driver, but it doesn't seem to recognize it > > at boot time. > > Do you have mpr_load="YES" in loader.conf? > Or for ISO booting you can manually load kernel modules at boot prompt. I dropped to boot prompt in ISO boot, and entered 'mpr_load="YES"'. I tried "load", but wasn't able to devine how to load the mpr module with that. Is that needed, or should 'mpr_load="YES"' have accomplished the desired result? - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?
Hello. I have a Cisco UCS C220-M5 with a RAID controller. It calls itself "Cisco 12G Modular Raid Controller with 2GB cache", PPID UCSC-RAID-M5. Looking at the CIMC, it shows the PCI vendor/device ids 1000:0014, which looks to be an LSI MegaRAID Tri-Mode SAS3516. It looks like this should be supported by the mpr(4) driver, but it doesn't seem to recognize it at boot time. Is there some magic I need to perform for the 12.1-RELEASE image ISO boot to get this driver loaded, or will some internal changes be needed to support this particular part due to quirks? Let me know any information I can provide that will help diagnose. Thank you. - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Compile-time check for clock_nanosleep()
> On Jul 3, 2017, at 14:46, Kurt Jaeger wrote: > > Use __FreeBSD_version from sys/param.h: > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/versions.html Thanks. That looks great. Also, for my specific case of the addition of clock_nanosleep(), it looks from time.h like I could use "__POSIX_VISIBLE >= 200112”. Maybe that isn’t safe, since later looking at time.h on 11.0 and on 11.1, the latter has a definition for clock_nanosleep() in that block, but the former does not. Yeah, digging around it appears that stable/11/sys/sys/param.h at r316498 had __FreeBSD_version at 1100512, and it was raised to 1100513 in revision 318197. And, clock_nanosleep was MFC’d into 11-stable in-between the two, at revision 317618. So, not a precise match there, but >= 1100513 should be safe. Thanks! - Chris signature.asc Description: Message signed with OpenPGP
Compile-time check for clock_nanosleep()
Some time ago, I ported a linux program that was using clock_nanosleep(). I see now that the extra code I’d put in isn’t needed anymore in 11-stable, as it appears this call was added in 11.1. My question is, to properly protect these changes, what is the best way to know at compile time, either (a) that that call is in libc, or (b) that I’m compiling on FreeBSD 11.1 or later ? Thanks. - Chris signature.asc Description: Message signed with OpenPGP
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
> On Jul 1, 2015, at 11:34, Kurt Lidl wrote: > I discovered that if I comment out the following lines > from my /etc/rc.conf, the machine boots reliably: > > ifconfig_bge0="DHCP" > ifconfig_bge0_ipv6="inet6 accept_rtadv" > > Of course, with no network connection, it's not a very useful machine, > but this probably is important to know while debugging the cause of > the problem. I had realized that bringing the interface up was the trigger for the panic. An interesting thing, given the above, would be to note whether using a static IPv4 address (i.e., not DHCP or SYNCDHCP which is what I have), or whether disabling IPv6 or IPv6 accept_rtadv would make any difference. I’m guessing it won’t matter, but I also have a similar config in my rc.conf, so testing a wider variety of configs might be of value. - Chris ___ 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: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Jul 1, 2015, at 05:18 , Fabian Keil wrote: > Does it make a difference if you boot with hw.bge.allow_asf=0? > > According to the man page it is known to "cause system lockup problems > on a small number of systems". It's not obvious to me why it's enabled > by default on FreeBSD and I disable it on all my systems. I'm not sure what it does, even. But, it doesn't seem to make a difference. The kernel I've been running (DDB version of r279722 from Mar 7 2015) panic's in the same way when that's set via the loader by hand, or put into loader.conf. Thanks for the suggestion. Sadly not related (causally). - Chris signature.asc Description: Message signed with OpenPGP using GPGMail
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Jun 30, 2015, at 22:36 , Glen Barber wrote: > On Tue, Jun 30, 2015 at 10:27:21PM -0400, Chris Ross wrote: >> >> Yeah, this is the same panic you, I, and others have been seeing on >> sparc64's >> with bge's, or at least v240's (and one other IIRC) for many many months. >> Thanks >> for grabbing a core! >> >> When I was trying to search for a commit that caused the change of behavior, >> I had difficultly doing it, but it was well back in 2014. The "boots >> sometimes" >> makes this a hard one to track, but as I only have my production v240, also >> makes it one I haven't spent as much time trying to find as I'd like. >> >> Thank you for letting me know this issue isn't fixed, though, despite the >> other >> success with this code. :-) >> >> Hopefully your stacktrace can help figure out what is wrong. >> > > A quick search through the PR system returned zero results for this. > Did you file a PR previously? (If not, do you know of one that already > exists that Kurt can update?) The "long" thread I see in my emails are with subject "FreeBSD 10-STABLE/sparc64 panic". May/June, and then later September and October, and I don't see anyone to have created a PR. I think I got confused and dismayed in June, from reading back, and then never got to trying hard again. The first report I see is from Kurt, http://lists.freebsd.org/pipermail/freebsd-sparc64/2014-March/009261.html, so well over a year ago. But, no mention in that thread about a PR either. I think you may be right, Glen, that there isn't one, and that's on me as well as others. Hopefully, some of the searching through various revisions of 10/stable I documented in the "FreeBSD 10-STABLE/sparc64 panic" thread in May 2014 may help in the end, though. Thanks. tl;dr; I don't know of an existing PR. - Chris >> >> On Jun 30, 2015, at 22:14 , Kurt Lidl wrote: >>> I got all excited and decided to give it a try on my dual-cpu >>> V240 as well. I was able to get it installed, but it panics >>> when booting off the mirrored ZFS drives. (Note: I have no >>> reason to believe this is ZFS related.) >>> >>> snip, snip >>> Setting hostname: spork.pix.net. >>> bge0: link state changed to DOWN >>> spin lock 0xc0cb9e38 (smp rendezvous) held by 0xf80003e93240 (tid >>> 100340) too long >>> timeout stopping cpus >>> panic: spin lock held too long >>> cpuid = 1 >>> KDB: stack backtrace: >>> #0 0xc0575380 at panic+0x20 >>> #1 0xc0558e10 at _mtx_lock_spin_failed+0x50 >>> #2 0xc0558ed8 at _mtx_lock_spin_cookie+0xb8 >>> #3 0xc08d7b9c at tick_get_timecount_mp+0xdc >>> #4 0xc0583c88 at binuptime+0x48 >>> #5 0xc08a3b8c at timercb+0x6c >>> #6 0xc08d7f00 at tick_intr+0x220 >>> Uptime: 29s >>> Dumping 8192 MB (4 chunks) >>> chunk at 0: 2147483648 bytes ... ok >>> chunk at 0x1: 2147483648 bytes ... ok >>> chunk at 0x10: 2147483648 bytes ... ok >>> chunk at 0x11: 2147483648 bytes ... ok >>> >>> Dump complete >>> snip, snip >>> >>> Now the thing that amazes me is that this happened >>> the first three times after I did the install, and >>> on the fourth boot, it didn't panic. And it was >>> able to 'savecore' the crashdump. >>> >>> Here's the stacktrace from the core.txt.0 file: >>> >>> -Kurt >>> >>> Reading symbols from /boot/kernel/zfs.ko.symbols...done. >>> Loaded symbols for /boot/kernel/zfs.ko.symbols >>> Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. >>> Loaded symbols for /boot/kernel/opensolaris.ko.symbols >>> Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. >>> Loaded symbols for /boot/kernel/geom_mirror.ko.symbols >>> Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. >>> Loaded symbols for /boot/kernel/tmpfs.ko.symbols >>> #0 0xc05745bc in doadump (textdump=) >>> at /usr/src/sys/kern/kern_shutdown.c:262 >>> 262 savectx(&dumppcb); >>> (kgdb) #0 0xc05745bc in doadump (textdump=) >>> at /usr/src/sys/kern/kern_shutdown.c:262 >>> #1 0xc0574fb0 in kern_reboot (howto=260) >>> at /usr/src/sys/kern/kern_shutdown.c:451 >>> #2 0xc0575358 in vpanic (fmt=0xc0b22fe0 "spin lock held too long&
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
Yeah, this is the same panic you, I, and others have been seeing on sparc64's with bge's, or at least v240's (and one other IIRC) for many many months. Thanks for grabbing a core! When I was trying to search for a commit that caused the change of behavior, I had difficultly doing it, but it was well back in 2014. The "boots sometimes" makes this a hard one to track, but as I only have my production v240, also makes it one I haven't spent as much time trying to find as I'd like. Thank you for letting me know this issue isn't fixed, though, despite the other success with this code. :-) Hopefully your stacktrace can help figure out what is wrong. - Chris On Jun 30, 2015, at 22:14 , Kurt Lidl wrote: > I got all excited and decided to give it a try on my dual-cpu > V240 as well. I was able to get it installed, but it panics > when booting off the mirrored ZFS drives. (Note: I have no > reason to believe this is ZFS related.) > > snip, snip > Setting hostname: spork.pix.net. > bge0: link state changed to DOWN > spin lock 0xc0cb9e38 (smp rendezvous) held by 0xf80003e93240 (tid 100340) > too long > timeout stopping cpus > panic: spin lock held too long > cpuid = 1 > KDB: stack backtrace: > #0 0xc0575380 at panic+0x20 > #1 0xc0558e10 at _mtx_lock_spin_failed+0x50 > #2 0xc0558ed8 at _mtx_lock_spin_cookie+0xb8 > #3 0xc08d7b9c at tick_get_timecount_mp+0xdc > #4 0xc0583c88 at binuptime+0x48 > #5 0xc08a3b8c at timercb+0x6c > #6 0xc08d7f00 at tick_intr+0x220 > Uptime: 29s > Dumping 8192 MB (4 chunks) > chunk at 0: 2147483648 bytes ... ok > chunk at 0x1: 2147483648 bytes ... ok > chunk at 0x10: 2147483648 bytes ... ok > chunk at 0x11: 2147483648 bytes ... ok > > Dump complete > snip, snip > > Now the thing that amazes me is that this happened > the first three times after I did the install, and > on the fourth boot, it didn't panic. And it was > able to 'savecore' the crashdump. > > Here's the stacktrace from the core.txt.0 file: > > -Kurt > > Reading symbols from /boot/kernel/zfs.ko.symbols...done. > Loaded symbols for /boot/kernel/zfs.ko.symbols > Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. > Loaded symbols for /boot/kernel/opensolaris.ko.symbols > Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. > Loaded symbols for /boot/kernel/geom_mirror.ko.symbols > Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. > Loaded symbols for /boot/kernel/tmpfs.ko.symbols > #0 0xc05745bc in doadump (textdump=) >at /usr/src/sys/kern/kern_shutdown.c:262 > 262 savectx(&dumppcb); > (kgdb) #0 0xc05745bc in doadump (textdump=) >at /usr/src/sys/kern/kern_shutdown.c:262 > #1 0xc0574fb0 in kern_reboot (howto=260) >at /usr/src/sys/kern/kern_shutdown.c:451 > #2 0xc0575358 in vpanic (fmt=0xc0b22fe0 "spin lock held too long", >ap=0x1fa2da638) at /usr/src/sys/kern/kern_shutdown.c:758 > #3 0xc0575388 in panic (fmt=0xc0b22fe0 "spin lock held too long") >at /usr/src/sys/kern/kern_shutdown.c:687 > #4 0xc0558e18 in _mtx_lock_spin_failed (m=0xc0cb9e38) >at /usr/src/sys/kern/kern_mutex.c:561 > #5 0xc0558ee0 in _mtx_lock_spin_cookie (c=0xf80003e93240, >tid=18446735277669594832, opts=0, file=0x0, line=0) >at /usr/src/sys/kern/kern_mutex.c:608 > #6 0xc08d7ba4 in tick_get_timecount_mp (tc=0xc0d13378) at smp.h:206 > #7 0xc0583c90 in binuptime (bt=0x1fa2da980) >at /usr/src/sys/kern/kern_tc.c:188 > #8 0xc08a3b94 in timercb (et=0xc0d13308, arg=) >at time.h:418 > #9 0xc08d7f08 in tick_intr (tf=0x1fa2dab20) >at /usr/src/sys/sparc64/sparc64/tick.c:252 > #10 0xc00a11bc in tl1_intr () > #11 0xc08c934c in spinlock_exit () >at /usr/src/sys/sparc64/sparc64/machdep.c:244 > #12 0xc08c9330 in spinlock_exit () >at /usr/src/sys/sparc64/sparc64/machdep.c:240 > #13 0xc051a194 in cnputs (p=0x1fa2db11a "") >at /usr/src/sys/kern/kern_cons.c:530 > #14 0xc05c06e0 in putchar (c=10, arg=0x1fa2db0c8) >at /usr/src/sys/kern/subr_prf.c:437 > #15 0xc05bee90 in kvprintf (fmt=0xc0b2fb95 "", >func=0xc05c02e0 , arg=0x1fa2db0c8, radix=10, ap=0x1fa2db300) >at /usr/src/sys/kern/subr_prf.c:655 > #16 0xc05bfe80 in _vprintf (level=5, flags=1, >fmt=0xc0b2fb78 "%s: link state changed to %s\n", ap=0x1fa2db2f0) >at /usr/src/sys/kern/subr_prf.c:281 > #17 0xc05c0270 in log (level=5, >fmt=0xc0b2fb78 "%s: link state changed to %s\n") >at /usr/src/sys/kern/subr_prf.c:308 > #18 0xc064ec28 in do_link_state_change (arg=0xf80003396800, >pending=1) at /usr/src/sys/net/if.c:2131 > #19 0xc05cab38 in taskqueue_run_locked (queue=0xf80003288000) >at /usr/src/sys/kern/subr_taskqueue.c:342 > #20 0xc05cacec in taskqueue_run (queue=0xf80003288000) >
Re: 10.1-STABLE bce: Watchdog timeout occurred
On Apr 21, 2015, at 10:10 , Gareth Wyn Roberts wrote: > This may be caused by DMA alignment problems. > See > https://docs.freebsd.org/cgi/getmsg.cgi?fetch=145859+0+archive/2015/freebsd-stable/20150419.freebsd-stable > for a recent thread about the msk driver. The msk maintainer Yonghyeon Pyun > has opted for super safe options of 32K alignment! > > It's a long shot, but you could try increasing BCE_DMA_ALIGN and/or > BCE_RX_BUF_ALIGN in the include file if_bcereg.h, say up to 4096, to see > whether it makes any difference. Well, after making that change, I was able to confirm that the problem doesn't seem to occur. However, in trying to verify the problem on an unmodified kernel, I've rebooted a GENERIC from r281672 without that change, and am also not seeing the problem. :-/ I'm not sure whether the gremlins have "fixed" something, or if I was just too critical in my initial analysis. For now I'll take that change out of my tree and run without it. If I see the flapping again, I'll confirm that it's repeatable, then change the alignments as suggested and see if I see a change. Thanks all... - Chris signature.asc Description: Message signed with OpenPGP using GPGMail
10.1-STABLE bce: Watchdog timeout occurred
I got a new [to me] system recently, a Dell PE 1950. It has two bce parts on the motherboard that identify as: bce#: The OS I installed and kernel I'm running are from a download of a 10.1 STABLE ISO, r281235, April 7, 2015. I had gone on to check out a newer stable from subversion, and build a custom kernel, but when I booted that one I got a bce0 that didn't seem to work, and kept emitting: bce0: /usr/src/sys/dev/bce/if_bce.c(7869): Watchdog timeout occurred, resetting! bce0: link state changed to DOWN bce0: link state changed to UP So, I fell back. But I've since noticed that even the original kernel seems to do this after booting. I'm not yet running any notable amount of traffic through the system, but intend to make it an edge router, so certainly will be. Is there any sort of issue noted in the bce driver in recent days/weeks/months? Are other folks seeing this diagnostic/error? I'll do a little more testing and see if I'm seeing it more or less often, but I know that in at least some cases the interface has flapped like this after boot for long enough that I was unable to get connected remotely, and resorted to a console login to reboot. - Chris signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Bind in FreeBSD, security advisories
On Jul 30, 2013, at 10:07 , Mark Felder wrote: > On Tue, Jul 30, 2013, at 8:42, sth...@nethelp.no wrote: >> >> and every contrib part which is removed, detracts from this. > > And every contrib part that is added to base is another piece of > software that rots for the life of a major release and ends up getting > replaced by frustrated endusers with the latest in ports… I do generally agree with this point, but it's not "every contrib part". Many contrib additions can be useful to a majority, and not rotting software. Some will use more recent replacements from ports, others won't, but it's not always bad. > The tight integration of the base system that everyone appreciates and > respects is far below high-level software like BIND. I agree with this point too, however I, like others have voiced, feel strongly that diagnostic [client] tools like host and/or dig are not at all "high-level software" and _need_ to be present in a base system. Whosever they are. - Chris ___ 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: Problems booting into ZFS on recent stable/9
On Jul 1, 2013, at 22:30 , Chris Ross wrote: > Maybe I messed something up in the kernel I was building. Let me drop back > to a GENERIC > from the same stable/9 and see if that will boot. I just have to figure out > how to get it onto the > disks. :-) User error. Thanks, Gary. I took too many things out of my kernel, I'm sure. I loaded a GENERIC from the same sources and it came up fine. I'll adjust my kernel config and try again, but it's definitely not a FreeBSD problem. Sorry for the noise. - Chris ___ 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: Problems booting into ZFS on recent stable/9
On Mon Jul 1 19:51:45 UTC 2013, Gary Palmer wrote: > What is the interface that the disk(s) that ZFS are on? If it's the > AcerLabs ATA controller, then there are no disks found. There is an > earlier ATA bus (at a guess from the fact ata2 and ata3 are shown above), > however I don't see any disks detected. Normally ATA and SCSI/SAS disks > are probed asynchronously near the end of the boot and that appears > to be missing Right you are. That's likely the core of the problem, then. On my netboot of an older kernel, I see more at the end as you describe: atapci0: port 0x10200-0x10207,0x10218-0x1021b,0x10210-0x10217,0x10208-0x1020b,0x10220-0x1022f at device 13.0 on pci0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 nexus0: type unknown (no driver attached) rtc0: at port 0x70-0x71 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 43 on isa0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2e8-0x2ef irq 43 on isa0 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounter "tick" frequency 5 Hz quality 1000 Event timer "tick" frequency 5 Hz quality 1000 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ada0 at ata2 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 device ada0: 66.700MB/s transfers (UDMA4, PIO 8192bytesuhub0: 2 ports with 2 removable, self powered) ada0: 308921MB (632672208 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata3 bus 0 scbus1 target 0 lun 0 ada1: ATA-7 device ada1: 66.700MB/s transfers (UDMA4, PIO 8192bytes) ada1: 308921MB (632672208 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 GEOM_MIRROR: Device mirror/gswap launched (2/2). Trying to mount root from nfs: []... dc0: link state changed to UP Maybe I messed something up in the kernel I was building. Let me drop back to a GENERIC from the same stable/9 and see if that will boot. I just have to figure out how to get it onto the disks. :-) - Chris ___ 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"
Problems booting into ZFS on recent stable/9
I had a sparc64 (Netra X1) running a stable/9 from late March 2013. Actually, the kernel may've been a bit newer than that as I was working with folks to diagnose and repair some Netra-X1 specific issues. But, ZFS worked fine. I have two pools, zroot as a RAID1 (using equally sized partitions at the front of two large disks), and a zdata that is a large pool of the remaining space of both disks concatenated together. After installing a kernel from a build of [yesterday's] stable/9 today, I now get a failure when trying to boot, which can be seen at the end of this clip from the end of the boot messages below. Is anyone aware of a change in recent months that might've caused this, or have any idea what I may've done wrong? In google'ing I've seen a few posts talking about ways to import the zfs pool to adjust the cache file, but I'm not sure if that is or isn't my problem. I don't think I did anything specific with configuring cache files for either pool. Thoughts are welcome. I don't have physical access to the machine for quite a few more hours, but when I do should be able to net-boot into the earlier freebsd stable/9 that I originally installed onto this host, and can try a few more things. - Chris atapci0: port 0x10200-0x10207,0x10218-0x1021b,0x10210-0x10217,0x10208-0x1020b,0x10220-0x1022f at device 13.0 on pci0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 rtc0: at port 0x70-0x71 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 43 on isa0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2e8-0x2ef irq 43 on isa0 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounter "tick" frequency 5 Hz quality 1000 Event timer "tick" frequency 5 Hz quality 1000 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 Root mount waiting for: usbus0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 2 ports with 2 removable, self powered Trying to mount root from zfs:zroot []... Mounting from zfs:zroot failed with error 2. Loader variables: vfs.root.mountfrom=zfs:zroot ___ 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: Reinstalling boot blocks on a ZFS-only system
On May 12, 2013, at 23:17 , Jeremy Chadwick wrote: > On Sun, May 12, 2013 at 10:20:26PM -0400, Chris Ross wrote: >> In the past, I've found I've been unable to install all of the bootblocks if >> I >> boot from the ZFS root. When booting from a cd, the basic: >> >> gpart bootcode -p ${bootdir}/zfsboot ${disk} >> dd if=${bootdir}zfsloader of=/dev/${disk}a bs=512 oseek=1024 >> conv=notrunc,sync >> >> works. But, if I boot from ZFS, then I can't dd anything into the front of >> the >> drives. Right now, the problem after booting from the CD, is trying to mount >> a read/write filesystem (mfs, or the like) so that I can scp the bootblocks >> onto the >> system and install them. But, I eventually found the command I'd lost. so I >> think I'm alright. Thanks... > > What does "unable to install" mean? What output/error do you get? I am > going to assume you get EPERM (Operation not permitted), which would be > caused by GEOM's "preventive foot-shooting" (keep reading). > > Is there some reason you're sticking with the MBR scheme instead of GPT? I apologize for all of the noise on the list. I failed to mention the important detail, which is that I'm working on a sparc64 system, so it's all VTOC8, not MBR nor GPT. But as noted, I was able to mount an MBR an accomplish what I'd intended when booting from a CD-R. Thanks. - Chris ___ 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: Reinstalling boot blocks on a ZFS-only system
On May 12, 2013, at 16:58 , Jeremy Chadwick wrote: > The command is "gpart bootcode", however I cannot be bothered to > remember the syntax; I imagine it greatly depends on if you're using GPT > vs. MBR, in addition to what your partition layout look like. Meaning: > there is no "universal standard", it depends entirely on how you set > your stuff up. But the command is definitely "gpart bootcode". > > Next, AFAIK there is no need to boot alternate media (CD etc.) to > accomplish this. > > You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's > "safety measure" / to permit writing to LBA 0; see GEOM(4) and search > for the word "foot". In the past, I've found I've been unable to install all of the bootblocks if I boot from the ZFS root. When booting from a cd, the basic: gpart bootcode -p ${bootdir}/zfsboot ${disk} dd if=${bootdir}zfsloader of=/dev/${disk}a bs=512 oseek=1024 conv=notrunc,sync works. But, if I boot from ZFS, then I can't dd anything into the front of the drives. Right now, the problem after booting from the CD, is trying to mount a read/write filesystem (mfs, or the like) so that I can scp the bootblocks onto the system and install them. BUt, I eventually found the command I'd lost. so I think I'm alright. Thanks... - Chris ___ 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"
Reinstalling boot blocks on a ZFS-only system
So, I've long known and it makes sense that when you're booted from a ZFS volume, you can't mess with the boot-loader. And, I know a few months ago I had a set of commands I would use when booted from a CD that would initialize the network and copy the "release/boot" from somewhere else so that I could install bootblocks and boot-loaders from more recent code. Sadly, I didn't _record_ those commands I was using. What do "people in the know" do when they want to update the bootblocks of a ZFS-boot system? Or, have too few people followed this path so far that they can boot UFS and do it with less difficulty? Thanks. Happy for any information. - Chris ___ 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: top's CPUn vs C column
That patch does in fact work, and removes the inconsistency that I noted earlier. I would be happy to see it committed. If no one else has objections, please do. Thanks... - Chris On Mar 4, 2013, at 11:37 , John Baldwin wrote: > On Friday, March 01, 2013 1:17:41 pm Chris Ross wrote: >> >> So, I was looking at a v240 I have running stable/9 (9.1-STABLE), and >> noticed something odd. The per-CPU information displayed by top seems >> inconsistent. To simplify things, while I'm running a "make release" in >> /usr/src/release, I just started running the following command over and over >> (by hand): >> >> cross: top | grep " CPU" >> cross: top | grep " CPU" >> 1044 cross 1 720 17128K 4464K CPU10 0:01 1.27% zsh >> 22528 root 1 775 11672K 2592K CPU11 0:00 0.00% sh >> cross: top | grep " CPU" >> cross: top | grep " CPU" >> 22634 cross 1 720 12808K 2872K CPU11 0:00 0.00% top >> 22633 root 1 775 6272K 880K CPU01 0:00 0.00% make >> cross: top | grep " CPU" >> 22637 root 1 775 6272K 1656K CPU00 0:00 0.00% make >> cross: top | grep " CPU" >> cross: top | grep " CPU" >> 22684 root 1 775 11672K 2592K CPU00 0:00 0.00% sh >> cross: >> >> This displayed what I had earlier seen in the full-screen top. There >> doesn't appear to be any specific binding between the "n" in the "CPUn" >> state >> value, and the number in the "C" column, which is according to the man page, >> should mean the same thing. >> > No, they are different things. The man page is a bit stale. The 'C' column > is the CPU that the process last ran on. Hmm, it's actually easiest to fix > the code I think. Try this (untested) change: > > Index: usr.bin/top/machine.c > === > --- machine.c (revision 247792) > +++ machine.c (working copy) > @@ -797,7 +797,7 @@ format_next_process(caddr_t handle, char *(*get_us > double pct; > struct handle *hp; > char status[16]; > - int state; > + int cpu, state; > struct rusage ru, *rup; > long p_tot, s_tot; > char *proc_fmt, thr_buf[6], jid_buf[6]; > @@ -997,6 +997,13 @@ format_next_process(caddr_t handle, char *(*get_us > } > > /* format this entry */ > + if (smpmode) { > + if (state == SRUN && pp->ki_oncpu != 0xff) > + cpu = pp->ki_oncpu; > + else > + cpu = pp->ki_lastcpu; > + } else > + cpu = 0; > proc_fmt = smpmode ? smp_Proc_format : up_Proc_format; > if (ps.thread != 0) > thr_buf[0] = '\0'; > @@ -1014,7 +1021,7 @@ format_next_process(caddr_t handle, char *(*get_us > format_k2(PROCSIZE(pp)), > format_k2(pagetok(pp->ki_rssize)), > status, > - smpmode ? pp->ki_lastcpu : 0, > + cpu, > format_time(cputime), > ps.wcpu ? 100.0 * weighted_cpu(pct, pp) : 100.0 * pct, > screen_width > cmdlengthdelta ? screen_width - cmdlengthdelta : 0, > > -- > 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"