Re: device_attach: ixv0 attach returned 5

2019-11-21 Thread Michal Vančo via freebsd-stable
Well then this is really annoying. I can image few other applications besides
virtualization. Jails using vnet bound to VF instead of epair being one of 
examples. Any hope that someone will port the SR-IOV from Intel’s code into
the base driver on foreseeable future?

regards
Michal

> On 21 Nov 2019, at 18:52, Richard Gallamore  wrote:
> 
> Hello Michal,
> 
>> I’m running 12-STABLE. Is this a hardware related or possibly a driver
> bug?
> This is probably a driver / module bug.
> 
> [1] is a bug on this issue, that I opened some years ago. The last time
> I tested the sr-iov functionality it was working if you compile the intel
> module with sr-iov support enabled but not with the base module. This
> was probably a couple years ago though and on 12-CURRENT before
> 12 was released.
> 
> Personally I suggest you just avoid sr-iov though and use bridges. sr-iov
> was
> a cool idea but it just failed to get an attraction. Probably several
> reasons
> for this, based on my experience I would say the primary reason is because
> its designed use case is for virtualization, and if you do use this for
> virtualization, you trade the ability to do live migrations due to using
> physical hardware.
> 
> Hope this helps,
> Richard Gallamore
> 
> On Thu, Nov 21, 2019 at 3:53 AM Michal Vančo via freebsd-stable <
> freebsd-stable@freebsd.org> wrote:
> 
>> Hi,
>> 
>> I’m trying to get SR-IOV working with my two port Intel 10G NIC:
>> 
>> ix0@pci0:3:0:0: class=0x02 card=0x15ad15d9 chip=0x15ad8086 rev=0x00
>> hdr=0x00
>>vendor = 'Intel Corporation'
>>device = 'Ethernet Connection X552/X557-AT 10GBASE-T'
>>class  = network
>>subclass   = ethernet
>> ix1@pci0:3:0:1: class=0x02 card=0x15ad15d9 chip=0x15ad8086 rev=0x00
>> hdr=0x00
>>vendor = 'Intel Corporation'
>>device = 'Ethernet Connection X552/X557-AT 10GBASE-T'
>>class  = network
>>subclass   = ethernet
>> 
>> with this iovctl config:
>> 
>> # cat /etc/iovctl_ix1.conf
>> PF {
>>device: "ix1";
>>num_vfs: 4;
>> }
>> 
>> I get 4 PCI devices created:
>> 
>> none57@pci0:3:0:129:class=0x02 card=0x15ad15d9 chip=0x15a88086
>> rev=0x00 hdr=0x00
>>vendor = 'Intel Corporation'
>>device = 'Ethernet Connection X552 Virtual Function'
>>class  = network
>>subclass   = ethernet
>> none58@pci0:3:0:131:class=0x02 card=0x15ad15d9 chip=0x15a88086
>> rev=0x00 hdr=0x00
>>vendor = 'Intel Corporation'
>>device = 'Ethernet Connection X552 Virtual Function'
>>class  = network
>>subclass   = ethernet
>> none59@pci0:3:0:133:class=0x02 card=0x15ad15d9 chip=0x15a88086
>> rev=0x00 hdr=0x00
>>vendor = 'Intel Corporation'
>>device = 'Ethernet Connection X552 Virtual Function'
>>class  = network
>>subclass   = ethernet
>> none60@pci0:3:0:135:class=0x02 card=0x15ad15d9 chip=0x15a88086
>> rev=0x00 hdr=0x00
>>vendor = 'Intel Corporation'
>>device = 'Ethernet Connection X552 Virtual Function'
>>class  = network
>>subclass   = ethernet
>> 
>> But the driver fails to attach with following errors:
>> 
>> ixv0:  at device 0.129
>> on pci4
>> ixv0: ...reset_hw() failure: Reset Failed!
>> ixv0: IFDI_ATTACH_PRE failed 5
>> device_attach: ixv0 attach returned 5
>> ixv0:  at device 0.131
>> on pci4
>> ixv0: ...reset_hw() failure: Reset Failed!
>> ixv0: IFDI_ATTACH_PRE failed 5
>> device_attach: ixv0 attach returned 5
>> ixv0:  at device 0.133
>> on pci4
>> ixv0: ...reset_hw() failure: Reset Failed!
>> ixv0: IFDI_ATTACH_PRE failed 5
>> device_attach: ixv0 attach returned 5
>> ixv0:  at device 0.135
>> on pci4
>> ixv0: ...reset_hw() failure: Reset Failed!
>> ixv0: IFDI_ATTACH_PRE failed 5
>> device_attach: ixv0 attach returned 5
>> 
>> I’m running 12-STABLE. Is this a hardware related or possibly a driver bug?
>> 
>> regards
>> Michal
>> 
>> ___
>> 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"
>> 
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

