Re: [RFC] Removin the old make
On Thu, Feb 12, 2015 at 05:47:27PM -0700, Ian Lepore wrote: On Fri, 2015-02-13 at 01:24 +0100, Baptiste Daroussin wrote: On Fri, Feb 13, 2015 at 12:49:13AM +0100, Julian H. Stacey wrote: Hi, I would like to start using bmake only syntax on our infrastructure for tha= t I want to make sure noone is using the old make, so I plan to remove the old = .^^ make =66rom base, I plan to do it by Feb 16th. Note that bmake is the default since FreeBSD 10. FreeBSD 9.3 is also providing bmake (as bmake) on default installation. Best regards, Bapt I don't know the difference, but it seems potentialy dangerous to remove old make without notice ? Old make was already removed in 10.x what remains is only the sources and that is what I propose to remove from 11 (and only from 11) Best regards, Bapt fmake exists as a port too, doesn't it? That's what I vaguely remember as the plan... bmake available in 9, it's the default in 10 but fmake source is still around, and then in 11 fmake is gone from base but available as a port. Yes it is in port for sure. Bapt pgp71bjqKARME.pgp Description: PGP signature
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #689
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/689/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #690
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/690/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
pcie Realtek 8168G issues (re driver)
Hi, I'm Luca, I've some issues using a PCIe Realtek Ethernet board: re0@pci0:3:0:0: class=0x02 card=0x012310ec chip=0x816810ec rev=0x0c hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x1000, size 256, enabled bar [18] = type Memory, range 64, base 0x9050, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0x9040, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0100684ce000 ecap 0018[170] = LTR 1 Rx and Tx don't work. After some minutes the interface is activated I get kernel panic. I've already tried to disable MSIx and MSI. It seems a DMA problem, rx fill the 256 descriptors and the nothing else until the panic. netstat -s shows now new packets. I filled a bug report with more infos: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 could someone kindly pointing some ideas? Best regards, Luca ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #691
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/691/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pcie Realtek 8168G issues (re driver)
Luca, I've had the same issue with this interface on both PCIe boards and embedded in a handful of Lenovo products. The one, fairly ugly workaround I've found that makes it work well enough is disable tso ( i.e. ifconfig re0 down ifconfig re0 -tso ifconfig re0 up ). This also seems to stop the panics under current. I'm not sure it will work for you - but it has on everyone of those interfaces I've dealt with. Good luck, -bp On Feb 13, 2015, at 8:06 AM, Luca Pizzamiglio luca.pizzamig...@gmail.com wrote: Hi, I'm Luca, I've some issues using a PCIe Realtek Ethernet board: re0@pci0:3:0:0: class=0x02 card=0x012310ec chip=0x816810ec rev=0x0c hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x1000, size 256, enabled bar [18] = type Memory, range 64, base 0x9050, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0x9040, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0100684ce000 ecap 0018[170] = LTR 1 Rx and Tx don't work. After some minutes the interface is activated I get kernel panic. I've already tried to disable MSIx and MSI. It seems a DMA problem, rx fill the 256 descriptors and the nothing else until the panic. netstat -s shows now new packets. I filled a bug report with more infos: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 could someone kindly pointing some ideas? Best regards, Luca ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
make regression -- -q doesn't work?
On 10.1-RELEASE, make -q doesn't seem to work anymore: [rstone@wtllab-bsd10-build-64 rstone]cat Makefile foo: bar cp bar foo bar: touch bar clean: rm -f foo bar [rstone@wtllab-bsd10-build-64 rstone]make -q foo; echo $? 1 [rstone@wtllab-bsd10-build-64 rstone]make foo touch bar cp bar foo [rstone@wtllab-bsd10-build-64 rstone]make -q foo; echo $? `foo' is up to date. 1 [rstone@wtllab-bsd10-build-64 rstone]make foo `foo' is up to date. [rstone@wtllab-bsd10-build-64 rstone]echo $? 0 This worked correctly in 8.1-RELEASE. I suspect that this is a bmake-induced regression? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make installworld broken on current amd64 at /usr/src/usr.bin/chpass
On Thu, Feb 12, 2015 at 10:17:28PM -0500, Shawn Webb wrote: On Thursday, February 12, 2015 06:38:29 PM Manfred Antar wrote: make install in usr.bin/chpass broken on current: (chpass)5006}make install install -s -o root -g wheel -m 4555 -fschg -S chpass /usr/bin/chpass install -o root -g wheel -m 444 chpass.1.gz /usr/share/man/man1 /usr/share/man/man1/chfn.1.gz - /usr/share/man/man1/chpass.1.gz /usr/share/man/man1/chsh.1.gz - /usr/share/man/man1/chpass.1.gz /usr/share/man/man1/ypchpass.1.gz - /usr/share/man/man1/chpass.1.gz /usr/share/man/man1/ypchfn.1.gz - /usr/share/man/man1/chpass.1.gz /usr/share/man/man1/ypchsh.1.gz - /usr/share/man/man1/chpass.1.gz /usr/bin/chfn - /usr/bin/chpass install: link /usr/bin/chpass - /usr/bin/chfn: Operation not permitted *** Error code 71 Stop. make: stopped in /usr/src/usr.bin/chpass I'm getting this, too. Thanks, Shawn It has been fixed sorry about that. Bapt pgpWD21howQ5K.pgp Description: PGP signature
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #692
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/692/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #693
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/693/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
process checkpoint and migration support?
Do we have any support for process checkpoint and migration on FreeBSD? I have found some code from 2010 at code.google.com/p/processmigration which works by forcing a core dump. I wonder how difficult it would be to extend it to do incremental checkpointing (to reduxe the time in which the process must be stopped during a migration). Cheers Luigi -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
sa(4) driver changes available for test
I have a fairly large set of changes to the sa(4) driver and mt(1) driver that I'm planning to commit in the near future. A description of the changes is here and below in this message. If you have tape hardware and the inclination, I'd appreciate testing and feedback. Rough draft commit message: http://people.freebsd.org/~ken/sa_changes_commitmsg.20150213.3.txt The patches against FreeBSD/head as of SVN revision 278706: http://people.freebsd.org/~ken/sa_changes.20150213.3.txt And (untested) patches against FreeBSD stable/10 as of SVN revision 278721. http://people.freebsd.org/~ken/sa_changes.stable_10.20150213.3.txt The intent is to get the tape infrastructure more up to date, so we can support LTFS and more modern tape drives: http://www.ibm.com/systems/storage/tape/ltfs/ I have ported IBM's LTFS Single Drive Edition to FreeBSD. The port depends on the patches linked above. It isn't fully cleaned up and ready for redistribution. If you're interested, though, let me know and I'll tell you when it is ready to go out. You need an IBM LTO-5, LTO-6, TS1140 or TS1150 tape drive. HP drives aren't supported by IBM's LTFS, and older drives don't have the necessary features to support LTFS. The commit message below outlines most of the changes. A few comments: 1. I'm planning to commit the XPT_DEV_ADVINFO changes separately. 2. The XML output is similar to what GEOM and CTL do. It would be nice to figure out how to put a standard schema on it so that standard tools could read it. I don't know how feasible that is, since I haven't time to dig into it. If anyone has suggestions on whether that is feasible or advisable, I'd appreciate feedback. 3. I have tested with a reasonable amount of tape hardware (see below for a list), but more testing and feedback would be good. 4. Standard 'mt status' output looks like this: # mt -f /dev/nsa3 status -v Drive: sa3: IBM ULTRIUM-HH6 E4J1 Serial Number: 101500520A - Mode Density Blocksize bpi Compression Current: 0x5a:LTO-6 variable 384607 enabled (0xff) - Current Driver State: at rest. - Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual:0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP 5. 'mt status -v' looks like this: # mt -f /dev/nsa3 status -v Drive: sa3: IBM ULTRIUM-HH6 E4J1 Serial Number: 101500520A - Mode Density Blocksize bpi Compression Current: 0x5a:LTO-6 variable 384607 enabled (0xff) - Current Driver State: at rest. - Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual:0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP - Tape I/O parameters: Maximum I/O size allowed by driver and controller (maxio): 1081344 bytes Maximum I/O size reported by controller (cpi_maxio): 5197824 bytes Maximum block size supported by tape drive and media (max_blk): 8388608 bytes Minimum block size supported by tape drive and media (min_blk): 1 bytes Block granularity supported by tape drive and media (blk_gran): 0 bytes Maximum possible I/O size (max_effective_iosize): 1081344 bytes 6. Existing applications should work without changes. If not, please let me know. Hopefully they will move over time to the new interfaces. 7. There are lots of additional features that could be added later. Append-only support, encryption, more log pages, etc. 8. I have SCSI READ ATTRIBUTE changes for camcontrol(8) that will go in separately. These changes allow displaying the contents of the MAM (Medium Auxiliary Memory) chips on LTO, TS and other modern tape drives. These are good, and a future possible direction is adding attributes to the status XML from the sa(4) driver. Significant upgrades to sa(4) and mt(1). The primary focus of these changes is to modernize FreeBSD's tape infrastructure so that we can take advantage of some of the features of modern tape drives and allow support for LTFS. Significant changes and new features include: o sa(4) driver status and parameter information is now exported via an XML structure. This will allow for changes and improvements later on that will not break userland applications. The old MTIOCGET status ioctl remains, so applications using the existing interface will not break. o 'mt status' now reports drive-reported tape position information as well as the previously available calculated tape position information. These numbers will be different at times, because the drive-reported block numbers are relative to BOP (Beginning of Partition), but the block numbers calculated previously via sa(4) (and still
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #694
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/694/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
boot panic r278740: Most recently used by acpica
Hi, Just built 11-CURRENT in order to debug a radeon initialization problem. Clean svn source download of r278740. Followed make buildworld/make buildkernel etc procedure. System panics during boot of kernel with several LOR indications. Haven't run -CURRENT on this system for a while so can't say from which commit point this problem started, however: - System boots fine (but with radeon init problem) on 10-STABLE. - System boots fine and radeon inits OK on 10-STABLE r269271. Detailed panic info here: http://opal.com/jr/freebsd/panic/r278740/dmesg.txt http://opal.com/jr/freebsd/panic/r278740/info.2 http://opal.com/jr/freebsd/panic/r278740/core.txt.2 -jr pgpCW53kupojC.pgp Description: OpenPGP digital signature
