Re: help me understand latest->quarterly pkg.conf switch
On 07/25/2015 05:04 AM, Glen Barber wrote:
On Fri, Jul 24, 2015 at 09:23:12PM -0400, Nikolai Lifanov wrote:
On 2015-07-24 17:27, Glen Barber wrote:
On Fri, Jul 24, 2015 at 05:15:52PM -0400, Nikolai Lifanov wrote:
I noticed that in stable/10, /etc/pkg/FreeBSD.conf was switched from
using
latest package set to whichever one that is "quarterly" word is pointing
to
at the moment. What is the motivation for this change?
This was not done in the stable/10 branch, it was done in releng/10.2.
Quarterly package sets are useful if the end-user is able to pick which
one
to pull from and there is some amount of time of support overlap so that
the
user has time to validate the new package set and switch his systems to
it
(like what is done with pkgsrc). As-is, "quarterly" works just like
"latest"
>from end-user perspective, but for most of the lifecycle packages are
outdated and there is a massive update bomb four times per year.
Port branches are still valuable to those building their own packages,
since
they can support the previous (unsupported by the project) branch,
backporting fixes manually, while validating and upgrading to the new
one.
But, what is the value of the quarterly package set as-is and what is
the
value of switching to this set by default?
In general, the quarterly package set is less prone to having build
failures, since the changes in the branch are (by intent) less
intrusive, while still receiving security updates. It is analogous to
the stable or releng branches in src, and how they compare to head.
(This will be noted in the final 10.2-RELEASE announcement, as well as
the release notes, and will also include instructions on how to switch
to the 'latest' branch if that is what is desired.)
Glen
Cool, thanks for the explanation!
You're welcome. (The 'quarterly' branch is admittedly under-documented,
which is a problem.)
What would be really amazing to see are quarterly branches that the end user
can switch between, like pkg.freebsd.org/${ABI}/2015Q3 ->
pkg.freebsd.org/${ABI}/2015Q4 when he is ready, with at least a little bit
of overlap.
I agree this would be a "nice to see" feature, but as I have insight
into how the pkg(8) mirrors operate, this is an unfortunately
non-trivial thing to implement.
Glen
Does this mean that quarterly pkg are synchronous with ports quarterly
branches? Say, at the moment, packages that we install with the default
("quarterly") setting in /etc/pkg/FreeBSD.conf, are built from the
2015Q3 branch?
-Alnis
___
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: msk msk0 watchdog timeout freeze hang lock stop problem
On 08/12/2015 04:44 PM, Roosevelt Littleton wrote: Hi, So, I can confirm with the attached patch. I have a working msk0 that hasn't failed for the past month. I considered this problem fix for me. Since, I have went a long time without any problems. Thanks! Roosevelt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" Since 10.2-RC1 it works for me, too; now on 10.2-RELEASE. And I don't use any patches, still. -Alnis ___ 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: msk msk0 watchdog timeout freeze hang lock stop problem
On 07/26/2015 01:40 PM, Yonghyeon PYUN wrote: On Sat, Jul 25, 2015 at 02:08:10PM +0300, Alnis Morics wrote: Just tried 10.2-RC1 amd64 GENERIC, and the problem seems to be gone. I was even able to scp a 500 MB file. Could it be related to this fix in BETA2, as mentioned in the announcement, "The watchdog(4) device has been fixed to print to the correct buffer."? msk(4) will show watchdog timeouts when it detects driver TX path is in stuck condition but I believe this has nothing to do with watchdog(4). There was no msk(4) code change in 10.2-RC1. If you happen to see the watchdog timeouts again, please try attached patch and let me know whether it makes any difference for you. I didn't get much feedbacks on the patch so I'm not sure whether it really fixes the root cause. pciconf -lv [..] mskc0@pci0:9:0:0:class=0x02 card=0xc072144d chip=0x435411ab rev=0x00 hdr=0x00 vendor = 'Marvell Technology Group Ltd.' device = '88E8040 PCI-E Fast Ethernet Controller' class = network subclass = ethernet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" Thanks, Pyun. If the watchdog timeouts reappear, I'll try the patch and give notice about the results. -Alnis ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: msk msk0 watchdog timeout freeze hang lock stop problem
On 04/16/2015 12:52 AM, Gareth Wyn Roberts wrote: I've inserted code to print some values which show the differences between specifying 4096 or 8192 for MSK_STAT_ALIGN. In both cases the status buffer has length 0x4000 (8x2048=16K) but the alignments are different as expected, respectively start addresses 0x5c3b000 or 0xbdc2c000. The following values were output from functions msk_status_dma_alloc(), msk_dmamap_cb() and msk_handle_events(). The "Break #n" refer to breaks in msk_handle_events(). "#1" occurs if ((control & HW_OWNER) == 0), "#5" is OP_RXSTAT and "#6" is OP_TXINDEXLE. The first output is for MSK_STAT_ALIGN=8192. It continues normally. Although not shown here, it reaches cons=2047 then cons=0 as expected. The second output is for MSK_STAT_ALIGN=4096. Although there can be isolated occurences of "Break #1" (e.g. cons=196) (?are these to be expected?), it continues normally until cons=512. At this point it continually invokes the "#1" block because the msk_control from msk_stat_ring[512] is always zero and the network hangs immediately. This suggests the Yukon Ultra 2 88E8057 can't access the next 4096 memory block, but why not? Please let me know if any further information would be helpful. Start of MSK_STAT_ALIGN=8192 output - mskc0: mem 0xfa00-0xfa003fff irq 19 at device 0.0 on pci6 mskc0: Successful creation of DMA tag mskc0: sc->msk_stat_count=2048 mskc0: stat_sz=16384 mskc0: sc->msk_stat_tag=0xf800050b99a0 mskc0: Successful allocation of DMA'able memory for status ring mskc0: sc->msk_stat_map=0xf800050b99a8 msk_dmamap_cb (stat): nseg=1 msk_dmamap_cb (stat): error=0 msk_dmamap_cb (stat): segs[0].ds_addr=3183656960=0xbdc2c000 msk_dmamap_cb (stat): segs[0].ds_len=16384=0x4000 mskc0: Successful load of DMA'able memory for status ring mskc0: sc->msk_stat_ring_paddr=3183656960=0xbdc2c000 msk0: on mskc0 msk0: Ethernet address: 00:13:77:e9:df:eb miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow ... mskc0: msk_handle_events: Break #6 cons=0 csrread=1 mskc0: msk_handle_events: Break #5 cons=1 csrread=2 mskc0: msk_handle_events: Break #6 cons=2 csrread=3 mskc0: msk_handle_events: Break #5 cons=3 csrread=5 mskc0: msk_handle_events: Break #6 cons=4 csrread=6 mskc0: msk_handle_events: Break #6 cons=5 csrread=6 mskc0: msk_handle_events: Break #6 cons=6 csrread=7 mskc0: msk_handle_events: Break #5 cons=7 csrread=8 mskc0: msk_handle_events: Break #5 cons=8 csrread=10 mskc0: msk_handle_events: Break #6 cons=9 csrread=10 ... mskc0: msk_handle_events: Break #5 cons=510 csrread=511 mskc0: msk_handle_events: Break #6 cons=511 csrread=512 mskc0: msk_handle_events: Break #5 cons=512 csrread=513 mskc0: msk_handle_events: Break #5 cons=513 csrread=514 mskc0: msk_handle_events: Break #6 cons=514 csrread=515 mskc0: msk_handle_events: Break #5 cons=515 csrread=516 ...etc. Start of MSK_STAT_ALIGN=4096 output - mskc0: mem 0xfa00-0xfa003fff irq 19 at device 0.0 on pci6 mskc0: Successful creation of DMA tag mskc0: sc->msk_stat_count=2048 mskc0: stat_sz=16384 mskc0: sc->msk_stat_tag=0xf800050b99a0 mskc0: Successful allocation of DMA'able memory for status ring mskc0: sc->msk_stat_map=0xf800050b99a8 msk_dmamap_cb (stat): nseg=1 msk_dmamap_cb (stat): error=0 msk_dmamap_cb (stat): segs[0].ds_addr=96710656=0x5c3b000 msk_dmamap_cb (stat): segs[0].ds_len=16384=0x4000 mskc0: Successful load of DMA'able memory for status ring mskc0: sc->msk_stat_ring_paddr=96710656=0x5c3b000 msk0: on mskc0 msk0: Ethernet address: 00:13:77:e9:df:eb miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow ... mskc0: msk_handle_events: Break #5 cons=0 csrread=2 mskc0: msk_handle_events: Break #5 cons=1 csrread=2 mskc0: msk_handle_events: Break #5 cons=2 csrread=3 mskc0: msk_handle_events: Break #5 cons=3 csrread=4 mskc0: msk_handle_events: Break #5 cons=4 csrread=5 mskc0: msk_handle_events: Break #5 cons=5 csrread=7 mskc0: msk_handle_events: Break #5 cons=6 csrread=7 mskc0: msk_handle_events: Break #5 cons=7 csrread=9 mskc0: msk_handle_events: Break #5 cons=8 csrread=9 mskc0: msk_handle_events: Break #5 cons=9 csrread=10 mskc0: msk_handle_events: Break #5 cons=10 csrread=11 ... mskc0: msk_handle_events: Break #6 cons=194 csrread=197 mskc0: msk_handle_events: Break #5 cons=195 csrread=197 mskc0: msk_handle_events: Break #1 cons=196 csrread=197 mskc0: msk_handle_events: sd=0xfe011e23b620 sd->msk_control=1610612806 control=1610612806 mskc0: msk_handle_events: Break #5 cons=196 csrread=197 mskc0: msk_handle_events: Break #5 cons=197 csrread=198 ... mskc0: msk_handle_event
Re: 10.1-STABLE bce: Watchdog timeout occurred
On 04/21/2015 06:17 AM, Chris Ross wrote: I got a new [to me] system recently, a Dell PE 1950. It has two bce parts on the motherboard that identify as: bce#: The OS I installed and kernel I'm running are from a download of a 10.1 STABLE ISO, r281235, April 7, 2015. I had gone on to check out a newer stable from subversion, and build a custom kernel, but when I booted that one I got a bce0 that didn't seem to work, and kept emitting: bce0: /usr/src/sys/dev/bce/if_bce.c(7869): Watchdog timeout occurred, resetting! bce0: link state changed to DOWN bce0: link state changed to UP So, I fell back. But I've since noticed that even the original kernel seems to do this after booting. I'm not yet running any notable amount of traffic through the system, but intend to make it an edge router, so certainly will be. Is there any sort of issue noted in the bce driver in recent days/weeks/months? Are other folks seeing this diagnostic/error? I'll do a little more testing and see if I'm seeing it more or less often, but I know that in at least some cases the interface has flapped like this after boot for long enough that I was unable to get connected remotely, and resorted to a console login to reboot. - Chris There are "Watchdog timeout" errors with some msk NICs. Both msk and bce are dependent on MII bus code (see /usr/src/sys/amd64/conf/GENERIC) -Alnis ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pkg 1.5.0 is out
On 04/14/2015 11:34 PM, Fernando Apesteguía wrote: El 14/04/2015 22:19, "Mikhail Tsatsenko" escribió: 2015-04-14 23:05 GMT+03:00 Baptiste Daroussin : Hi all, Hi, thanks for your great work! +1 +1 Final pkg 1.5.0 has been released. What happened since pkg 1.4.0: - Initial provides/requires support - Lots of new regression tests have been added - Initial support for OS X - Initial support for NetBSD/EdgeBSD - Update most of the bundled third party software has been updated to their latest version - Improve the messages reported by pkg - Properly support file flags - Implement argument support for custom keywords - Extend setting credential via plist to allow to set file flags - Make credential syntax via plist more flexible allow to only defines the first - pkg updating now supports case insensitive matching - pkg create now support a verbose mode - Add an option to change the default on question, until now the default answer was "No" with that option set it would be "Yes" - Lots of fixes to pkg audit -r - Global memory usage reduction and speed up - Improvements and cleanup on pkg alias - pkg annotate --show --all has been fixed - Make pkg.h C++ friendly - Lots of improvements in the solver - Lots of fixes on 32 bits platforms - Add support for: pkg create -M ./plop.ucl -p ./plop.plist - New pkg -r that will install in the given rootdir without chrooting - Export PKG_ROOTDIR to scripts allow to make them as portable as possible - Stop trying to remove all installed package with the argument of pkg delete is a local file - Be more explicit about why the solver it going to reinstall, remove or upgrade (when possible) - Plenty of bug fixes - Plenty of new bugs - pkg shlibs now support -q - pkg lock gained a new --has-locked-packages option - pkg now resumes fetch if possible - CONSERVATIVE_UPGRADE is now on by default - pkg alias now have a -l argument to list aliases - A sample pkg.conf is now installed with a bunch of aliases set by default - Fix the backup script to properly export an sql which will be importable via pkg shell and/or sqlite out of box I would like to thank anyone that has been contributing to pkg to make this release happen (via code, bug report, feature request, testing and documentation) For pkg 1.6.0 among other things and depending on the time, here is what we do plan to work on: - Safe cherry-picking of upgrades (aka: pkg upgrade something) - New context dependant messages: * messages that only appears during upgrades * messages that only appears on deinstall * messages that only appears on install - Extend provides/requires to support flexible dependencies - Linux package backend (?) - Allow multiple versions of a given package in a repo - Add more regression tests - Improve documentation - - portmaster support (-P)? Best regards, Bapt -- Mikhail ___ freebsd-po...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
msk msk0 watchdog timeout freeze hang lock stop problem
Hm... I patched if_msk.c with if_msk.c.rev262524.dma.diff (attachment-001.bin) and if_mskreg.h with if_mskreg.h.rev264442.dma.diff (attachment-002.bin), and nothing changed: scp'ing 50 MB soon got "stalled" and ended up with "broken pipe", as it was before. I have 10.1-RELEASE-p9 amd64 pciconf -lv: [..] mskc0@pci0:9:0:0:class=0x02 card=0xc072144d chip=0x435411ab rev=0x00 hdr=0x00 vendor = 'Marvell Technology Group Ltd.' device = '88E8040 PCI-E Fast Ethernet Controller' class = network subclass = ethernet Alnis ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
