Re: Intel + Thunderbolt Driver

[John-Mark Gurney]

Gerard E. Seibert wrote this message on Fri, Jan 14, 2022 at 14:39 -0500:
> I was just wondering if anyone had heard or knows when FreeBSD will be
> able to support Intel's "Thunderbolt" technology? The lack of a driver
> that works for FreeBSD has made it impossible for me to update my
> system beyond version 11.4.
> 
> https://en.wikipedia.org/wiki/Thunderbolt_(interface)

Last bit of info that I know about it the 2020 presentation on it:
https://papers.freebsd.org/2020/bsdcan/long-thunderbolt_on_freebsd/

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."

Re: fsck -C -p: NO WRITE ACCESS

[John-Mark Gurney]

Andriy Gapon wrote this message on Mon, Feb 07, 2022 at 14:15 +0200:
> I've got a problem where fsck behaves differently from my expectations.
> The problem happens with a filesystem on a GELI encrypted ZVOL.
> The volume has 4K block size and that's the GELI's sector size as well.
> FreeBSD is stable/13 from mid January.

Did you put a ffs filesystem that was formatted on a 512 byte sector disk
onto this geli device?

fsck calculates the sector size via (/sbin/fsck_ffs/setup.c):
dev_bsize = sblock.fs_fsize / fsbtodb(&sblock, 1);

and fsbtodb:
../../sys/ufs/ffs/fs.h:#define  fsbtodb(fs, b)  ((daddr_t)(b) << 
(fs)->fs_fsbtodb)

> fsize   4096shift   12  mask0xf000
> frag8   shift   3   fsbtodb 3

fsize / (1 << 3) == 4096 / 8 == 512.

so, likely updating fsbtodb to be 0 instead of 3 would fix this.  I'm not
sure how to do this though, as tunefs and fsdb don't seem to have options
to do this, and likely you'll want to update all the superblocks w/ this
new value.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."

Re: fsck -C -p: NO WRITE ACCESS

[John-Mark Gurney]

Andriy Gapon wrote this message on Tue, Feb 15, 2022 at 08:44 +0200:
> On 15/02/2022 01:17, John-Mark Gurney wrote:
> > Andriy Gapon wrote this message on Mon, Feb 07, 2022 at 14:15 +0200:
> >> I've got a problem where fsck behaves differently from my expectations.
> >> The problem happens with a filesystem on a GELI encrypted ZVOL.
> >> The volume has 4K block size and that's the GELI's sector size as well.
> >> FreeBSD is stable/13 from mid January.
> > 
> > Did you put a ffs filesystem that was formatted on a 512 byte sector disk
> > onto this geli device?
> 
> As far as I can recall, no.  I created it with newsfs on the geli device.

Looks like it's a bug in newfs, as I just reproduced this myself:
fsbtodb   int32_t  0x0003

and manually specifying a sector size of 4096 to newfs does not fix the
issue.

This is the issue:
https://cgit.freebsd.org/src/blame/sbin/newfs/newfs.c#n399

It changes the sectorsize back down to 512 from whatever it should
be, which means that the calculation in mkfs.c becomes off.  I'd file
a bug report and get someone who knows FFS to look at it.  I tried to
change mkfs.c to use realsectorsize isntead, so fsbtodb is set to 0, but
then it break ffsinfo, because it's calculations are likely wrong.

> > fsck calculates the sector size via (/sbin/fsck_ffs/setup.c):
> > dev_bsize = sblock.fs_fsize / fsbtodb(&sblock, 1);
> > 
> > and fsbtodb:
> > ../../sys/ufs/ffs/fs.h:#define  fsbtodb(fs, b)  ((daddr_t)(b) << 
> > (fs)->fs_fsbtodb)
> > 
> >> fsize   4096shift   12  mask0xf000
> >> frag8   shift   3   fsbtodb 3
> > 
> > fsize / (1 << 3) == 4096 / 8 == 512.
> > 
> > so, likely updating fsbtodb to be 0 instead of 3 would fix this.  I'm not
> > sure how to do this though, as tunefs and fsdb don't seem to have options
> > to do this, and likely you'll want to update all the superblocks w/ this
> > new value.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."