Re: Panic after updating

2021-01-12 Thread Jakob Alvermark
On 1/12/21 6:10 PM, Hans Petter Selasky wrote: On 1/12/21 2:46 PM, Hans Petter Selasky wrote: On 1/12/21 2:40 PM, Jakob Alvermark wrote: On 1/12/21 2:16 PM, Hans Petter Selasky wrote: On 1/12/21 1:43 PM, Jakob Alvermark wrote: On 1/12/21 12:54 PM, Hans Petter Selasky wrote: On 1/12/21

Re: Old PowerMacs, Giant, and stable/13 branch and other futures: What is the intent?

2021-01-12 Thread Mark Millard
On 2021-Jan-12, at 13:11, Mark Millard wrote: > PowerMac G5's and G4's with not much in them or connected to them report: > > WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD > 13.0. > WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.

Old PowerMacs, Giant, and stable/13 branch and other futures: What is the intent?

2021-01-12 Thread Mark Millard
PowerMac G5's and G4's with not much in them or connected to them report: WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD 13.0. WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0. There is also, using and example G4 that I have access to,

Re: Panic after updating

2021-01-12 Thread Ian Lepore
On Tue, 2021-01-12 at 19:56 +0100, Hans Petter Selasky wrote: > On 1/12/21 7:45 PM, Ian Lepore wrote: > > > > - for (int i = 0; i <= sc->sc_npins; i++) { > > > > + for (int i = 0; i != sc->sc_npins; i++) { > > > > mtx_destroy(>sc_pin_intr[i].mtx); > > > >

Re: Panic after updating

2021-01-12 Thread Hans Petter Selasky
On 1/12/21 7:45 PM, Ian Lepore wrote: - for (int i = 0; i <= sc->sc_npins; i++) { + for (int i = 0; i != sc->sc_npins; i++) { mtx_destroy(>sc_pin_intr[i].mtx); free(>sc_pin_intr[i].pin, M_GPIOC); } --HPS If that is the problem, I'd rather

Re: Panic after updating

2021-01-12 Thread Ian Lepore
On Tue, 2021-01-12 at 18:10 +0100, Hans Petter Selasky wrote: > On 1/12/21 2:46 PM, Hans Petter Selasky wrote: > > On 1/12/21 2:40 PM, Jakob Alvermark wrote: > > > > > > On 1/12/21 2:16 PM, Hans Petter Selasky wrote: > > > > On 1/12/21 1:43 PM, Jakob Alvermark wrote: > > > > > > > > > > On

Re: Preparing ZFS drives

2021-01-12 Thread joe mcguckin
Freddie, Thanks! I have to say that this is the most cogent explanation on how to prepare ZFS drives that anyone has ever given me. Thanks again! Joe Joe McGuckin ViaNet Communications j...@via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax > On Jan 12, 2021, at 10:32 AM,

Re: Preparing ZFS drives

2021-01-12 Thread Alan Somers
On Tue, Jan 12, 2021 at 11:10 AM joe mcguckin wrote: > Folks, > > I want to buy some 16TB drives and raid them up > > How should I label and prepare the drives for ZFS? Someone ought to write > a ‘cookbook’ on that! > > Do I need to start the volume on a particular sector boundary? > > Are the

Re: Preparing ZFS drives

2021-01-12 Thread Kurt Jaeger
Hi! > How should I label and prepare the drives for ZFS? Someone ought to write a > ???cookbook??? on that! Basically, what I once did, was this: zpool create bck raidz2 ada2 ada3 ada4 ada5 ada6 ada7 ada8 ada9 Therefore: raw disks, nothing else. > Do I need to start the volume on a

Re: Preparing ZFS drives

2021-01-12 Thread Freddie Cash
On Tue, Jan 12, 2021 at 10:10 AM joe mcguckin wrote: > Folks, > > I want to buy some 16TB drives and raid them up > > How should I label and prepare the drives for ZFS? Someone ought to write > a ‘cookbook’ on that! > If these drives will be strictly data drives (not booting from them),

Preparing ZFS drives

2021-01-12 Thread joe mcguckin
Folks, I want to buy some 16TB drives and raid them up How should I label and prepare the drives for ZFS? Someone ought to write a ‘cookbook’ on that! Do I need to start the volume on a particular sector boundary? Are the 4096 byte sector drives usable? Thanks, Joe Joe McGuckin ViaNet

Re: Panic after updating

2021-01-12 Thread Hans Petter Selasky
On 1/12/21 2:46 PM, Hans Petter Selasky wrote: On 1/12/21 2:40 PM, Jakob Alvermark wrote: On 1/12/21 2:16 PM, Hans Petter Selasky wrote: On 1/12/21 1:43 PM, Jakob Alvermark wrote: On 1/12/21 12:54 PM, Hans Petter Selasky wrote: On 1/12/21 12:32 PM, Jakob Alvermark wrote: Alright, after a

/usr/bin/diff - incorrectly says files are identical

2021-01-12 Thread Jamie Landeg-Jones
When diff hits certain access errors, function diffreg() shows the error message, and then returns to the calling function, which calls print_status() with the return value. However, in these cases, the return value isn't changed from the initial default value of D_SAME. Normally,

Re: Git and complementary web interfaces (some fast but basic, others fuller-featured)

2021-01-12 Thread Jamie Landeg-Jones
Graham Perrin wrote: > Strictly speaking, main site does still > direct developers to the Subversion repository and the Git mirror on GitHub. Fair enough, but that will change, and timestamps don't appear to be an option. I'm sure it wouldn't be too painful to add,

Re: Current amd64 main-c255825-g2a4b22514635-dirty panic triggered by ure(4) detach

2021-01-12 Thread Hans Petter Selasky
On 1/12/21 4:58 PM, Oleg V. Nauman wrote: __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=) at

Current amd64 main-c255825-g2a4b22514635-dirty panic triggered by ure(4) detach

2021-01-12 Thread Oleg V. Nauman
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:399 #2

Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850

2021-01-12 Thread David Wolfskill
On Tue, Jan 12, 2021 at 05:31:30PM +0200, Andriy Gapon wrote: > On 2021-01-11 14:55, David Wolfskill wrote: > > pci3: unknown notify 0x2 > > ACPI Error: AE_ERROR, Thread 12 could not acquire Mutex > > [ACPI_MTX_Caches] (0c4) (20201113/utmutex-434) > > Looks like that was some sort of a race

Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850

2021-01-12 Thread Andriy Gapon
On 2021-01-11 14:55, David Wolfskill wrote: > pci3: unknown notify 0x2 > ACPI Error: AE_ERROR, Thread 12 could not acquire Mutex [ACPI_MTX_Caches] > (0c4) (20201113/utmutex-434) Looks like that was some sort of a race or otherwise transient condition that lead to the _PTS (prepare-to-sleep)

Re: Panic after updating

2021-01-12 Thread Hans Petter Selasky
On 1/12/21 2:40 PM, Jakob Alvermark wrote: On 1/12/21 2:16 PM, Hans Petter Selasky wrote: On 1/12/21 1:43 PM, Jakob Alvermark wrote: On 1/12/21 12:54 PM, Hans Petter Selasky wrote: On 1/12/21 12:32 PM, Jakob Alvermark wrote: Alright, after a new bisect run I got a different result, so I

Re: Panic after updating

2021-01-12 Thread Jakob Alvermark
On 1/12/21 2:16 PM, Hans Petter Selasky wrote: On 1/12/21 1:43 PM, Jakob Alvermark wrote: On 1/12/21 12:54 PM, Hans Petter Selasky wrote: On 1/12/21 12:32 PM, Jakob Alvermark wrote: Alright, after a new bisect run I got a different result, so I most likely did something wrong the first

Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850

2021-01-12 Thread David Wolfskill
On Mon, Jan 11, 2021 at 04:55:13AM -0800, David Wolfskill wrote: > At the conclusion of each morning's "update cycle," I have (for > some time) been in the habit of powering the laptop off, leaving > it powered off for about 15 seconds, then powering it back up. (The > build machine also gets

Re: Panic after updating

2021-01-12 Thread Hans Petter Selasky
On 1/12/21 1:43 PM, Jakob Alvermark wrote: On 1/12/21 12:54 PM, Hans Petter Selasky wrote: On 1/12/21 12:32 PM, Jakob Alvermark wrote: Alright, after a new bisect run I got a different result, so I most likely did something wrong the first time. ff3468ac94597efdcbc56f372528dfc98b114dac is

Re: Panic after updating

2021-01-12 Thread Jakob Alvermark
On 1/12/21 12:54 PM, Hans Petter Selasky wrote: On 1/12/21 12:32 PM, Jakob Alvermark wrote: Alright, after a new bisect run I got a different result, so I most likely did something wrong the first time. ff3468ac94597efdcbc56f372528dfc98b114dac is the first bad commit commit

Re: Panic after updating

2021-01-12 Thread Hans Petter Selasky
On 1/12/21 12:32 PM, Jakob Alvermark wrote: Alright, after a new bisect run I got a different result, so I most likely did something wrong the first time. ff3468ac94597efdcbc56f372528dfc98b114dac is the first bad commit commit ff3468ac94597efdcbc56f372528dfc98b114dac Author: Ian Lepore Date:  

Re: Panic after updating

2021-01-12 Thread Jakob Alvermark
On 1/12/21 9:33 AM, Jakob Alvermark wrote: On 1/11/21 7:08 PM, Hans Petter Selasky wrote: On 1/11/21 5:24 PM, Jakob Alvermark wrote: On 1/11/21 1:14 PM, Hans Petter Selasky wrote: On 1/11/21 11:12 AM, Jakob Alvermark wrote: Updated my Acer laptop from r367734 to main-c255666-g1790f5e654f

Re: zpool can not create a pool after using gdisk to prepare the device

2021-01-12 Thread Johan Hendriks
On 12/01/2021 07:50, Graham Perrin wrote: I used gdisk(8) with a USB flash drive to: 1. zap (destroy) GPT data structures 2. blank out the MBR 3. (below) write a new GPT with a FreeBSD ZFS (A504) partition at /dev/da1p1 root@mowa219-gjp4-8570p:~ # gdisk /dev/da1 GPT fdisk (gdisk)

Re: Panic after updating

2021-01-12 Thread Jakob Alvermark
On 1/11/21 7:08 PM, Hans Petter Selasky wrote: On 1/11/21 5:24 PM, Jakob Alvermark wrote: On 1/11/21 1:14 PM, Hans Petter Selasky wrote: On 1/11/21 11:12 AM, Jakob Alvermark wrote: Updated my Acer laptop from r367734 to main-c255666-g1790f5e654f Rebooting with the newly build kernel i