___
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: Logging boot messages from the loader

2019-11-21 Thread Kyle Evans
On Thu, Nov 21, 2019 at 4:48 AM Eugene Grosbein  wrote:
>
> 21.11.2019 17:22, Bjoern A. Zeeb wrote:
>
> > On 21 Nov 2019, at 9:51, Eugene Grosbein wrote:
> >
> >> Hi!
> >>
> >> How do I get boot messages generated by loader itself written to some log 
> >> after successfull boot?
> >> This is generic BIOS-based 11.3-STABLE/amd64 system with syscons console 
> >> driver.
> >>
> >> /var/run/dmesg.boot starts with kernel messages without previous lines 
> >> from the loader.
> >> Specifically, I need messages about loading kernel modules with full paths.
> >
> > loader cannot write to the kernel message buffer as there is no kernel yet. 
> >  There might be possible ways to preserve that but I doubt loader is fit 
> > for that task.
>
> Some hardware does not clear memory while warm booting, so KDB trace from 
> previous panic sometimes survive reboot
> and ends up in /var/run/dmesg.boot for successful boot. I wonder why loader 
> messages cannot be there, too.
> In fact, kernel message buffer can be found even in absence of kernel :-)
>
> I've already searched through the sources in stand/ and see there is no code 
> to support this yet.
>
> > A boot -v (boot_verbose=“YES”) might spit the information out from the 
> > kernel as well.   Not sure if that helps you.  However on modern server 
> > machines a boot -v often overflows the message buffer.. so you might have 
> > to tune that as well.
> >
> > Extracted from an older console log of a random lab machine of someone else:
> > ..
> > WARNING: WITNESS option enabled, expect reduced performance.^M^@
> > WARNING: DIAGNOSTIC option enabled, expect reduced performance.^M^@
> > Preloaded elf kernel "/boot/kernel/kernel" at 0x80e66000.^M^@
> > Preloaded elf obj module "/boot/kernel/if_igb.ko" at 0x80e66968.^M^@
> > Preloaded elf obj module "/boot/kernel/nfscl.ko" at 0x80e66fd0.^M^@
> > Preloaded elf obj module "/boot/kernel/nfslock.ko" at 
> > 0x80e67638.^M^@
> > Preloaded elf obj module "/boot/kernel/nfssvc.ko" at 0x80e67ba0.^M^@
> > Preloaded elf obj module "/boot/kernel/krpc.ko" at 0x80e68088.^M^@
> > Preloaded elf obj module "/boot/kernel/nfscommon.ko" at 
> > 0x80e686b0.^M^@
> > Preloaded elf obj module "/boot/kernel/ahci.ko" at 0x80e68d20.^M^@
> > Preloaded elf obj module "/boot/kernel/cam.ko" at 0x80e69308.^M^@
> > Preloaded elf obj module "/boot/kernel/mfi.ko" at 0x80e699f0.^M^@
> > Preloaded elf obj module "/boot/kernel/geom_part_gpt.ko" at 
> > 0x80e6a058.^M^@
> > Preloaded elf obj module "/boot/kernel/sysvsem.ko" at 
> > 0x80e6a648.^M^@
> > Preloaded elf obj module "/boot/kernel/sysvshm.ko" at 
> > 0x80e6acb0.^M^@
> > Calibrating TSC clock ... TSC clock: 3400185886 Hz^M^@
> > CPU: Intel(R) Xeon(R) CPU   X5272  @ 3.40GHz (3400.19-MHz K8-class 
> > CPU)^M^@
>
> Yes, but this only shows results of loader's work and kldstat -v shows paths 
> too.
> I need to know why changing modules_path in the nextboot.conf does not work
> and why does loader uses stock zfs.ko insted of my patched version 
> /boot/nextboot/zfs.ko
> if I use nextboot.conf with 
> module_path="/boot/nextboot;/boot/kernel;/boot/modules"
>
>

