Reproducible igb related panic 11.0-ALPHA4

[Richard Perini]

Reproducible igb related panic 11.0-ALPHA4 

OS: FreeBSD 11.0-ALPHA4 #6 r302022
Hardware: Asus P9D C224 
(integrated 

RE: Compiling 11 on a Raspberry B+ 2 failes [not in my experience for -r301975]

[Mark Millard]

Quoting Erich Dollansky erichsfreebsdlist at alogt.com Sun Jun 19 23:38:56 UTC 
2016 :

> I am trying to compile HEAD on a Raspberry and get always the following
> error.
> 
> Of course, compiling revision 302017 on amd64 works.
> 
> Erich
> 
> Last Changed Rev: 301974
> 
>  /usr/src/lib/csu/arm/crt1.c:(.text+0xb4): relocation truncated to
> fit: R_ARM_CALL against symbol `atexit' defined in .text section
> in /usr/lib/libc.a(atexit.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xbc):
> relocation truncated to fit: R_ARM_CALL against symbol `_init_tls'
> defined in .text section
> in /usr/lib/libc.a(tls.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xcc):
> relocation truncated to fit: R_ARM_CALL against symbol `atexit' defined
> in .text section
> in /usr/lib/libc.a(atexit.o) /usr/src/lib/csu/arm/crt1.c:(.text+0x174):
> relocation truncated to fit: R_ARM_CALL against symbol `exit' defined
> in .text section in /usr/lib/libc.a(exit.o) /usr/lib/crt1.o: In
> function `finalizer': /usr/src/lib/csu/arm/crt1.c:(.text+0x1ec):
> relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini'
> defined in .fini section in /usr/lib/crti.o c++: error: linker command
> failed with exit code 1 (use -v to see invocation) *** Error code 1
> 
> Stop.
> bmake[4]: stopped in /usr/src.head/usr.bin/clang/clang
> *** Error code 1
> 
> Stop.
> bmake[3]: stopped in /usr/src.head/usr.bin/clang
> *** Error code 1
> 
> Stop.
> bmake[2]: stopped in /usr/src.head
> *** Error code 1
> 
> Stop.
> bmake[1]: stopped in /usr/src.head
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/src.head
> [raspberry2]~/System (root) > 


I've done buildworld buildkernel for -r301975 on an rpi2 (not using  
WITH_META_MODE=yes) with no problem. The rpi2 was already running -r301975 via 
a amd64 -> rpi2 cross build.

You do not mention what vintage of 11.0 your -r301974 build was started from. A

uname -apKU

output would be appropriate to post as one way of indicating that.

My WITH_META_MODE=yes buidlworld buildkernel is still in process.

Later below list my src.conf showing my slightly odd choices targeting 
armv7-a/cortex-a7 explicitly. I'd be surprised if that makes a difference for 
this issue. You have not provided your src.conf or make.conf or other such 
context.

My -r301975 cross builds on amd64 targeting an rpi2 [armv7-a/cortex-a7] have 
all worked fine (no matter if WITH_META_MODE_yes was in use or not).

I've only used the system clang 3.8.0 to target armv6 in modern times.

My src.conf for rpi2 self hosted builds looks like:

> # more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host 
> TO_TYPE=armv6
> #
> KERNCONF=RPI2-NODBG
> TARGET=arm
> .if ${.MAKE.LEVEL} == 0
> TARGET_ARCH=${TO_TYPE}
> .export TARGET_ARCH
> .endif
> #
> #WITH_CROSS_COMPILER=
> WITH_SYSTEM_COMPILER=
> #
> #CPUTYPE=soft
> WITH_LIBSOFT=
> WITH_LIBCPLUSPLUS=
> WITH_BINUTILS_BOOTSTRAP=
> #WITHOUT_CLANG_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_CLANG_EXTRAS=
> WITH_LLDB=
> #
> WITH_BOOT=
> WITHOUT_LIB32=
> #
> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
> WITHOUT_GCC_BOOTSTRAP=
> WITHOUT_GCC=
> WITHOUT_GCC_IS_CC=
> WITHOUT_GNUCXX=
> #
> NO_WERROR=
> #WERROR=
> MALLOC_PRODUCTION=
> #
> WITH_DEBUG_FILES=
> #
> XCFLAGS+= -march=armv7-a -mcpu=cortex-a7
> XCXXFLAGS+= -march=armv7-a -mcpu=cortex-a7
> # There is no XCPPFLAGS but XCPP ets XCFLAGS content.

The ~/src.configs/make.conf is empty.

The amd64 -> rpi2 cross builds are only different for src.conf by:

> # diff ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host 
> ~/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host 
> 10,11c10,11
> < #WITH_CROSS_COMPILER=
> < WITH_SYSTEM_COMPILER=
> ---
> > WITH_CROSS_COMPILER=
> > WITHOUT_SYSTEM_COMPILER=
> 17c17
> < #WITHOUT_CLANG_BOOTSTRAP=
> ---
> > WITH_CLANG_BOOTSTRAP=


Showing the "on a rpi2" script that runs make for using WITH_META_MODE=yes :

> # more 
> ~/sys_build_scripts.rpi2-host/make_rpi2_nodebug_clang_bootstrap-rpi2-host.sh 
> kldload -n filemon && \
> script 
> ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-rpi2-host-$(date
>  +%Y-%m-%d:%H:%M:%S) \
> env __MAKE_CONF="/root/src.configs/make.conf" 
> SRC_ENV_CONF="/root/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host" \
> WITH_META_MODE=yes \
> MAKEOBJDIRPREFIX="/usr/obj/clang/arm.armv6" \
> make $*

My /usr/src tree has some changes/additions --but mostly for powerpc64 and 
powerpc issues:

> # svnlite status /usr/src/
> M   /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
> M   /usr/src/lib/csu/powerpc64/Makefile
> ?   /usr/src/sys/amd64/include/include
> ?   /usr/src/sys/arm/conf/RPI2-NODBG
> ?   /usr/src/sys/arm/include/include
> M   /usr/src/sys/boot/ofw/Makefile.inc
> M   /usr/src/sys/boot/powerpc/Makefile
> M   /usr/src/sys/boot/powerpc/Makefile.inc
> M   /usr/src/sys/boot/uboot/Makefile.inc
> M   /usr/src/sys/conf/Makefile.powerpc
> M   /usr/src/sys/conf/kern.mk
> M   /usr/src/sys/conf/kmod.mk
> M   

Compiling 11 on a Raspberry B+ 2 failes

[Erich Dollansky]

Hi,

I am trying to compile HEAD on a Raspberry and get always the following
error.

Of course, compiling revision 302017 on amd64 works.

Erich

Last Changed Rev: 301974

 /usr/src/lib/csu/arm/crt1.c:(.text+0xb4): relocation truncated to
fit: R_ARM_CALL against symbol `atexit' defined in .text section
in /usr/lib/libc.a(atexit.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xbc):
relocation truncated to fit: R_ARM_CALL against symbol `_init_tls'
defined in .text section
in /usr/lib/libc.a(tls.o) /usr/src/lib/csu/arm/crt1.c:(.text+0xcc):
relocation truncated to fit: R_ARM_CALL against symbol `atexit' defined
in .text section
in /usr/lib/libc.a(atexit.o) /usr/src/lib/csu/arm/crt1.c:(.text+0x174):
relocation truncated to fit: R_ARM_CALL against symbol `exit' defined
in .text section in /usr/lib/libc.a(exit.o) /usr/lib/crt1.o: In
function `finalizer': /usr/src/lib/csu/arm/crt1.c:(.text+0x1ec):
relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini'
defined in .fini section in /usr/lib/crti.o c++: error: linker command
failed with exit code 1 (use -v to see invocation) *** Error code 1

Stop.
bmake[4]: stopped in /usr/src.head/usr.bin/clang/clang
*** Error code 1

Stop.
bmake[3]: stopped in /usr/src.head/usr.bin/clang
*** Error code 1

Stop.
bmake[2]: stopped in /usr/src.head
*** Error code 1

Stop.
bmake[1]: stopped in /usr/src.head
*** Error code 1

Stop.
make: stopped in /usr/src.head
[raspberry2]~/System (root) > 
___
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"
___
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: New FreeBSD snapshots available: head (20160617 r301975)

[Glen Barber]

On Sun, Jun 19, 2016 at 10:48:02AM +0300, Ivan Klymenko wrote:
> On Sat, 18 Jun 2016 23:07:22 +
> Glen Barber  wrote:
> 
> > On Sat, Jun 18, 2016 at 02:02:50PM +, Glen Barber wrote:
> > > On Sat, Jun 18, 2016 at 10:12:07AM +0300, fidaj wrote:  
> > > > === Installation ISOs ===
> > > > 
> > > > Installation images are available for:
> > > > 
> > > > o 11.0-ALPHA4 amd64 GENERIC
> > > > o 11.0-ALPHA4 i386 GENERIC
> > > > o 11.0-ALPHA4 powerpc GENERIC
> > > > o 11.0-ALPHA4 powerpc64 GENERIC64
> > > > o 11.0-ALPHA4 sparc64 GENERIC
> > > > o 11.0-ALPHA4 armv6 BANANAPI
> > > > o 11.0-ALPHA4 armv6 BEAGLEBONE
> > > > o 11.0-ALPHA4 armv6 CUBIEBOARD
> > > > o 11.0-ALPHA4 armv6 CUBIEBOARD2
> > > > o 11.0-ALPHA4 armv6 CUBOX-HUMMINGBOARD
> > > > o 11.0-ALPHA4 armv6 GUMSTIX
> > > > o 11.0-ALPHA4 armv6 RPI-B
> > > > o 11.0-ALPHA4 armv6 RPI2
> > > > o 11.0-ALPHA4 armv6 PANDABOARD
> > > > o 11.0-ALPHA4 armv6 WANDBOARD
> > > > o 11.0-ALPHA4 aarch64 GENERIC
> > > >  
> > > > Hello. 
> > > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/
> > > > not have manifest file. 
> > > 
> > > Huh.  Yep, this is a problem.
> > > 
> > > Thank you for the report.  I'll investigate what happened here.
> > >   
> > 
> > This doesn't make sense.  The MANIFEST exists on the build machine,
> > and should have been copied as result of the distribution to the
> > mirrors.
> > 
> > I don't understand how it did not make it to the mirrors.
> > 
> > So I know, how did you discover this?
> > 
> > I *do* see the MANIFEST for amd64, so something very bizarre happened
> > here.
> > 
> > Glen
> > 
> 
> It breaks my poudriere.
> poudriere jail -c -v 11.0-ALPHA4 -a i386 -j 11_ALPHA4_i386 -m
> url=ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/

This is even stranger than originally thought.  The MANIFEST file *does*
exist now, but I did not manually put it there.  I don't think anyone
else did either.

So, I have no idea what happened, but thank you for this report.  One
more thing to double-check before sending these emails.

Glen



signature.asc
Description: PGP signature

Re: Intel Atom I2C

[Lundberg, Johannes]

Hi Ian

Thanks for the info. I'll give it a try and see if I have more success.

I'm still uncertain about the role of the DMA controller though. If data
has to be relayed through it or if using it is optional..

Maybe some further testing will reveal the truth..

On Sunday, June 19, 2016, Ian Lepore  wrote:

> On Sun, 2016-06-19 at 11:36 -0700, Lundberg, Johannes wrote:
> > Hi
> >
> > I am trying to figure out how to get I2C support on Intel Atom x5
> > (Cherryview), which should be same for Baytrail platforms.
> >
> > On the Serial I/O device (PCI device 24) there are 8 devices.
> > #0 is DMA controller
> > #1-7 are I2C controllers (1 & 2 available on GPIO pins).
> >
> > I assume that all traffic to/from the I2C controllers must go via the
> > DMA
> > controller although I'm not 100% sure.
> >
> > In page 23 in the atom-z8000-datasheet-vol-2 there is a nice table of
> > the
> > PCI configuration space.
> >
> > On Linux they have
> > i2c/busses/i2c-designware-*
> > and
> > dma/dw/*
> > that takes care of the I2C and DMA parts.
> >
> > The ichiic (ig4) driver seems to be working on this platform and
> > looking
> > through the registers it seems to be basically the same as i2c
> > -designware
> > driver, but it doesn't not detect any devices on the I2C bus
> > (/dev/smbx).
> > (I have confirmed that the devices are recognized on Linux on the
> > same
> > device.)
> >
>
> There is no way to automatically detect devices on an i2c bus.  You
> can, with some incomplete success, detect which addresses are in use.
>  Even when you can detect there is a device at a given address, there
> is no way to figure out what that device is (and in some rare cases,
> even probing for the address being in use can perturb the device).
>
> So, in the linux case, something must be telling the OS which drivers
> to attach to which addresses.  I have no idea what that mechanism might
> be, if it's not FDT.
>
> In freebsd, you can specify i2c devices using FDT data, or hints.
>
> -- Ian
>
> > We also need a Mailbox (IOSF-SB MBI) driver and it is quite simple so
> > I
> > have already ported this.
> >
> > What is left to do I guess would be to implement a DMA driver that
> > works
> > with ig4 or create a new ig4 driver that is extended to use the DMA
> > controller, and implement the DMA controller driver.
> >
> > Implementing from scratch would be quite the undertaking. Can we
> > leverage
> > any existing DMA infrastructure for this?
> >
> > Any one interested in helping?
> >
> > I have a board called "UP" which is very similar to Raspberry Pi but
> > Intel
> > SoC. It has IC20 and IC21 available on the 40-pin connector.
> > Since it's Intel most stuff just works. Thanks to mmacy accelerated
> > graphics is also working (on separate branch).
> > It really is a great board for anyone who likes to tinker :)
> >
> >
> > References:
> > http://www.up-board.org/
> > http://lxr.linux.no/#linux+v4.6.2/drivers/i2c/busses
> > http://lxr.linux.no/#linux+v4.6.2/drivers/dma/dw
> > http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-dat
> > asheet-vol-1.html
> > http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-dat
> > asheet-vol-2.html
> >
> > Other TODO stuff:
> > Port Imer's GPIO driver from DragonFly
> > Add support for S0ix sleep states (would be useful for all new Intel
> > low
> > power laptops since Haswell)
> > And more...
> >
> > Thanks!
> > /Johannes
> >
>


-- 
Sent from Gmail Mobile

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
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: Intel Atom I2C

[Ian Lepore]

On Sun, 2016-06-19 at 11:36 -0700, Lundberg, Johannes wrote:
> Hi
> 
> I am trying to figure out how to get I2C support on Intel Atom x5
> (Cherryview), which should be same for Baytrail platforms.
> 
> On the Serial I/O device (PCI device 24) there are 8 devices.
> #0 is DMA controller
> #1-7 are I2C controllers (1 & 2 available on GPIO pins).
> 
> I assume that all traffic to/from the I2C controllers must go via the
> DMA
> controller although I'm not 100% sure.
> 
> In page 23 in the atom-z8000-datasheet-vol-2 there is a nice table of
> the
> PCI configuration space.
> 
> On Linux they have
> i2c/busses/i2c-designware-*
> and
> dma/dw/*
> that takes care of the I2C and DMA parts.
> 
> The ichiic (ig4) driver seems to be working on this platform and
> looking
> through the registers it seems to be basically the same as i2c
> -designware
> driver, but it doesn't not detect any devices on the I2C bus
> (/dev/smbx).
> (I have confirmed that the devices are recognized on Linux on the
> same
> device.)
> 

There is no way to automatically detect devices on an i2c bus.  You
can, with some incomplete success, detect which addresses are in use. 
 Even when you can detect there is a device at a given address, there
is no way to figure out what that device is (and in some rare cases,
even probing for the address being in use can perturb the device).

So, in the linux case, something must be telling the OS which drivers
to attach to which addresses.  I have no idea what that mechanism might
be, if it's not FDT.

In freebsd, you can specify i2c devices using FDT data, or hints.

-- Ian

> We also need a Mailbox (IOSF-SB MBI) driver and it is quite simple so
> I
> have already ported this.
> 
> What is left to do I guess would be to implement a DMA driver that
> works
> with ig4 or create a new ig4 driver that is extended to use the DMA
> controller, and implement the DMA controller driver.
> 
> Implementing from scratch would be quite the undertaking. Can we
> leverage
> any existing DMA infrastructure for this?
> 
> Any one interested in helping?
> 
> I have a board called "UP" which is very similar to Raspberry Pi but
> Intel
> SoC. It has IC20 and IC21 available on the 40-pin connector.
> Since it's Intel most stuff just works. Thanks to mmacy accelerated
> graphics is also working (on separate branch).
> It really is a great board for anyone who likes to tinker :)
> 
> 
> References:
> http://www.up-board.org/
> http://lxr.linux.no/#linux+v4.6.2/drivers/i2c/busses
> http://lxr.linux.no/#linux+v4.6.2/drivers/dma/dw
> http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-dat
> asheet-vol-1.html
> http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-dat
> asheet-vol-2.html
> 
> Other TODO stuff:
> Port Imer's GPIO driver from DragonFly
> Add support for S0ix sleep states (would be useful for all new Intel
> low
> power laptops since Haswell)
> And more...
> 
> Thanks!
> /Johannes
> 
___
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"

Intel Atom I2C

[Lundberg, Johannes]

Hi

I am trying to figure out how to get I2C support on Intel Atom x5
(Cherryview), which should be same for Baytrail platforms.

On the Serial I/O device (PCI device 24) there are 8 devices.
#0 is DMA controller
#1-7 are I2C controllers (1 & 2 available on GPIO pins).

I assume that all traffic to/from the I2C controllers must go via the DMA
controller although I'm not 100% sure.

In page 23 in the atom-z8000-datasheet-vol-2 there is a nice table of the
PCI configuration space.

On Linux they have
i2c/busses/i2c-designware-*
and
dma/dw/*
that takes care of the I2C and DMA parts.

The ichiic (ig4) driver seems to be working on this platform and looking
through the registers it seems to be basically the same as i2c-designware
driver, but it doesn't not detect any devices on the I2C bus (/dev/smbx).
(I have confirmed that the devices are recognized on Linux on the same
device.)

We also need a Mailbox (IOSF-SB MBI) driver and it is quite simple so I
have already ported this.

What is left to do I guess would be to implement a DMA driver that works
with ig4 or create a new ig4 driver that is extended to use the DMA
controller, and implement the DMA controller driver.

Implementing from scratch would be quite the undertaking. Can we leverage
any existing DMA infrastructure for this?

Any one interested in helping?

I have a board called "UP" which is very similar to Raspberry Pi but Intel
SoC. It has IC20 and IC21 available on the 40-pin connector.
Since it's Intel most stuff just works. Thanks to mmacy accelerated
graphics is also working (on separate branch).
It really is a great board for anyone who likes to tinker :)


References:
http://www.up-board.org/
http://lxr.linux.no/#linux+v4.6.2/drivers/i2c/busses
http://lxr.linux.no/#linux+v4.6.2/drivers/dma/dw
http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-datasheet-vol-1.html
http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-datasheet-vol-2.html

Other TODO stuff:
Port Imer's GPIO driver from DragonFly
Add support for S0ix sleep states (would be useful for all new Intel low
power laptops since Haswell)
And more...

Thanks!
/Johannes

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
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: mfi timeouts at boot on ASUS Z97 motherboard with LSI 9240-4i

[Ngie Cooper]

On Thu, Apr 9, 2015 at 12:10 AM, Garrett Cooper  wrote:
...
> It booted both FreeBSD/Linux without my controller — the hardware 
> compatibility with it just sucks.
>
> Email back from ASUS, “it’s not in our compatibility list. Use another card”. 
> Uh, yeah… right. Not going to dump another $300 in an LSI card and redo my 
> RAID. Guess I’ll purchase another motherboard.
>
> Thank you for the input everyone. I’ll leave a helpful review on Newegg so 
> others don’t stumble on this either.

(following up/closing out the thread from last year on a more constructive note)

I recently had to replace my P6T-WS motherboard/CPU because it finally
bit the dust (it was 7 years old). I found a ASUS desktop board that
worked with the before mentioned LSI card -- ASUS Z170M-E D3. The
compatibility list didn't mention my LSI card specifically, but it
said that they validated the 9260-4i card, which was "close enough"
apparently.

The card's detected properly at POST, it attaches in FreeBSD, and the
volume looks AOK. The only thing that's slightly annoying is that the
chipset does some silly things with the onboard graphics when I plug
it in initially (I believe it thinks it's a graphics card..), so I had
to tweak some BIOS settings.

Thanks!
-Ngie
___
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: BBB (cpsw(4)) seems to be broken in the latest 11-current

[Maxim Sobolev]

Jim, some update from here. Running r283287 of the driver, I still see the
same "watchdog timeout" messages, but they do not lead to the interface
lockout. The traffic resumes momentarily. Which is probably why I never
paid much attention to those warnings before. Therefore, I suspect that the
new MAC code does not deal with watchdog-triggered interface reset as good
as the old code. Does it give you any ideas about what could be wrong there
by any chance?

03:54:50 CPSW watchdog cpsw0: watchdog timeout
cpsw0: Unable to cleanly shutdown transmitter
03:58:03 CPSW watchdog cpsw0: watchdog timeout
cpsw0: Unable to cleanly shutdown transmitter


On Sat, Jun 18, 2016 at 2:09 PM, Maxim Sobolev  wrote:

> Jim,
>
> Yes, I've seen those. There were just handful of revision into the driver
> between my old good kernel and now, most of them are from you guys:
>
> r299477 | gonzo | 2016-05-11 11:20:02 -0700 (ср, 11 май 2016) | 16 lines
> r298352 | pfg | 2016-04-20 08:45:55 -0700 (ср, 20 апр 2016) | 6 lines
> r297132 | loos | 2016-03-20 20:16:56 -0700 (вс, 20 мар 2016) | 5 lines
> r297043 | loos | 2016-03-18 13:24:31 -0700 (пт, 18 мар 2016) | 4 lines
> r297042 | loos | 2016-03-18 13:09:54 -0700 (пт, 18 мар 2016) | 4 lines
> r297041 | loos | 2016-03-18 13:04:34 -0700 (пт, 18 мар 2016) | 4 lines
> r296993 | loos | 2016-03-17 12:35:08 -0700 (чт, 17 мар 2016) | 24 lines
> r296980 | loos | 2016-03-16 23:23:48 -0700 (ср, 16 мар 2016) | 6 lines
> r283287 | andrew | 2015-05-22 07:25:23 -0700 (пт, 22 май 2015) | 4 lines
> (last known good one)
>
> I've reverted the driver to the state all way down to r283287, while
> keeping the rest of the kernel intact and soon will see if it works better.
> If that works fine, I'll try to bi-sect it to a single troublesome revision.
>
> -Max
>
> On Sat, Jun 18, 2016 at 12:26 PM, Jim Thompson  wrote:
>
>> There are recent changes to enable the switch and two port MAC mode.
>>
>> These were lightly tested on BBB prior to being committed.
>>
>> -- Jim
>>
>> > On Jun 18, 2016, at 11:49 AM, Maxim Sobolev 
>> wrote:
>> >
>> > Well, I am not sure either as I don't have any issue restarting it
>> > afterwards.
>> >
>> > Yes, it seems to be happening fairly reliably here. :( Happened for me
>> > again, I left it running overnight. I am 99% positive it was not the
>> case
>> > before kernel upgrade..
>> >
>> > 07:11:52 CPSW watchdog cpswss0: watchdog timeout
>> > cpswss0: Unable to cleanly shutdown transmitter
>> >
>> >
>> >> On Sat, Jun 18, 2016 at 1:09 AM, Svatopluk Kraus 
>> wrote:
>> >>
>> >> On Sat, Jun 18, 2016 at 8:50 AM, Maxim Sobolev 
>> >> wrote:
>> >>> Updated my BBB to the latest -current, immediately got this while
>> trying
>> >> to
>> >>> make world over ssh console:
>> >>>
>> >>> 06:02:17 CPSW watchdog cpswss0: watchdog timeout
>> >>> cpswss0: Unable to cleanly shutdown transmitter
>> >>
>> >> My BBB stucks in cpsw0 during boot rarely, and even soft reset (reset
>> >> button) does not help. Only hard reset (power-off) helps. I have never
>> >> had time to discover where a problem is. I'm not even sure if this is
>> >> related to your problem as I did not remember exact dmesg in my case.
>> >>
>> >> Svata
>> >>
>> >>
>> >>>
>> >>> Interface seems to be locked after that, no traffic comes in or out.
>> >>>
>> >>> This is:
>> >>>
>> >>> FreeBSD 11.0-ALPHA3 #1 ba7edef(tps65217x)-dirty: Fri Jun 17 16:22:07
>> PDT
>> >>> 2016, svn revision 301898
>> >>>
>> >>> The previous version that was rock-solid was:
>> >>>
>> >>> FreeBSD 11.0-CURRENT #0 9d390ee(tps65217x)-dirty: Mon Jul  6 19:31:30
>> PDT
>> >>> 2015, svn revision 284878
>> >>>
>> >>> I've been running buildworlds for literally days on that board,
>> because
>> >>> it's how long it takes to build on that hardware. :)
>> >>>
>> >>> I'll run it again and see if the issue re-appears.
>> >>>
>> >>> If anyone seen this or if it's known issue please let me know.
>> >>>
>> >>> Thanks!
>> >>>
>> >>> -Max
>> >>> ___
>> >>> freebsd-...@freebsd.org mailing list
>> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> >>> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org
>> "
>> > ___
>> > freebsd-...@freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> > To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"
>>
>>
>


-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
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: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4

[Konstantin Belousov]

On Sun, Jun 19, 2016 at 11:09:02AM +0200, Daniel Engberg wrote:
> I have the following in /etc/src.conf
> 
> MALLOC_PRODUCTION=yes
> WITHOUT_DEBUG_FILES=1

Most important is to remove WITHOUT_DEBUG_FILES and recompile the world.
___
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: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4

[Daniel Engberg]

On 2016-06-19 10:06, Konstantin Belousov wrote:
> On Sun, Jun 19, 2016 at 09:10:08AM +0200, Daniel Engberg wrote:
>> Hi,
>>
>> Decided to try ALPHA4 and Samba 4.3 and 4.4 doesn't seem very happy.
>>
>> Fatal error 'mutex 0x8013ec000 own 0x18cdc is on list 0x8112161a0 0x0' at 
>> line 153 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 4)
>> [2016/06/19 01:14:47.689256,  0] ../lib/util/fault.c:78(fault_report)
>>   ===
>> [2016/06/19 01:14:47.689450,  0] ../lib/util/fault.c:79(fault_report)
>>   INTERNAL ERROR: Signal 6 in pid 45222 (4.4.3)
>>   Please read the Trouble-Shooting section of the Samba HOWTO
>> [2016/06/19 01:14:47.689479,  0] ../lib/util/fault.c:81(fault_report)
>>   ===
>> [2016/06/19 01:14:47.689498,  0] ../source3/lib/util.c:791(smb_panic_s3)
>>   PANIC (pid 45222): internal error
>> [2016/06/19 01:14:47.690577,  0] ../source3/lib/util.c:902(log_stack_trace)
>>   BACKTRACE: 6 stack frames:
>>#0 0x803c16fe8  at 
>> /usr/local/lib/samba4/libsmbconf.so.0
>>#1 0x803c16ed2  at 
>> /usr/local/lib/samba4/libsmbconf.so.0
>>#2 0x801696dad  at 
>> /usr/local/lib/samba4/libsamba-util.so.0
>>#3 0x801696c57  at 
>> /usr/local/lib/samba4/libsamba-util.so.0
>>#4 0x8014616df  at /lib/libthr.so.3
>>#5 0x801460cbf  at /lib/libthr.so.3
>> [2016/06/19 01:14:47.690686,  0] ../source3/lib/dumpcore.c:313(dump_core)
>>   unable to change to %N.core
>>   refusing to dump core
>>
>> Fatal error 'mutex 0x8013eb000 own 0x18d3d is on list 0x812e161a0 0x0' at 
>> line 153 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 4)
>> [2016/06/19 01:26:41.063681,  0] ../lib/util/fault.c:78(fault_report)
>>   ===
>> [2016/06/19 01:26:41.063827,  0] ../lib/util/fault.c:79(fault_report)
>>   INTERNAL ERROR: Signal 6 in pid 61297 (4.3.9)
>>   Please read the Trouble-Shooting section of the Samba HOWTO
>> [2016/06/19 01:26:41.063844,  0] ../lib/util/fault.c:81(fault_report)
>>   ===
>> [2016/06/19 01:26:41.063855,  0] ../source3/lib/util.c:789(smb_panic_s3)
>>   PANIC (pid 61297): internal error
>> [2016/06/19 01:26:41.064679,  0] ../source3/lib/util.c:900(log_stack_trace)
>>   BACKTRACE: 6 stack frames:
>>#0 0x803846eb8  at /usr/local/lib/libsmbconf.so.0
>>#1 0x803846da2  at /usr/local/lib/libsmbconf.so.0
>>#2 0x80168c12d  at /usr/local/lib/libsamba-util.so.0
>>#3 0x80168bfd7  at /usr/local/lib/libsamba-util.so.0
>>#4 0x8014606df  at /lib/libthr.so.3
>>#5 0x80145fcbf  at /lib/libthr.so.3
>> [2016/06/19 01:26:41.064747,  0] ../source3/lib/dumpcore.c:313(dump_core)
>>   unable to change to %N.core
>>   refusing to dump core
>>
>> This occurs immediately when you start Samba so it's easy to replicate.
>> I know that 4.3 worked on r298887 for sure, I'm going to try this in VM too 
>> but I'd apperciate if anyone else could give this a go.
>>
>> I noticed that there were some changes in libthr which might be a clue
>>
> 
> Please convince samba to allow to dump core on assert (I have no idea how),
> then get a backtrace from the core, using ports/devel/gdb.  After that I
> may know where to look next.
> 
Hi,

Thanks for the quick reply, I'm not familiar to gdb but from what I found this 
seems to be correct way.

sysctl kern.corefile=/var/log/samba4/%N.core (for whatever reason %N.core only 
doesn't seem to make Samba happy)

/usr/local/bin/gdb /usr/local/sbin/smbd /var/log/samba4/smbd.core
GNU gdb (GDB) 7.11.1 [GDB v7.11.1 for FreeBSD]
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/sbin/smbd...done.
[New LWP 101688]
Core was generated by `smbd'.
Program terminated with signal SIGABRT, Aborted.
#0  0x0008055ed10a in ?? ()
(gdb) bt
#0  0x0008055ed10a in ?? ()
#1  0x0008055ed0db in ?? ()
#2  0x00018d38 in ?? ()
#3  0x8979efeec3bd9290 in ?? ()
#4  0x7fffd2a4 in ?? ()
#5  0x0008020f6020 

Re: Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4

[Konstantin Belousov]

On Sun, Jun 19, 2016 at 09:10:08AM +0200, Daniel Engberg wrote:
> Hi,
> 
> Decided to try ALPHA4 and Samba 4.3 and 4.4 doesn't seem very happy.
> 
> Fatal error 'mutex 0x8013ec000 own 0x18cdc is on list 0x8112161a0 0x0' at 
> line 153 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 4)
> [2016/06/19 01:14:47.689256,  0] ../lib/util/fault.c:78(fault_report)
>   ===
> [2016/06/19 01:14:47.689450,  0] ../lib/util/fault.c:79(fault_report)
>   INTERNAL ERROR: Signal 6 in pid 45222 (4.4.3)
>   Please read the Trouble-Shooting section of the Samba HOWTO
> [2016/06/19 01:14:47.689479,  0] ../lib/util/fault.c:81(fault_report)
>   ===
> [2016/06/19 01:14:47.689498,  0] ../source3/lib/util.c:791(smb_panic_s3)
>   PANIC (pid 45222): internal error
> [2016/06/19 01:14:47.690577,  0] ../source3/lib/util.c:902(log_stack_trace)
>   BACKTRACE: 6 stack frames:
>#0 0x803c16fe8  at 
> /usr/local/lib/samba4/libsmbconf.so.0
>#1 0x803c16ed2  at /usr/local/lib/samba4/libsmbconf.so.0
>#2 0x801696dad  at 
> /usr/local/lib/samba4/libsamba-util.so.0
>#3 0x801696c57  at 
> /usr/local/lib/samba4/libsamba-util.so.0
>#4 0x8014616df  at /lib/libthr.so.3
>#5 0x801460cbf  at /lib/libthr.so.3
> [2016/06/19 01:14:47.690686,  0] ../source3/lib/dumpcore.c:313(dump_core)
>   unable to change to %N.core
>   refusing to dump core
> 
> Fatal error 'mutex 0x8013eb000 own 0x18d3d is on list 0x812e161a0 0x0' at 
> line 153 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 4)
> [2016/06/19 01:26:41.063681,  0] ../lib/util/fault.c:78(fault_report)
>   ===
> [2016/06/19 01:26:41.063827,  0] ../lib/util/fault.c:79(fault_report)
>   INTERNAL ERROR: Signal 6 in pid 61297 (4.3.9)
>   Please read the Trouble-Shooting section of the Samba HOWTO
> [2016/06/19 01:26:41.063844,  0] ../lib/util/fault.c:81(fault_report)
>   ===
> [2016/06/19 01:26:41.063855,  0] ../source3/lib/util.c:789(smb_panic_s3)
>   PANIC (pid 61297): internal error
> [2016/06/19 01:26:41.064679,  0] ../source3/lib/util.c:900(log_stack_trace)
>   BACKTRACE: 6 stack frames:
>#0 0x803846eb8  at /usr/local/lib/libsmbconf.so.0
>#1 0x803846da2  at /usr/local/lib/libsmbconf.so.0
>#2 0x80168c12d  at /usr/local/lib/libsamba-util.so.0
>#3 0x80168bfd7  at /usr/local/lib/libsamba-util.so.0
>#4 0x8014606df  at /lib/libthr.so.3
>#5 0x80145fcbf  at /lib/libthr.so.3
> [2016/06/19 01:26:41.064747,  0] ../source3/lib/dumpcore.c:313(dump_core)
>   unable to change to %N.core
>   refusing to dump core
> 
> This occurs immediately when you start Samba so it's easy to replicate.
> I know that 4.3 worked on r298887 for sure, I'm going to try this in VM too 
> but I'd apperciate if anyone else could give this a go.
> 
> I noticed that there were some changes in libthr which might be a clue
> 

Please convince samba to allow to dump core on assert (I have no idea how),
then get a backtrace from the core, using ports/devel/gdb.  After that I
may know where to look next.
___
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: New FreeBSD snapshots available: head (20160617 r301975)

[Ivan Klymenko]

On Sat, 18 Jun 2016 23:07:22 +
Glen Barber  wrote:

> On Sat, Jun 18, 2016 at 02:02:50PM +, Glen Barber wrote:
> > On Sat, Jun 18, 2016 at 10:12:07AM +0300, fidaj wrote:  
> > > === Installation ISOs ===
> > > 
> > > Installation images are available for:
> > > 
> > > o 11.0-ALPHA4 amd64 GENERIC
> > > o 11.0-ALPHA4 i386 GENERIC
> > > o 11.0-ALPHA4 powerpc GENERIC
> > > o 11.0-ALPHA4 powerpc64 GENERIC64
> > > o 11.0-ALPHA4 sparc64 GENERIC
> > > o 11.0-ALPHA4 armv6 BANANAPI
> > > o 11.0-ALPHA4 armv6 BEAGLEBONE
> > > o 11.0-ALPHA4 armv6 CUBIEBOARD
> > > o 11.0-ALPHA4 armv6 CUBIEBOARD2
> > > o 11.0-ALPHA4 armv6 CUBOX-HUMMINGBOARD
> > > o 11.0-ALPHA4 armv6 GUMSTIX
> > > o 11.0-ALPHA4 armv6 RPI-B
> > > o 11.0-ALPHA4 armv6 RPI2
> > > o 11.0-ALPHA4 armv6 PANDABOARD
> > > o 11.0-ALPHA4 armv6 WANDBOARD
> > > o 11.0-ALPHA4 aarch64 GENERIC
> > >  
> > > Hello. 
> > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/
> > > not have manifest file. 
> > 
> > Huh.  Yep, this is a problem.
> > 
> > Thank you for the report.  I'll investigate what happened here.
> >   
> 
> This doesn't make sense.  The MANIFEST exists on the build machine,
> and should have been copied as result of the distribution to the
> mirrors.
> 
> I don't understand how it did not make it to the mirrors.
> 
> So I know, how did you discover this?
> 
> I *do* see the MANIFEST for amd64, so something very bizarre happened
> here.
> 
> Glen
> 

It breaks my poudriere.
poudriere jail -c -v 11.0-ALPHA4 -a i386 -j 11_ALPHA4_i386 -m
url=ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/
___
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"

Samba 4.3 and 4.4 crashes on FreeBSD 11-ALPHA4

[Daniel Engberg]

Hi,

Decided to try ALPHA4 and Samba 4.3 and 4.4 doesn't seem very happy.

Fatal error 'mutex 0x8013ec000 own 0x18cdc is on list 0x8112161a0 0x0' at line 
153 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 4)
[2016/06/19 01:14:47.689256,  0] ../lib/util/fault.c:78(fault_report)
  ===
[2016/06/19 01:14:47.689450,  0] ../lib/util/fault.c:79(fault_report)
  INTERNAL ERROR: Signal 6 in pid 45222 (4.4.3)
  Please read the Trouble-Shooting section of the Samba HOWTO
[2016/06/19 01:14:47.689479,  0] ../lib/util/fault.c:81(fault_report)
  ===
[2016/06/19 01:14:47.689498,  0] ../source3/lib/util.c:791(smb_panic_s3)
  PANIC (pid 45222): internal error
[2016/06/19 01:14:47.690577,  0] ../source3/lib/util.c:902(log_stack_trace)
  BACKTRACE: 6 stack frames:
   #0 0x803c16fe8  at 
/usr/local/lib/samba4/libsmbconf.so.0
   #1 0x803c16ed2  at /usr/local/lib/samba4/libsmbconf.so.0
   #2 0x801696dad  at /usr/local/lib/samba4/libsamba-util.so.0
   #3 0x801696c57  at 
/usr/local/lib/samba4/libsamba-util.so.0
   #4 0x8014616df  at /lib/libthr.so.3
   #5 0x801460cbf  at /lib/libthr.so.3
[2016/06/19 01:14:47.690686,  0] ../source3/lib/dumpcore.c:313(dump_core)
  unable to change to %N.core
  refusing to dump core

Fatal error 'mutex 0x8013eb000 own 0x18d3d is on list 0x812e161a0 0x0' at line 
153 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 4)
[2016/06/19 01:26:41.063681,  0] ../lib/util/fault.c:78(fault_report)
  ===
[2016/06/19 01:26:41.063827,  0] ../lib/util/fault.c:79(fault_report)
  INTERNAL ERROR: Signal 6 in pid 61297 (4.3.9)
  Please read the Trouble-Shooting section of the Samba HOWTO
[2016/06/19 01:26:41.063844,  0] ../lib/util/fault.c:81(fault_report)
  ===
[2016/06/19 01:26:41.063855,  0] ../source3/lib/util.c:789(smb_panic_s3)
  PANIC (pid 61297): internal error
[2016/06/19 01:26:41.064679,  0] ../source3/lib/util.c:900(log_stack_trace)
  BACKTRACE: 6 stack frames:
   #0 0x803846eb8  at /usr/local/lib/libsmbconf.so.0
   #1 0x803846da2  at /usr/local/lib/libsmbconf.so.0
   #2 0x80168c12d  at /usr/local/lib/libsamba-util.so.0
   #3 0x80168bfd7  at /usr/local/lib/libsamba-util.so.0
   #4 0x8014606df  at /lib/libthr.so.3
   #5 0x80145fcbf  at /lib/libthr.so.3
[2016/06/19 01:26:41.064747,  0] ../source3/lib/dumpcore.c:313(dump_core)
  unable to change to %N.core
  refusing to dump core

This occurs immediately when you start Samba so it's easy to replicate.
I know that 4.3 worked on r298887 for sure, I'm going to try this in VM too but 
I'd apperciate if anyone else could give this a go.

I noticed that there were some changes in libthr which might be a clue

Best regards,
Daniel Engberg
___
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"