Re: Odd ZFS boot module issue on r332158

2018-05-01 Thread Toomas Soome


> On 1 May 2018, at 17:34, Andrew Gallatin  wrote:
> 
> On 04/10/18 16:51, Andriy Gapon wrote:
>> On 10/04/2018 22:48, Andrew Gallatin wrote:
>>> On 04/10/18 11:25, Andriy Gapon wrote:
 On 10/04/2018 15:27, Andrew Gallatin wrote:
> Is there something like tools/diag/prtblknos for ZFS?
 
 zdb.
 
 It has a manual page, but in the case like this you typically want to run
 zdb -d[d*]  
 Add d-s until you get all the information you want.
 
 It looks like five d-s is needed to get individual blocks reported.
 
>>> 
>>> Thanks for the instructions!
>>> 
>>> How do I interpret this output:
>> [snip]
>>>0 L1  1:1f01016c000:1000 2L/1000P F=3 B=16769122/16769122
>>>0  L0 1:1f00f9e3000:2 2L/2P F=1 
>>> B=16769122/16769122
>>>2  L0 1:1f00fa03000:2 2L/2P F=1 
>>> B=16769122/16769122
>>>4  L0 1:1f00fa23000:2 2L/2P F=1 
>>> B=16769122/16769122
>> The first number is an offset within the file (hex); Lx is a block level 
>> where
>> L0 is a data block, L1 is an indirect block just above data blocks, etc; 
>> x:y:z
>> is a (top-level) vdev number, a block offset on disk (hex) and a block size 
>> on
>> disk(hex); the rest is not as important.
>> The quoted offsets appear to be just below 2TB.
> 
> Are these byte addresses?  Or do I need to multiply by the blocksize to 
> determine the offset into the file?  From your "just below 2TB" I'm assuming 
> byte addresses.
> 
> This is a supermicro board X10SRA. They do have a f/w update,
> but I suspect it is mainly just for new ucode.  Of course there is
> no changelong.  I guess I'll try it if/when I'm totally unable to
> boot into a new BE.
> 
> I just checked, and my EFI loader is ~1 year old, I should probably try
> updating that too.
> 
> FWIW, I just updated to head again, and I see a problem with just one
> module, which looks like the attached.
> 

could you test https://reviews.freebsd.org/D15207 
 ?

rgds,
toomas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Odd ZFS boot module issue on r332158

2018-05-01 Thread Andrew Gallatin

FWIW, I also updated to the latest BIOS available for this board,
Supermicro X10SRA, to version: 2.0c Release Date: 09/25/2017.

One thing I noticed is that even though the board supports UEFI,
there was no UEFI update procedure for it, and I had to flash via
a USB stick with a FreeDOS boot image.  Given that, I would
not be terribly... surprised... if the UEFI fw on the board had
 issues with 2TB as well.   All the update seemed to do was
re-order my PCI devices, so I had to revisit my Xorg and
byhve pptdev configurations.

Thankfully, the only module giving issues is nvidia, which is
just as well loaded post-boot.

FWIW, the error is

~~~
/boot/modules/nvidia.ko -
elf64_obj_loadimage: read failed

can't load file '/boot/modules/nvidia.ko': input/output error
~~~


Drew
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Odd ZFS boot module issue on r332158

2018-05-01 Thread Andrew Gallatin

On 05/01/18 13:14, Toomas Soome wrote:



On 1 May 2018, at 17:34, Andrew Gallatin > wrote:


On 04/10/18 16:51, Andriy Gapon wrote:

On 10/04/2018 22:48, Andrew Gallatin wrote:

On 04/10/18 11:25, Andriy Gapon wrote:

On 10/04/2018 15:27, Andrew Gallatin wrote:

Is there something like tools/diag/prtblknos for ZFS?


zdb.

It has a manual page, but in the case like this you typically want 
to run

zdb -d[d*]  
Add d-s until you get all the information you want.

It looks like five d-s is needed to get individual blocks reported.



Thanks for the instructions!

How do I interpret this output:

[snip]
   0 L1  1:1f01016c000:1000 2L/1000P F=3 
B=16769122/16769122
   0  L0 1:1f00f9e3000:2 2L/2P F=1 
B=16769122/16769122
   2  L0 1:1f00fa03000:2 2L/2P F=1 
B=16769122/16769122
   4  L0 1:1f00fa23000:2 2L/2P F=1 
B=16769122/16769122
The first number is an offset within the file (hex); Lx is a block 
level where
L0 is a data block, L1 is an indirect block just above data blocks, 
etc; x:y:z
is a (top-level) vdev number, a block offset on disk (hex) and a 
block size on

disk(hex); the rest is not as important.
The quoted offsets appear to be just below 2TB.


Are these byte addresses?  Or do I need to multiply by the blocksize 
to determine the offset into the file?  From your "just below 2TB" I'm 
assuming byte addresses.


This is a supermicro board X10SRA. They do have a f/w update,
but I suspect it is mainly just for new ucode.  Of course there is
no changelong.  I guess I'll try it if/when I'm totally unable to
boot into a new BE.

I just checked, and my EFI loader is ~1 year old, I should probably try
updating that too.

FWIW, I just updated to head again, and I see a problem with just one
module, which looks like the attached.



could you test https://reviews.freebsd.org/D15207 



Thank you so much!  I just tried that, and I'm afraid that it didn't 
help, though by all rights I'd expect that it should.  I installed the

world into a new BE, and made sure to re-install boot1.efi into all
my EFI partitions.

Are you able to replicate this issue yourself?

Drew



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Odd ZFS boot module issue on r332158

2018-05-01 Thread Andrew Gallatin

On 04/10/18 16:51, Andriy Gapon wrote:

On 10/04/2018 22:48, Andrew Gallatin wrote:

On 04/10/18 11:25, Andriy Gapon wrote:

On 10/04/2018 15:27, Andrew Gallatin wrote:

Is there something like tools/diag/prtblknos for ZFS?


zdb.

It has a manual page, but in the case like this you typically want to run
zdb -d[d*]  
Add d-s until you get all the information you want.

It looks like five d-s is needed to get individual blocks reported.



Thanks for the instructions!

How do I interpret this output:

[snip]

    0 L1  1:1f01016c000:1000 2L/1000P F=3 B=16769122/16769122
    0  L0 1:1f00f9e3000:2 2L/2P F=1 B=16769122/16769122
    2  L0 1:1f00fa03000:2 2L/2P F=1 B=16769122/16769122
    4  L0 1:1f00fa23000:2 2L/2P F=1 B=16769122/16769122


The first number is an offset within the file (hex); Lx is a block level where
L0 is a data block, L1 is an indirect block just above data blocks, etc; x:y:z
is a (top-level) vdev number, a block offset on disk (hex) and a block size on
disk(hex); the rest is not as important.

The quoted offsets appear to be just below 2TB.





Are these byte addresses?  Or do I need to multiply by the blocksize to 
determine the offset into the file?  From your "just below 2TB" I'm 
assuming byte addresses.


This is a supermicro board X10SRA. They do have a f/w update,
but I suspect it is mainly just for new ucode.  Of course there is
no changelong.  I guess I'll try it if/when I'm totally unable to
boot into a new BE.

I just checked, and my EFI loader is ~1 year old, I should probably try
updating that too.

FWIW, I just updated to head again, and I see a problem with just one
module, which looks like the attached.

Drew
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"