I pointed this out on IRC, but for list's sake: for something like
this, it's good to verify module_path that loader used by inspecting
kenv. This is my guess at the output:

$ kenv module_path
/boot/kernel;/boot/nextboot;/boot/kernel;/boot/modules

With lualoader, it would be slightly different as we go through the
cosmetic exercise of removing the loaded kernel path from the middle
of module_path if it's there. Both 4th and lua will prepend the kernel
path to module_path once the kernel's loaded, which should always
happen after nextboot processing. For anyone else doing the same, the
best option here would likely be fully qualifying the module names for
every module you want out of a separate path:

zfs_name="/boot/nextboot/zfs.ko"

This should/will work with both 4thloader and lualoader. It's not
ideal for general configuration, but if you're doing a one-off load of
a module in loader it works.
___
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: Logging boot messages from the loader

2019-11-21 Thread Eugene Grosbein
21.11.2019 18:35, David Wolfskill wrote:

>> How do I get boot messages generated by loader itself written to some log 
>> after successfull boot?
>> This is generic BIOS-based 11.3-STABLE/amd64 system with syscons console 
>> driver.
>>
>> /var/run/dmesg.boot starts with kernel messages without previous lines from 
>> the loader.
>> Specifically, I need messages about loading kernel modules with full paths.
>> 
> 
> Perhaps: Set up serial console on the machine in question, then
> connect a machine that's expected to be "sufficiently stable" to
> the other end of a "null modem" cable & run tip(1) on the second
> machine (perhaps within script(1)).
> 
> Or something similar, anyway.

The box is located in remote hoster's datacenter, so I was looking for easier 
way. Bad luck.


___
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"


[NTP] "Unexpected origin timestamp 0xe180e455.d15bf3fb does not match aorg 0000000000.00000000 from server" (kernel reports TIME_ERROR: 0x41: Clock Unsynchronized)

2019-11-21 Thread Vinícius Zavam via freebsd-stable
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242137

-- 
Vinícius Zavam
keybase.io/egypcio
___
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"


device_attach: ixv0 attach returned 5

2019-11-21 Thread Michal Vančo via freebsd-stable
Hi,

I’m trying to get SR-IOV working with my two port Intel 10G NIC:

ix0@pci0:3:0:0: class=0x02 card=0x15ad15d9 chip=0x15ad8086 rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Connection X552/X557-AT 10GBASE-T'
class  = network
subclass   = ethernet
ix1@pci0:3:0:1: class=0x02 card=0x15ad15d9 chip=0x15ad8086 rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Connection X552/X557-AT 10GBASE-T'
class  = network
subclass   = ethernet

with this iovctl config:

# cat /etc/iovctl_ix1.conf 
PF {
device: "ix1";
num_vfs: 4;
}

I get 4 PCI devices created:

none57@pci0:3:0:129:class=0x02 card=0x15ad15d9 chip=0x15a88086 rev=0x00 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Connection X552 Virtual Function'
class  = network
subclass   = ethernet
none58@pci0:3:0:131:class=0x02 card=0x15ad15d9 chip=0x15a88086 rev=0x00 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Connection X552 Virtual Function'
class  = network
subclass   = ethernet
none59@pci0:3:0:133:class=0x02 card=0x15ad15d9 chip=0x15a88086 rev=0x00 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Connection X552 Virtual Function'
class  = network
subclass   = ethernet
none60@pci0:3:0:135:class=0x02 card=0x15ad15d9 chip=0x15a88086 rev=0x00 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Connection X552 Virtual Function'
class  = network
subclass   = ethernet

But the driver fails to attach with following errors:

ixv0:  at device 0.129 on 
pci4
ixv0: ...reset_hw() failure: Reset Failed!
ixv0: IFDI_ATTACH_PRE failed 5
device_attach: ixv0 attach returned 5
ixv0:  at device 0.131 on 
pci4
ixv0: ...reset_hw() failure: Reset Failed!
ixv0: IFDI_ATTACH_PRE failed 5
device_attach: ixv0 attach returned 5
ixv0:  at device 0.133 on 
pci4
ixv0: ...reset_hw() failure: Reset Failed!
ixv0: IFDI_ATTACH_PRE failed 5
device_attach: ixv0 attach returned 5
ixv0:  at device 0.135 on 
pci4
ixv0: ...reset_hw() failure: Reset Failed!
ixv0: IFDI_ATTACH_PRE failed 5
device_attach: ixv0 attach returned 5

I’m running 12-STABLE. Is this a hardware related or possibly a driver bug?

regards
Michal

___
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: Logging boot messages from the loader

2019-11-21 Thread David Wolfskill
On Thu, Nov 21, 2019 at 04:51:13PM +0700, Eugene Grosbein wrote:
> Hi!
> 
> How do I get boot messages generated by loader itself written to some log 
> after successfull boot?
> This is generic BIOS-based 11.3-STABLE/amd64 system with syscons console 
> driver.
> 
> /var/run/dmesg.boot starts with kernel messages without previous lines from 
> the loader.
> Specifically, I need messages about loading kernel modules with full paths.
> 

Perhaps: Set up serial console on the machine in question, then
connect a machine that's expected to be "sufficiently stable" to
the other end of a "null modem" cable & run tip(1) on the second
machine (perhaps within script(1)).

Or something similar, anyway.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Why is Trump trying to keep salient information from House investigators?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature


Re: Logging boot messages from the loader

2019-11-21 Thread Eugene Grosbein
21.11.2019 17:22, Bjoern A. Zeeb wrote:

> On 21 Nov 2019, at 9:51, Eugene Grosbein wrote:
> 
>> Hi!
>>
>> How do I get boot messages generated by loader itself written to some log 
>> after successfull boot?
>> This is generic BIOS-based 11.3-STABLE/amd64 system with syscons console 
>> driver.
>>
>> /var/run/dmesg.boot starts with kernel messages without previous lines from 
>> the loader.
>> Specifically, I need messages about loading kernel modules with full paths.
> 
> loader cannot write to the kernel message buffer as there is no kernel yet.  
> There might be possible ways to preserve that but I doubt loader is fit for 
> that task.

Some hardware does not clear memory while warm booting, so KDB trace from 
previous panic sometimes survive reboot
and ends up in /var/run/dmesg.boot for successful boot. I wonder why loader 
messages cannot be there, too.
In fact, kernel message buffer can be found even in absence of kernel :-)

I've already searched through the sources in stand/ and see there is no code to 
support this yet.

> A boot -v (boot_verbose=“YES”) might spit the information out from the kernel 
> as well.   Not sure if that helps you.  However on modern server machines a 
> boot -v often overflows the message buffer.. so you might have to tune that 
> as well.
> 
> Extracted from an older console log of a random lab machine of someone else:
> ..
> WARNING: WITNESS option enabled, expect reduced performance.^M^@
> WARNING: DIAGNOSTIC option enabled, expect reduced performance.^M^@
> Preloaded elf kernel "/boot/kernel/kernel" at 0x80e66000.^M^@
> Preloaded elf obj module "/boot/kernel/if_igb.ko" at 0x80e66968.^M^@
> Preloaded elf obj module "/boot/kernel/nfscl.ko" at 0x80e66fd0.^M^@
> Preloaded elf obj module "/boot/kernel/nfslock.ko" at 0x80e67638.^M^@
> Preloaded elf obj module "/boot/kernel/nfssvc.ko" at 0x80e67ba0.^M^@
> Preloaded elf obj module "/boot/kernel/krpc.ko" at 0x80e68088.^M^@
> Preloaded elf obj module "/boot/kernel/nfscommon.ko" at 
> 0x80e686b0.^M^@
> Preloaded elf obj module "/boot/kernel/ahci.ko" at 0x80e68d20.^M^@
> Preloaded elf obj module "/boot/kernel/cam.ko" at 0x80e69308.^M^@
> Preloaded elf obj module "/boot/kernel/mfi.ko" at 0x80e699f0.^M^@
> Preloaded elf obj module "/boot/kernel/geom_part_gpt.ko" at 
> 0x80e6a058.^M^@
> Preloaded elf obj module "/boot/kernel/sysvsem.ko" at 0x80e6a648.^M^@
> Preloaded elf obj module "/boot/kernel/sysvshm.ko" at 0x80e6acb0.^M^@
> Calibrating TSC clock ... TSC clock: 3400185886 Hz^M^@
> CPU: Intel(R) Xeon(R) CPU   X5272  @ 3.40GHz (3400.19-MHz K8-class 
> CPU)^M^@

