Re: CURRENT: re(4) crashing system

2016-11-06 Thread YongHyeon PYUN 
On Sun, Nov 06, 2016 at 01:20:36PM +0100, Hartmann, O. wrote:
> On Mon, 31 Oct 2016 11:12:22 +0900
> YongHyeon PYUN  wrote:
> 
> > On Fri, Oct 28, 2016 at 09:21:13PM +0200, Hartmann, O. wrote:
> > > On Thu, 27 Oct 2016 10:00:04 +0900
> > > YongHyeon PYUN  wrote:
> > >   
> > > > On Tue, Oct 25, 2016 at 07:03:38AM +0200, Hartmann, O. wrote:  
> > > > > On Tue, 25 Oct 2016 11:05:38 +0900
> > > > > YongHyeon PYUN  wrote:
> > > > > 
> > > > 
> > > > [...]
> > > >   
> > > > > > I'm not sure but it's likely the issue is related with
> > > > > > EEE/Green Ethernet handling. EEE is negotiated feature with
> > > > > > link partner. If you directly connect your laptop to non-EEE
> > > > > > capable link partner like other re(4) box without switches
> > > > > > you may be able to tell whether the issue is EEE/Green
> > > > > > Ethernet related one or not.
> > > > > 
> > > > > Me either since when I discovered a problem the first time with
> > > > > CURRENT, that was the Friday before last week's Friday, there
> > > > > was a unlucky coicidence: I got the new switch, FreeBSD
> > > > > introduced a serious bug and I changed the NICs.
> > > > > 
> > > > > The laptop, the last in the row of re(4) equipted systems on
> > > > > which I use the Realtek NIC, does well now with Green IT
> > > > > technology, but crashes on plugging/unplugging - not on each
> > > > > event, but at least in one of ten.
> > > > 
> > > > Hmm, it seems you know how to trigger the issue. When you unplug
> > > > UTP cable was there active network traffic on re(4) device?
> > > > It would be helpful to know which event triggers the crash(e.g.
> > > > unplugging or plugging).  And would you show me backtrace of
> > > > panic? 
> > > > > I guess the Green IT issue is more a unlucky guess of mine and
> > > > > went hand in hand with the problem I face with CURRENT right
> > > > > now on some older, Non UEFI machines.
> > > > > 
> > > > 
> > > > Ok.
> > > > 
> > > > [...]  
> > > > > 
> > > > > As requested the informations about re0 and rgephy0 on the
> > > > > laptop (Lenovo E540) 
> > > > > 
> > > > > [...]
> > > > > 
> > > > > rgephy0:  PHY 1 on miibus0
> > > > > rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow,
> > > > > 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX,
> > > > > 1000baseT-FDX-master, 1000baseT-FDX-flow,
> > > > > 1000baseT-FDX-flow-master, auto, auto-flow
> > > > > 
> > > > > re0: 
> > > > > port 0x3000-0x30ff mem
> > > > > 0xf0d04000-0xf0d04fff,0xf0d0-0xf0d03fff at device 0.0 on
> > > > > pci2 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip
> > > > > rev. 0x5080 re0: MAC rev. 0x0010
> > > > 
> > > > This looks like 8168GU controller.
> > > > 
> > > > [...]
> > > >   
> > > > > I use options netmap in kernel config, but the problem is also
> > > > > present without this option - just for the record.
> > > > > 
> > > > 
> > > > Yup, netmap(4) has nothing to do with the crash.
> > > > 
> > > > Thanks.  
> > > 
> > > Attached, you'll find the backtrace of the crash. This time it was
> > > really easy - just one pull of the LAN cabling - and we are
> > > happy :-/
> > > 
> > > Please let me know if you need something else. I will return to
> > > normal operations (disabling debugging) due to CURRENT is very
> > > unstable at the moment on other hosts beyond r307157.
> > >   
> > 
> > It seems the attachment was stripped.
> 
> This time I hope I got it right!
> 
> Attached you'll find the latest CURRENT's backtrace on the provoked
> crash (plug and unplug).
> 
> I also saved the kernel and coredump, so if you need me to do further
> investigations,please let me know.
> 

