Re: ZFS server has gone crazy slow

[Chris Ross]

> 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

[Chris Ross]

> 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

[Chris Ross]

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 ?

[Chris Ross]

> 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) ?

[Chris Ross]

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=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) ?

[Chris Ross]

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=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 ?

[Chris Ross]

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 ?

[Chris Ross]

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) ?

[Chris Ross]

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 ?

[Chris Ross]

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 ?

[Chris Ross]

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 ?

[Chris Ross]

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 ?

[Chris Ross]

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) ?

[Chris Ross]

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) ?

[Chris Ross]

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) ?

[Chris Ross]

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) ?

[Chris Ross]

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()

[Chris Ross]

> 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()

[Chris Ross]

  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)

[Chris Ross]

On Jul 1, 2015, at 05:18 , Fabian Keil freebsd-lis...@fabiankeil.de 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)

[Chris Ross]

 On Jul 1, 2015, at 11:34, Kurt Lidl l...@pix.net 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)

[Chris Ross]

  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 l...@pix.net 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=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:262
 262 savectx(dumppcb);
 (kgdb) #0  0xc05745bc in doadump (textdump=value optimized out)
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=value optimized out)
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 putchar, 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)
at 

Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)

[Chris Ross]

On Jun 30, 2015, at 22:36 , Glen Barber g...@freebsd.org 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 l...@pix.net 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=value optimized out)
   at /usr/src/sys/kern/kern_shutdown.c:262
 262 savectx(dumppcb);
 (kgdb) #0  0xc05745bc in doadump (textdump=value optimized out)
   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=value optimized out)
   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

Re: 10.1-STABLE bce: Watchdog timeout occurred

[Chris Ross]

On Apr 21, 2015, at 10:10 , Gareth Wyn Roberts g.w.robe...@glyndwr.ac.uk 
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

[Chris Ross]

  I got a new [to me] system recently, a Dell PE 1950.  It has two bce parts on 
the motherboard that identify as:

bce#: QLogic NetXtreme II BCM5708 1000Base-T (B2)

  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

[Chris Ross]

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

Problems booting into ZFS on recent stable/9

[Chris Ross]

  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: AcerLabs M5229 UDMA66 controller 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: ATA channel at channel 0 on atapci0
ata3: ATA channel at channel 1 on atapci0
rtc0: Real-Time Clock 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: AcerLabs at usbus0
uhub0: AcerLabs OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 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: Problems booting into ZFS on recent stable/9

[Chris Ross]

On Mon Jul 1 19:51:45 UTC 2013, Gary Palmer gpal...@freebsd.org  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: AcerLabs M5229 UDMA66 controller 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: ATA channel at channel 0 on atapci0
ata3: ATA channel at channel 1 on atapci0
nexus0: syscons type unknown (no driver attached)
rtc0: Real-Time Clock 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: AcerLabs at usbus0
uhub0: AcerLabs OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0
ada0 at ata2 bus 0 scbus0 target 0 lun 0
ada0: Maxtor 5A320J0 RAM51VV0 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: Maxtor 5A320J0 RAM51VV0 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

Re: Problems booting into ZFS on recent stable/9

[Chris Ross]

On Jul 1, 2013, at 22:30 , Chris Ross cross+free...@distal.com 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: Reinstalling boot blocks on a ZFS-only system

[Chris Ross]

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

Reinstalling boot blocks on a ZFS-only system

[Chris Ross]

  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: Reinstalling boot blocks on a ZFS-only system

[Chris Ross]

On May 12, 2013, at 16:58 , Jeremy Chadwick j...@koitsu.org 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

Re: top's CPUn vs C column

[Chris Ross]

  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 j...@freebsd.org 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