Yes, but this only shows results of loader's work and kldstat -v shows paths 
too.
I need to know why changing modules_path in the nextboot.conf does not work
and why does loader uses stock zfs.ko insted of my patched version 
/boot/nextboot/zfs.ko
if I use nextboot.conf with 
module_path="/boot/nextboot;/boot/kernel;/boot/modules"

I have panicing production server (ZFS-only) and cannot reboot it often and
I don't wont to make cycle-boot by mistake due to wrong debugging code I might 
add to the module.


___
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: Logging boot messages from the loader

2019-11-21 Thread Bjoern A. Zeeb

On 21 Nov 2019, at 9:51, Eugene Grosbein wrote:


Hi!

How do I get boot messages generated by loader itself written to some 
log after successfull boot?
This is generic BIOS-based 11.3-STABLE/amd64 system with syscons 
console driver.


/var/run/dmesg.boot starts with kernel messages without previous lines 
from the loader.
Specifically, I need messages about loading kernel modules with full 
paths.


loader cannot write to the kernel message buffer as there is no kernel 
yet.  There might be possible ways to preserve that but I doubt loader 
is fit for that task.


A boot -v (boot_verbose=“YES”) might spit the information out from 
the kernel as well.   Not sure if that helps you.  However on modern 
server machines a boot -v often overflows the message buffer.. so you 
might have to tune that as well.


Extracted from an older console log of a random lab machine of someone 
else:

..
WARNING: WITNESS option enabled, expect reduced performance.^M^@
WARNING: DIAGNOSTIC option enabled, expect reduced performance.^M^@
Preloaded elf kernel "/boot/kernel/kernel" at 0x80e66000.^M^@
Preloaded elf obj module "/boot/kernel/if_igb.ko" at 
0x80e66968.^M^@
Preloaded elf obj module "/boot/kernel/nfscl.ko" at 
0x80e66fd0.^M^@
Preloaded elf obj module "/boot/kernel/nfslock.ko" at 
0x80e67638.^M^@
Preloaded elf obj module "/boot/kernel/nfssvc.ko" at 
0x80e67ba0.^M^@
Preloaded elf obj module "/boot/kernel/krpc.ko" at 
0x80e68088.^M^@
Preloaded elf obj module "/boot/kernel/nfscommon.ko" at 
0x80e686b0.^M^@
Preloaded elf obj module "/boot/kernel/ahci.ko" at 
0x80e68d20.^M^@
Preloaded elf obj module "/boot/kernel/cam.ko" at 
0x80e69308.^M^@
Preloaded elf obj module "/boot/kernel/mfi.ko" at 
0x80e699f0.^M^@
Preloaded elf obj module "/boot/kernel/geom_part_gpt.ko" at 
0x80e6a058.^M^@
Preloaded elf obj module "/boot/kernel/sysvsem.ko" at 
0x80e6a648.^M^@
Preloaded elf obj module "/boot/kernel/sysvshm.ko" at 
0x80e6acb0.^M^@

Calibrating TSC clock ... TSC clock: 3400185886 Hz^M^@
CPU: Intel(R) Xeon(R) CPU   X5272  @ 3.40GHz (3400.19-MHz 
K8-class CPU)^M^@

..

___
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"


Logging boot messages from the loader

2019-11-21 Thread Eugene Grosbein
Hi!

How do I get boot messages generated by loader itself written to some log after 
successfull boot?
This is generic BIOS-based 11.3-STABLE/amd64 system with syscons console driver.

/var/run/dmesg.boot starts with kernel messages without previous lines from the 
loader.
Specifically, I need messages about loading kernel modules with full paths.

___
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"