Thanks a lot for the backtrace.  This backtrace is not the one I
expected and I guess the issue is related with cached route removal
on interface down.  Quick looking over the code didn't reveal the
cause of crash(I'm not familiar with that part code).  Probably
gnn@ may have better idea what's going on here(CCed).

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

hang during kldload if_bwn

2016-11-06 Thread Justin Hibbits 
Hi folks,

I have a PowerBook G4 with an Airport Extreme card (bwi/bwn, can use
either one), and found if I don't have the exact correct firmware it
hangs.  Here's a snippet of WITNESS before it hangs:

siba_bwn0:  mem
0xa0004000-0xa0005fff irq 52 at device 17.0 on pci1 bwn0 on siba_bwn0
bwn0: bwn_attach_core: forcing 2GHz only; no dual-band support for PHY
bwn0: WLAN (chipid 0x4318 rev 9) PHY (analog 3 type 2 rev 7) RADIO
(manuf 0x17f ver 0x2050 rev 8) bwn0: DMA (32 bits)
wlan0: Ethernet address: 00:14:51:7d:60:39
bwn0: ucode fw: ucode5
Sleeping on "fwload" with the following non-sleepable locks held:
exclusive sleep mutex bwn0 (network driver) r = 0 (0xd2e57004) locked
@ /usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c:814 stack backtrace:
#0 0x50fd64 at witness_warn+0x2c0
#1 0x49ef0c at _sleep+0xc8
#2 0x4e2e10 at firmware_get+0x120
#3 0xd2d0a6e4 at bwn_fw_get+0xe4
#4 0xd2d1057c at bwn_fw_gets+0x1ac
#5 0xd2d13130 at bwn_core_init+0x28c
#6 0xd2d151f0 at bwn_init+0x310
#7 0xd2d15408 at bwn_parent+0x80
#8 0xd2da794c at parent_updown+0x1c
#9 0x4fe6dc at taskqueue_run_locked+0x178
#10 0x4ff468 at taskqueue_thread_loop+0xa8
#11 0x44c99c at fork_exit+0xc0
#12 0x8229dc at fork_trampoline+0xc
bwn_v4_ucode5: could not load firmware image, error 2
bwn0: the fw file(bwn_v4_ucode5) not found
bwn0: ucode fw: ucode5
Sleeping on "fwload" with the following non-sleepable locks held:
exclusive sleep mutex bwn0 (network driver) r = 0 (0xd2e57004) locked
@ /usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c:814 stack backtrace:
#0 0x50fd64 at witness_warn+0x2c0
#1 0x49ef0c at _sleep+0xc8
#2 0x4e2e10 at firmware_get+0x120
#3 0xd2d0a6e4 at bwn_fw_get+0xe4
#4 0xd2d1057c at bwn_fw_gets+0x1ac
#5 0xd2d13130 at bwn_core_init+0x28c
#6 0xd2d151f0 at bwn_init+0x310
#7 0xd2d15408 at bwn_parent+0x80
#8 0xd2da794c at parent_updown+0x1c
#9 0x4fe6dc at taskqueue_run_locked+0x178
#10 0x4ff468 at taskqueue_thread_loop+0xa8
#11 0x44c99c at fork_exit+0xc0
#12 0x8229dc at fork_trampoline+0xc
bwn-open_v4_ucode5: could not load firmware image, error 2
bwn0: the fw file(bwn-open_v4_ucode5) not found


Creating a symlink in /boot/modules of bwn_v4_ucode5.ko ->
bwn_v4_ucode.ko makes it not hang, but it still triggers WITNESS.

- Justin
___
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: [poudriere]: lang/php56 is unwilling to build with ZTS

2016-11-06 Thread O. Hartmann 
Am Thu, 3 Nov 2016 12:03:55 +1000
Dima Panov  schrieb:

> 01.11.16 20:49, O. Hartmann пишет:
> > Obviously I ran into a problem with recent poudriere on CURRENT building 
> > ports
> > in a CURRENT jail.
> > 
> > Building threaded www/apache24 requires lang/php56 having option ZTS set. I 
> > did
> > so. I tried to rebuild all depending ports, but I run into rpoblems then 
> > with
> > php56: for instance, textproc/php56-xmlreader fails to build, the poudriere 
> > log
> > gives the reason:
> >   
> > ===>   php56-xmlreader-5.6.27 depends on  
> > file: /usr/local/lib/php/20131226/dom.so - not found
> > 
> > On systems with properly set ZTS, the expected folder for PHP modules would 
> > be
> > 
> > /usr/local/lib/php/20131226-zts/
> > 
> > When I first discovered this, I tried to delete and rebuild lang/php56 from
> > packages - definitely with option ZTS set - but the error is persistant.
> > 
> > I'm unwilling to rebuild ALL thousands of packages, so I need some advice 
> > how
> > to solve this problem.
> > 
> > Please CC me, I do not subscribe the list. Thanks.
> > 
> > Thank you very much in advance,
> >   
> 
> Some tweaks with poudriere build environment requred to suport ZTS build:
> 
> cat /usr/local/poudriere.d/make.conf
> 
> # www/apache24
> WITH_MPM=event

I used WITH_MPM=worker which should provide also a threaded Apache 2.4

> 
> 
> Meanwhile, I've got today another problem with poudriere. 
> 
> 'poudriere options' with non-default portstree uses options subdir from 
> default tree, 
> but 'poudriere bulk' hooks up the right options tree, without configured 
> options, at
> all. 
> 
> 
> 
> 

The problem must be located around the lang/php56 port/package. When ZTS 
enabled, I would
expect to find php plugin libs in 

/usr/local/lib/php/20131226-zts/

but the failing ports report all a non-available /usr/local/lib/php/20131226/ 
folder,
please consider the difference!

At this very moment, even a fresh clean start of the poudriere build does end 
up in
failures for the follwoing ports:

textproc/php56-wddx
databases/php56-pdo_sqlite
databases/php56-pdo_pgsql
databases/php56-pdo_mysql
devel/pear
textproc/php56-xmlreader
textproc/php56-xsl
net/phpldapadmin
databases/phppgadmin
devel/websvn

This failure occurs only in poudriere. If the ports are installed the proper way
via /usr/ports and make, everything seems correct.


pgpxXPmY82x06.pgp
Description: OpenPGP digital signature

Re: New warnings from WITNESS

2016-11-06 Thread Michael Tuexen 

> On 6 Nov 2016, at 19:41, Scott Long  wrote:
> 
> 
>> On Nov 6, 2016, at 11:01 AM, Michael Tuexen  wrote:
>> 
>>> On 6 Nov 2016, at 15:39, Konstantin Belousov  wrote:
>>> 
>>> On Sun, Nov 06, 2016 at 02:17:45PM +0100, Michael Tuexen wrote:
> On 6 Nov 2016, at 13:28, Konstantin Belousov  wrote:
> 
> On Sun, Nov 06, 2016 at 12:50:12PM +0100, Michael Tuexen wrote:
>> bus_dmamap_create with the following non-sleepable locks held:
>> exclusive sleep mutex mpt (mpt) r = 0 (0xfee2f008) locked @ 
>> dev/mpt/mpt.c:2287
>> stack backtrace:
>> #0 0x80ac0300 at witness_debugger+0x70
>> #1 0x80ac15e7 at witness_warn+0x3d7
>> #2 0x81055fef at bus_dmamap_create+0x2f
>> #3 0x80678a25 at mpt_configure_ioc+0x3a5
>> #4 0x80677476 at mpt_attach+0x226
>> #5 0x80683299 at mpt_pci_attach+0x9c9
>> #6 0x80a9478d at device_attach+0x41d
>> #7 0x80a9595a at bus_generic_attach+0x4a
>> #8 0x806ebe75 at pci_attach+0xd5
>> #9 0x80a9478d at device_attach+0x41d
>> #10 0x80a9595a at bus_generic_attach+0x4a
>> #11 0x803c11a2 at acpi_pcib_acpi_attach+0x402
>> #12 0x80a9478d at device_attach+0x41d
>> #13 0x80a9595a at bus_generic_attach+0x4a
>> #14 0x803b4c8f at acpi_attach+0xdbf
>> #15 0x80a9478d at device_attach+0x41d
>> #16 0x80a9595a at bus_generic_attach+0x4a
>> #17 0x80ee03e3 at nexus_acpi_attach+0x73
>> 
>> ... and so on. Not sure which revision introduced it...
> r308268
> 
> I believe that this is an mpt(4) driver issue, which calls
> bus_dmamap_create(9) with the mpt mutex held.
 OK. Whom to contact? Or are you willing to look into it?
 I haven't worked in that area...
>>> 
>>> I am really not sure.  Looking at the svn history is not very encouraging.
>> Hmm. Time to change my setup, I guess...
>>> 
>>> Might be try freebsd-scsi@ as well.
>> I dropped them an e-mail...
>> 
>> 
> 
> Please see my response on that list.
Will do once it shows up in the archive since I'm not subscribed
to that list...

Best regards
Michael
> 
> Scott
> 
> 

___
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 warnings from WITNESS

2016-11-06 Thread Scott Long 

> On Nov 6, 2016, at 11:01 AM, Michael Tuexen  wrote:
> 
>> On 6 Nov 2016, at 15:39, Konstantin Belousov  wrote:
>> 
>> On Sun, Nov 06, 2016 at 02:17:45PM +0100, Michael Tuexen wrote:
 On 6 Nov 2016, at 13:28, Konstantin Belousov  wrote:
 
 On Sun, Nov 06, 2016 at 12:50:12PM +0100, Michael Tuexen wrote:
> bus_dmamap_create with the following non-sleepable locks held:
> exclusive sleep mutex mpt (mpt) r = 0 (0xfee2f008) locked @ 
> dev/mpt/mpt.c:2287
> stack backtrace:
> #0 0x80ac0300 at witness_debugger+0x70
> #1 0x80ac15e7 at witness_warn+0x3d7
> #2 0x81055fef at bus_dmamap_create+0x2f
> #3 0x80678a25 at mpt_configure_ioc+0x3a5
> #4 0x80677476 at mpt_attach+0x226
> #5 0x80683299 at mpt_pci_attach+0x9c9
> #6 0x80a9478d at device_attach+0x41d
> #7 0x80a9595a at bus_generic_attach+0x4a
> #8 0x806ebe75 at pci_attach+0xd5
> #9 0x80a9478d at device_attach+0x41d
> #10 0x80a9595a at bus_generic_attach+0x4a
> #11 0x803c11a2 at acpi_pcib_acpi_attach+0x402
> #12 0x80a9478d at device_attach+0x41d
> #13 0x80a9595a at bus_generic_attach+0x4a
> #14 0x803b4c8f at acpi_attach+0xdbf
> #15 0x80a9478d at device_attach+0x41d
> #16 0x80a9595a at bus_generic_attach+0x4a
> #17 0x80ee03e3 at nexus_acpi_attach+0x73
> 
> ... and so on. Not sure which revision introduced it...
 r308268
 
 I believe that this is an mpt(4) driver issue, which calls
 bus_dmamap_create(9) with the mpt mutex held.
>>> OK. Whom to contact? Or are you willing to look into it?
>>> I haven't worked in that area...
>> 
>> I am really not sure.  Looking at the svn history is not very encouraging.
> Hmm. Time to change my setup, I guess...
>> 
>> Might be try freebsd-scsi@ as well.
> I dropped them an e-mail...
> 
> 

Please see my response on that list.

Scott


___
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: [RFC] remove GNU rcs from FreeBSD 12

2016-11-06 Thread Mark Linimon 
On Sun, Nov 06, 2016 at 12:09:30PM +0100, Eivind Nicolay Evensen wrote:
> I also thought that perl was a good example of another piece of software
> that once was provided and no longer is.

Yes, that's true, but somewhat different.

perl was removed because keeping it became incompatible with the concept
of the -stable branches.  perl development was simply moving faster than
FreeBSD major releases, leading to FreeBSD having to keep maintaining an
obsolete piece of software far past the time upstream had dropped support
for it.

Of course this is a problem with any software that FreeBSD imports, but
IIUC this may have been the most painful case.  (I was just starting to
use FreeBSD at the time, so was really just an observer.)

mcl
___
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 warnings from WITNESS

2016-11-06 Thread Michael Tuexen 
> On 6 Nov 2016, at 15:39, Konstantin Belousov  wrote:
> 
> On Sun, Nov 06, 2016 at 02:17:45PM +0100, Michael Tuexen wrote:
>>> On 6 Nov 2016, at 13:28, Konstantin Belousov  wrote:
>>> 
>>> On Sun, Nov 06, 2016 at 12:50:12PM +0100, Michael Tuexen wrote:
 bus_dmamap_create with the following non-sleepable locks held:
 exclusive sleep mutex mpt (mpt) r = 0 (0xfee2f008) locked @ 
 dev/mpt/mpt.c:2287
 stack backtrace:
 #0 0x80ac0300 at witness_debugger+0x70
 #1 0x80ac15e7 at witness_warn+0x3d7
 #2 0x81055fef at bus_dmamap_create+0x2f
 #3 0x80678a25 at mpt_configure_ioc+0x3a5
 #4 0x80677476 at mpt_attach+0x226
 #5 0x80683299 at mpt_pci_attach+0x9c9
 #6 0x80a9478d at device_attach+0x41d
 #7 0x80a9595a at bus_generic_attach+0x4a
 #8 0x806ebe75 at pci_attach+0xd5
 #9 0x80a9478d at device_attach+0x41d
 #10 0x80a9595a at bus_generic_attach+0x4a
 #11 0x803c11a2 at acpi_pcib_acpi_attach+0x402
 #12 0x80a9478d at device_attach+0x41d
 #13 0x80a9595a at bus_generic_attach+0x4a
 #14 0x803b4c8f at acpi_attach+0xdbf
 #15 0x80a9478d at device_attach+0x41d
 #16 0x80a9595a at bus_generic_attach+0x4a
 #17 0x80ee03e3 at nexus_acpi_attach+0x73
 
 ... and so on. Not sure which revision introduced it...
>>> r308268
>>> 
>>> I believe that this is an mpt(4) driver issue, which calls
>>> bus_dmamap_create(9) with the mpt mutex held.
>> OK. Whom to contact? Or are you willing to look into it?
>> I haven't worked in that area...
> 
> I am really not sure.  Looking at the svn history is not very encouraging.
Hmm. Time to change my setup, I guess...
> 
> Might be try freebsd-scsi@ as well.
I dropped them an e-mail...

Best regards
Michael

___
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: [RFC] remove GNU rcs from FreeBSD 12

2016-11-06 Thread Eivind Nicolay Evensen 
On Sat, Nov 05, 2016 at 05:31:47PM -0400, Mark Heily wrote:
> On Sat, Nov 5, 2016 at 9:07 AM, Ronald Klop  wrote:
> 
> > On Thu, 03 Nov 2016 03:17:23 +0100, Julian Elischer 
> > wrote:
> >
> > On 26/10/2016 2:27 AM, Eivind Nicolay Evensen wrote:
> >>
> >>> On Sun, Sep 11, 2016 at 03:38:04PM +0200, Baptiste Daroussin wrote:
> >>>
>  hi,
> 
>  For long we are planning to remove GNU rcs from base, after a failed
>  attempt
>  before FreeBSD 10.0. Let see where we are to be able to remove it from
>  FreeBSD
>  12.
> 
> >>>
> >> why should we remove it?
> >>
> >
> It should be removed from base because the license was changed to GPLv3+
> about six years ago. The obsolete GPLv2 version currently in base is no
> longer maintained. I agree with the sentiment that RCS should be an
> optional component available from ports.

In my use of it, just plain keeping versions of files containing
only text in them, I haven't seen the need for a maintainer since
there has not been any problems. Is there a real problem I should be aware of?



-- 
Eivind
___
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: [RFC] remove GNU rcs from FreeBSD 12

2016-11-06 Thread Eivind Nicolay Evensen 
On Sat, Nov 05, 2016 at 08:19:15PM -0500, Mark Linimon wrote:
> On Thu, Nov 03, 2016 at 10:17:23AM +0800, Julian Elischer wrote:
> > why should we remove it?
> 
> IIUC the plan for several years has been to remove all GPLed software
> from base.
> 
> But in any case the conversation is moot.  It was removed from head
> on 20161015 by bapt:
> 
>   https://svnweb.freebsd.org/base?view=revision=307351

It already being removed doesn't make me, and most likely nobody else
who also wanted it to stay, want it in base any less. Thanks though
for the headsup for us that doesn't use current.

> UPDATING contains notes about how to install it on your system.

Thanks for the tip, though I'll rather keep it in my own tree,
like I did with cvs when that was taken away.


-- 
Eivind
___
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 warnings from WITNESS

2016-11-06 Thread Konstantin Belousov 
On Sun, Nov 06, 2016 at 02:17:45PM +0100, Michael Tuexen wrote:
> > On 6 Nov 2016, at 13:28, Konstantin Belousov  wrote:
> > 
> > On Sun, Nov 06, 2016 at 12:50:12PM +0100, Michael Tuexen wrote:
> >> bus_dmamap_create with the following non-sleepable locks held:
> >> exclusive sleep mutex mpt (mpt) r = 0 (0xfee2f008) locked @ 
> >> dev/mpt/mpt.c:2287
> >> stack backtrace:
> >> #0 0x80ac0300 at witness_debugger+0x70
> >> #1 0x80ac15e7 at witness_warn+0x3d7
> >> #2 0x81055fef at bus_dmamap_create+0x2f
> >> #3 0x80678a25 at mpt_configure_ioc+0x3a5
> >> #4 0x80677476 at mpt_attach+0x226
> >> #5 0x80683299 at mpt_pci_attach+0x9c9
> >> #6 0x80a9478d at device_attach+0x41d
> >> #7 0x80a9595a at bus_generic_attach+0x4a
> >> #8 0x806ebe75 at pci_attach+0xd5
> >> #9 0x80a9478d at device_attach+0x41d
> >> #10 0x80a9595a at bus_generic_attach+0x4a
> >> #11 0x803c11a2 at acpi_pcib_acpi_attach+0x402
> >> #12 0x80a9478d at device_attach+0x41d
> >> #13 0x80a9595a at bus_generic_attach+0x4a
> >> #14 0x803b4c8f at acpi_attach+0xdbf
> >> #15 0x80a9478d at device_attach+0x41d
> >> #16 0x80a9595a at bus_generic_attach+0x4a
> >> #17 0x80ee03e3 at nexus_acpi_attach+0x73
> >> 
> >> ... and so on. Not sure which revision introduced it...
> > r308268
> > 
> > I believe that this is an mpt(4) driver issue, which calls
> > bus_dmamap_create(9) with the mpt mutex held.
> OK. Whom to contact? Or are you willing to look into it?
> I haven't worked in that area...

I am really not sure.  Looking at the svn history is not very encouraging.

Might be try freebsd-scsi@ as well.
___
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 warnings from WITNESS

2016-11-06 Thread Michael Tuexen 
> On 6 Nov 2016, at 13:28, Konstantin Belousov  wrote:
> 
> On Sun, Nov 06, 2016 at 12:50:12PM +0100, Michael Tuexen wrote:
>> bus_dmamap_create with the following non-sleepable locks held:
>> exclusive sleep mutex mpt (mpt) r = 0 (0xfee2f008) locked @ 
>> dev/mpt/mpt.c:2287
>> stack backtrace:
>> #0 0x80ac0300 at witness_debugger+0x70
>> #1 0x80ac15e7 at witness_warn+0x3d7
>> #2 0x81055fef at bus_dmamap_create+0x2f
>> #3 0x80678a25 at mpt_configure_ioc+0x3a5
>> #4 0x80677476 at mpt_attach+0x226
>> #5 0x80683299 at mpt_pci_attach+0x9c9
>> #6 0x80a9478d at device_attach+0x41d
>> #7 0x80a9595a at bus_generic_attach+0x4a
>> #8 0x806ebe75 at pci_attach+0xd5
>> #9 0x80a9478d at device_attach+0x41d
>> #10 0x80a9595a at bus_generic_attach+0x4a
>> #11 0x803c11a2 at acpi_pcib_acpi_attach+0x402
>> #12 0x80a9478d at device_attach+0x41d
>> #13 0x80a9595a at bus_generic_attach+0x4a
>> #14 0x803b4c8f at acpi_attach+0xdbf
>> #15 0x80a9478d at device_attach+0x41d
>> #16 0x80a9595a at bus_generic_attach+0x4a
>> #17 0x80ee03e3 at nexus_acpi_attach+0x73
>> 
>> ... and so on. Not sure which revision introduced it...
> r308268
> 
> I believe that this is an mpt(4) driver issue, which calls
> bus_dmamap_create(9) with the mpt mutex held.
OK. Whom to contact? Or are you willing to look into it?
I haven't worked in that area...

Best regards
Michael

___
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: was: CURRENT [r308087] still crashing: Backtrace provided

2016-11-06 Thread O. Hartmann 
Am Sat, 5 Nov 2016 13:37:48 -0700
Mark Johnston  schrieb:

> On Sat, Nov 05, 2016 at 06:45:09PM +0100, O. Hartmann wrote:
> > Am Sun, 30 Oct 2016 11:25:09 -0700
> > Mark Johnston  schrieb:
> >   
> > > On Sun, Oct 30, 2016 at 06:55:00PM +0100, O. Hartmann wrote:  
> > > > Am Sun, 30 Oct 2016 09:39:34 -0700
> > > > Mark Johnston  schrieb:  
> > > > > Based on the stack trace and affected range of revisions, it may be 
> > > > > that
> > > > > reverting r307887 or r307234 helps, but I have no specific evidence 
> > > > > for
> > > > > this without the requested output.
> > > > 
> > > > I had the crashing also with > r307300 until now, so that leaves me with
> > > > r307233 ... I will go further with that revision and report so far. 
> > > 
> > > Hm, I don't see why this excludes r307887? In any case, r307234 looks to
> > > be the more likely culprit.  
> > 
> > Here I'm again.
> > 
> > This time, it was r308329 or r308331. WITHOUT the debug stuff compiled into 
> > the
> > kernel, it took approximately 5 minutes to provoke the crash. WITH the 
> > debug options
> > set, it took more than 45 minutes to let the system dump the core. I really 
> > hope this
> > time we can fix the problem, this moment, I have put the system back to 
> > r307233 to
> > see whether 3072034 is causing the crash as you suspect.  
> 
> Sorry, I don't quite follow - are you able to provoke the crash at
> r307233? Or are you still testing that revision?

Yesterday, I ran the whole day (> 9 hours) without problems r307233 without the 
reported
crash.

Today's morning I got brave and tried r307234 - and had a crash within an hour.

> 
> > 
> > Attached, you'll find the backtrace report as last time. I had to type in 
> > "dump"
> > blindly on the system as a dark screen or a stuck X11 screen blocked the 
> > console (I
> > use vt() and nVidia BLOB with my nVidia GPUs - and this is still broken on 
> > FBSD).
> > 
> > Please let me know how I can assist further. I saved both the core AND this 
> > time the
> > culprit kernel.  
> 
> Great, thank you. I would first like to confirm that r307234 is indeed
> causing the crash - since it appears to be easy to trigger, that should
> be faster. If not, the core will help track down the real problem.

Although I was under the impression the in-kernel-config option

makeoptionsDEBUG=-g

would make debugging symbols available, I'm proved wrong.

I tried also on 

FreeBSD 12.0-CURRENT #15 r308329: Sat Nov  5 08:52:24 CET 2016
 
and crashed, from which I picked up kernel and vmcore as well as
the text of the backtrace as provided in an earlier mail (see below at 
[core.txt.0], and
if I perform this suggested command sequence:

ohartmann@thor [kernel_debug]: kgdb ./kernel vmcore.0 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols 
found)...
Attempt to extract a component of a value that is not a structure pointer.
Attempt to extract a component of a value that is not a structure pointer.
#0  0x807b8d83 in doadump ()
(kgdb) frame 12
#12 0x80923a74 in ip_output ()
(kgdb) p *ifp
No symbol table is loaded.  Use the "file" command.
(kgdb) p *ro
No symbol table is loaded.  Use the "file" command.
(kgdb)

Again, I'm doing this kind of debugging the very first time and I miss 
something here,
apologizes for that.

Sorry about the redundancy.

The curious thing to me is that this bug is triggered on systems with Intel CPU
architectures older or equal than IvyBridge. The very same /etc/make.conf
and /etc/src.conf as well as the very same kernel config apart from some local 
hardware
dependend modifications are spread around my servers and workstations and 
especially my
bureau's box is a sHaswell XEON with almost the exact same confict running on 
CURRENT
(recent as of Thursday) without problems while the box I'm reporting this error 
from is
crashing (i3-3220, the server, also crashing here, is a E3-1245 V2. Another 
crashing
system is a 2009 C2D XEON 5XXX, two socket server, crashing the same way, but 
with a
different kernel config.
I tried on the crashing systems with GENERIC as well with the same results.

I'm using IPFW as the firewall on all systems.

Please tell me if you revert some commits, I'll then checkout the sources up to 
recent
CURRENT and try again.

This just for addition and completion.


Kind regards and thanks in advance,

Oliver

[...]
[core.txt.0]
...
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x807b44fb
stack pointer   = 0x28:0xfe0238f7c290
frame

Re: New warnings from WITNESS

2016-11-06 Thread Konstantin Belousov 
On Sun, Nov 06, 2016 at 12:50:12PM +0100, Michael Tuexen wrote:
> bus_dmamap_create with the following non-sleepable locks held:
> exclusive sleep mutex mpt (mpt) r = 0 (0xfee2f008) locked @ 
> dev/mpt/mpt.c:2287
> stack backtrace:
> #0 0x80ac0300 at witness_debugger+0x70
> #1 0x80ac15e7 at witness_warn+0x3d7
> #2 0x81055fef at bus_dmamap_create+0x2f
> #3 0x80678a25 at mpt_configure_ioc+0x3a5
> #4 0x80677476 at mpt_attach+0x226
> #5 0x80683299 at mpt_pci_attach+0x9c9
> #6 0x80a9478d at device_attach+0x41d
> #7 0x80a9595a at bus_generic_attach+0x4a
> #8 0x806ebe75 at pci_attach+0xd5
> #9 0x80a9478d at device_attach+0x41d
> #10 0x80a9595a at bus_generic_attach+0x4a
> #11 0x803c11a2 at acpi_pcib_acpi_attach+0x402
> #12 0x80a9478d at device_attach+0x41d
> #13 0x80a9595a at bus_generic_attach+0x4a
> #14 0x803b4c8f at acpi_attach+0xdbf
> #15 0x80a9478d at device_attach+0x41d
> #16 0x80a9595a at bus_generic_attach+0x4a
> #17 0x80ee03e3 at nexus_acpi_attach+0x73
> 
> ... and so on. Not sure which revision introduced it...
r308268

I believe that this is an mpt(4) driver issue, which calls
bus_dmamap_create(9) with the mpt mutex held.
___
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: CURRENT: re(4) crashing system

2016-11-06 Thread Hartmann, O. 
On Mon, 31 Oct 2016 11:12:22 +0900
YongHyeon PYUN  wrote:

> On Fri, Oct 28, 2016 at 09:21:13PM +0200, Hartmann, O. wrote:
> > On Thu, 27 Oct 2016 10:00:04 +0900
> > YongHyeon PYUN  wrote:
> >   
> > > On Tue, Oct 25, 2016 at 07:03:38AM +0200, Hartmann, O. wrote:  
> > > > On Tue, 25 Oct 2016 11:05:38 +0900
> > > > YongHyeon PYUN  wrote:
> > > > 
> > > 
> > > [...]
> > >   
> > > > > I'm not sure but it's likely the issue is related with
> > > > > EEE/Green Ethernet handling. EEE is negotiated feature with
> > > > > link partner. If you directly connect your laptop to non-EEE
> > > > > capable link partner like other re(4) box without switches
> > > > > you may be able to tell whether the issue is EEE/Green
> > > > > Ethernet related one or not.
> > > > 
> > > > Me either since when I discovered a problem the first time with
> > > > CURRENT, that was the Friday before last week's Friday, there
> > > > was a unlucky coicidence: I got the new switch, FreeBSD
> > > > introduced a serious bug and I changed the NICs.
> > > > 
> > > > The laptop, the last in the row of re(4) equipted systems on
> > > > which I use the Realtek NIC, does well now with Green IT
> > > > technology, but crashes on plugging/unplugging - not on each
> > > > event, but at least in one of ten.
> > > 
> > > Hmm, it seems you know how to trigger the issue. When you unplug
> > > UTP cable was there active network traffic on re(4) device?
> > > It would be helpful to know which event triggers the crash(e.g.
> > > unplugging or plugging).  And would you show me backtrace of
> > > panic? 
> > > > I guess the Green IT issue is more a unlucky guess of mine and
> > > > went hand in hand with the problem I face with CURRENT right
> > > > now on some older, Non UEFI machines.
> > > > 
> > > 
> > > Ok.
> > > 
> > > [...]  
> > > > 
> > > > As requested the informations about re0 and rgephy0 on the
> > > > laptop (Lenovo E540) 
> > > > 
> > > > [...]
> > > > 
> > > > rgephy0:  PHY 1 on miibus0
> > > > rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow,
> > > > 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX,
> > > > 1000baseT-FDX-master, 1000baseT-FDX-flow,
> > > > 1000baseT-FDX-flow-master, auto, auto-flow
> > > > 
> > > > re0: 
> > > > port 0x3000-0x30ff mem
> > > > 0xf0d04000-0xf0d04fff,0xf0d0-0xf0d03fff at device 0.0 on
> > > > pci2 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip
> > > > rev. 0x5080 re0: MAC rev. 0x0010
> > > 
> > > This looks like 8168GU controller.
> > > 
> > > [...]
> > >   
> > > > I use options netmap in kernel config, but the problem is also
> > > > present without this option - just for the record.
> > > > 
> > > 
> > > Yup, netmap(4) has nothing to do with the crash.
> > > 
> > > Thanks.  
> > 
> > Attached, you'll find the backtrace of the crash. This time it was
> > really easy - just one pull of the LAN cabling - and we are
> > happy :-/
> > 
> > Please let me know if you need something else. I will return to
> > normal operations (disabling debugging) due to CURRENT is very
> > unstable at the moment on other hosts beyond r307157.
> >   
> 
> It seems the attachment was stripped.

This time I hope I got it right!

Attached you'll find the latest CURRENT's backtrace on the provoked
crash (plug and unplug).

I also saved the kernel and coredump, so if you need me to do further
investigations,please let me know.

Thanks in advance and kind regards,

oliver

core.txt.0
Description: Binary data
___
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"

New warnings from WITNESS

2016-11-06 Thread Michael Tuexen 
Dear all,

when booting a recent kernel

[freebsd12:~] tuexen% uname -a
FreeBSD freebsd12.testbed 12.0-CURRENT FreeBSD 12.0-CURRENT #702 r308359M: Sun 
Nov  6 11:55:17 CET 2016 
tuexen@freebsd12.testbed:/usr/home/tuexen/head/sys/amd64/compile/SCTP  amd64

on a VMWare Fusion VM, I get a lot of warnings like

bus_dmamap_create with the following non-sleepable locks held:
exclusive sleep mutex mpt (mpt) r = 0 (0xfee2f008) locked @ 
dev/mpt/mpt.c:2287
stack backtrace:
#0 0x80ac0300 at witness_debugger+0x70
#1 0x80ac15e7 at witness_warn+0x3d7
#2 0x81055fef at bus_dmamap_create+0x2f
#3 0x80678a25 at mpt_configure_ioc+0x3a5
#4 0x80677476 at mpt_attach+0x226
#5 0x80683299 at mpt_pci_attach+0x9c9
#6 0x80a9478d at device_attach+0x41d
#7 0x80a9595a at bus_generic_attach+0x4a
#8 0x806ebe75 at pci_attach+0xd5
#9 0x80a9478d at device_attach+0x41d
#10 0x80a9595a at bus_generic_attach+0x4a
#11 0x803c11a2 at acpi_pcib_acpi_attach+0x402
#12 0x80a9478d at device_attach+0x41d
#13 0x80a9595a at bus_generic_attach+0x4a
#14 0x803b4c8f at acpi_attach+0xdbf
#15 0x80a9478d at device_attach+0x41d
#16 0x80a9595a at bus_generic_attach+0x4a
#17 0x80ee03e3 at nexus_acpi_attach+0x73
bus_dmamap_create with the following non-sleepable locks held:
exclusive sleep mutex mpt (mpt) r = 0 (0xfee2f008) locked @ 
dev/mpt/mpt.c:2287
stack backtrace:
#0 0x80ac0300 at witness_debugger+0x70
#1 0x80ac15e7 at witness_warn+0x3d7
#2 0x81055fef at bus_dmamap_create+0x2f
#3 0x80678a25 at mpt_configure_ioc+0x3a5
#4 0x80677476 at mpt_attach+0x226
#5 0x80683299 at mpt_pci_attach+0x9c9
#6 0x80a9478d at device_attach+0x41d
#7 0x80a9595a at bus_generic_attach+0x4a
#8 0x806ebe75 at pci_attach+0xd5
#9 0x80a9478d at device_attach+0x41d
#10 0x80a9595a at bus_generic_attach+0x4a
#11 0x803c11a2 at acpi_pcib_acpi_attach+0x402
#12 0x80a9478d at device_attach+0x41d
#13 0x80a9595a at bus_generic_attach+0x4a
#14 0x803b4c8f at acpi_attach+0xdbf
#15 0x80a9478d at device_attach+0x41d
#16 0x80a9595a at bus_generic_attach+0x4a
#17 0x80ee03e3 at nexus_acpi_attach+0x73
bus_dmamap_create with the following non-sleepable locks held:
exclusive sleep mutex mpt (mpt) r = 0 (0xfee2f008) locked @ 
dev/mpt/mpt.c:2287
stack backtrace:
#0 0x80ac0300 at witness_debugger+0x70
#1 0x80ac15e7 at witness_warn+0x3d7
#2 0x81055fef at bus_dmamap_create+0x2f
#3 0x80678a25 at mpt_configure_ioc+0x3a5
#4 0x80677476 at mpt_attach+0x226
#5 0x80683299 at mpt_pci_attach+0x9c9
#6 0x80a9478d at device_attach+0x41d
#7 0x80a9595a at bus_generic_attach+0x4a
#8 0x806ebe75 at pci_attach+0xd5
#9 0x80a9478d at device_attach+0x41d
#10 0x80a9595a at bus_generic_attach+0x4a
#11 0x803c11a2 at acpi_pcib_acpi_attach+0x402
#12 0x80a9478d at device_attach+0x41d
#13 0x80a9595a at bus_generic_attach+0x4a
#14 0x803b4c8f at acpi_attach+0xdbf
#15 0x80a9478d at device_attach+0x41d
#16 0x80a9595a at bus_generic_attach+0x4a
#17 0x80ee03e3 at nexus_acpi_attach+0x73
bus_dmamap_create with the following non-sleepable locks held:
exclusive sleep mutex mpt (mpt) r = 0 (0xfee2f008) locked @ 
dev/mpt/mpt.c:2287
stack backtrace:
#0 0x80ac0300 at witness_debugger+0x70
#1 0x80ac15e7 at witness_warn+0x3d7
#2 0x81055fef at bus_dmamap_create+0x2f
#3 0x80678a25 at mpt_configure_ioc+0x3a5
#4 0x80677476 at mpt_attach+0x226
#5 0x80683299 at mpt_pci_attach+0x9c9
#6 0x80a9478d at device_attach+0x41d
#7 0x80a9595a at bus_generic_attach+0x4a
#8 0x806ebe75 at pci_attach+0xd5
#9 0x80a9478d at device_attach+0x41d
#10 0x80a9595a at bus_generic_attach+0x4a
#11 0x803c11a2 at acpi_pcib_acpi_attach+0x402
#12 0x80a9478d at device_attach+0x41d
#13 0x80a9595a at bus_generic_attach+0x4a
#14 0x803b4c8f at acpi_attach+0xdbf
#15 0x80a9478d at device_attach+0x41d
#16 0x80a9595a at bus_generic_attach+0x4a
#17 0x80ee03e3 at nexus_acpi_attach+0x73

... and so on. Not sure which revision introduced it...

Best regards
Michael
___
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: [RFC] remove GNU rcs from FreeBSD 12

2016-11-06 Thread Eivind Nicolay Evensen 
On Sat, Nov 05, 2016 at 02:07:21PM +0100, Ronald Klop wrote:
> On Thu, 03 Nov 2016 03:17:23 +0100, Julian Elischer   
> wrote:
> 
> >On 26/10/2016 2:27 AM, Eivind Nicolay Evensen wrote:
> >>On Sun, Sep 11, 2016 at 03:38:04PM +0200, Baptiste Daroussin wrote:
> >>>hi,
> >>>
> >>>For long we are planning to remove GNU rcs from base, after a failed  
> >>>attempt
> >>>before FreeBSD 10.0. Let see where we are to be able to remove it from  
> >>>FreeBSD
> >>>12.
> >
> >why should we remove it?
> >What will replace it?  it's an integral part of many people's systems.
> 
> Firefox/perl/java is also an integral part of many people's system. But it  
> is not in base.


I see a big difference between these two

First providing something people find useful enough that it affects their
decision about whether or not to use a system, then stopping providing it.

versus

Not including any and all available software packages.


I don't think I'm entirely along in that view.

I also thought that perl was a good example of another piece of software
that once was provided and no longer is.




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