Re: ffs_truncate3 panics

On Thu, Aug 09, 2018 at 08:38:50PM +, Rick Macklem wrote: > I did notice that my code locks the vnode first and then calls > vn_start_write() > for the vn_extattr_set() calls, whereas the syscall code locks the vnode > after the vn_start_write() call. > > Does that matter? Yes, it matter.

Re: #includes and #defined

Hi, On Fri, 10 Aug 2018 12:40:48 +0800 blubee blubeeme wrote: > On Fri, Aug 10, 2018 at 8:28 AM Erich Dollansky < > freebsd.ed.li...@sumeritec.com> wrote: > > > Hi, > > > > On Fri, 10 Aug 2018 08:01:42 +0800 > > blubee blubeeme wrote: > > > > > What's the proper way to define and include F

Re: #includes and #defined

On Fri, Aug 10, 2018 at 8:28 AM Erich Dollansky < freebsd.ed.li...@sumeritec.com> wrote: > Hi, > > On Fri, 10 Aug 2018 08:01:42 +0800 > blubee blubeeme wrote: > > > What's the proper way to define and include FreeBSD amd64 in GNU > > Makefiles > > > > Do we define FreeBSD as x86_64 or amd64 also

ix SR-IOV working

hello, i have a newly provisioned VPS system from Vultr which comes stock with a 10Gbe ix interface: ix0@pci0:1:0:0: class=0x02 card=0x082315d9 chip=0x15578086 rev=0x01 hdr=0x00     vendor = 'Intel Corporation'     device = '82599 10 Gigabit Network Connection'     class  = n

Re: #includes and #defined

Hi, On Fri, 10 Aug 2018 08:01:42 +0800 blubee blubeeme wrote: > What's the proper way to define and include FreeBSD amd64 in GNU > Makefiles > > Do we define FreeBSD as x86_64 or amd64 also is it __FreeBSD__, > FreeBSD__, or __FreeBSD > > I've seen all of the above looking through different pr

#includes and #defined

What's the proper way to define and include FreeBSD amd64 in GNU Makefiles Do we define FreeBSD as x86_64 or amd64 also is it __FreeBSD__, FreeBSD__, or __FreeBSD I've seen all of the above looking through different projects. Best, Owen ___ freebsd-cur

Re: ffs_truncate3 panics

Konstantin Belousov wrote: [stuff snipped] >I wrote: >> >> I can add printf()s anywhere you suggest, but I'm not sure how you would >> catch >> this case sooner? (For example, I could print out di_extsize at the >> beginning of >> ffs_truncate(), if that would help?) >May be, add a loop at the be

Re: ffs_truncate3 panics

Rodney W. Grimes wrote: [stuff snipped] >It should be possible to design a set of VM's using bhyve, xen or ones >favorite hypervisor/virtulization platform to do "more" pNFS testing. >If you could provide a rought machine set needed to have a functional >test bed, and what should be done to "test"

Re: programs like gdb core dump

On Thu, Aug 09, 2018 at 02:54:59PM -0400, Ryan Stone wrote: > On Sat, Aug 4, 2018 at 9:17 PM Erich Dollansky > wrote: > > > > Hi, > > > > I compiled me yesterday this system: > > > > 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r337285: > > > > When restarting fortune core dumps. When trying to load the c

Re: programs like gdb core dump

On Sat, Aug 4, 2018 at 9:17 PM Erich Dollansky wrote: > > Hi, > > I compiled me yesterday this system: > > 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r337285: > > When restarting fortune core dumps. When trying to load the core dump, > gdb core dumps. > > The message is always: > > Bad system call (core

Re: programs like gdb core dump

> On 8/8/18 4:49 PM, Erich Dollansky wrote: > > Hi, > > > > here we are: > > > > http://sumeritec/FreeBSD/fortune.core > > http://sumeritec/FreeBSD/gdb.core > > > > The fortune core is from the same source as the now running system. The > > gdb core should be but I am not 100% sure. > > > > Rev

Re: programs like gdb core dump

On 8/8/18 4:49 PM, Erich Dollansky wrote: > Hi, > > here we are: > > http://sumeritec/FreeBSD/fortune.core > http://sumeritec/FreeBSD/gdb.core > > The fortune core is from the same source as the now running system. The > gdb core should be but I am not 100% sure. > > Revision: Revision: 337343

Re: Early kernel boot log?

On 8/9/18 4:02 AM, Konstantin Belousov wrote: > On Thu, Aug 09, 2018 at 10:26:06AM +0100, Johannes Lundberg wrote: >> On Thu, Aug 9, 2018 at 9:29 AM Konstantin Belousov >> wrote: >> >>> On Thu, Aug 09, 2018 at 08:54:31AM +0100, Johannes Lundberg wrote: Hi So I believe the reason I'm

Re: ffs_truncate3 panics

> Konstantin Belousov wrote: > [stuff snipped] > >> >Can you print the only buffer on the clean queue when the panic occur ? > >> ffst3 vtyp=1 bodirty=0 boclean=1 > >> buf at 0x428a110 > >> b_flags = 0x20001020, b_xflags=0x2, b_vflags=0x0 > >> b_error = 0, b_bufsize = 4096, b_bcount = 4096, b_resid

Re: ffs_truncate3 panics

On Thu, Aug 09, 2018 at 01:39:20AM +, Rick Macklem wrote: > Konstantin Belousov wrote: > [stuff snipped] > >> >Can you print the only buffer on the clean queue when the panic occur ? > >> ffst3 vtyp=1 bodirty=0 boclean=1 > >> buf at 0x428a110 > >> b_flags = 0x20001020, b_xflags=0x2, b_vflags=0x

Re: Early kernel boot log?

On Thu, Aug 09, 2018 at 10:26:06AM +0100, Johannes Lundberg wrote: > On Thu, Aug 9, 2018 at 9:29 AM Konstantin Belousov > wrote: > > > On Thu, Aug 09, 2018 at 08:54:31AM +0100, Johannes Lundberg wrote: > > > Hi > > > > > > So I believe the reason I'm not seeing and printf output in dmesg is that

Re: IPMI SOL seems to not accept characters after getty starts

On Thu, Aug 9, 2018, 03:24 Warner Losh wrote: > On Wed, Aug 8, 2018 at 6:03 PM, Allan Jude wrote: > > > On 2018-08-08 19:21, Sean Bruno wrote: > > > > > > > > > On 08/08/18 17:13, Warner Losh wrote: > > >> > > >> > > >> On Wed, Aug 8, 2018 at 4:39 PM, Sean Bruno > >>

Re: Early kernel boot log?

On Thu, Aug 9, 2018 at 9:29 AM Konstantin Belousov wrote: > On Thu, Aug 09, 2018 at 08:54:31AM +0100, Johannes Lundberg wrote: > > Hi > > > > So I believe the reason I'm not seeing and printf output in dmesg is that > > it is too early in some functions. > > For example > > machdep.s > > getmems

Re: Early kernel boot log?

On Thu, Aug 09, 2018 at 08:54:31AM +0100, Johannes Lundberg wrote: > Hi > > So I believe the reason I'm not seeing and printf output in dmesg is that > it is too early in some functions. > For example > machdep.s > getmemsize() > add_efi_map_entries() > etc > > However, these functions do cont

Early kernel boot log?

Hi So I believe the reason I'm not seeing and printf output in dmesg is that it is too early in some functions. For example machdep.s getmemsize() add_efi_map_entries() etc However, these functions do contain debug printf statements so if they're logging to somewhere, where/how can I see this?