svn0.eu.freebsd.org timed out - temporary problems?
Something wrong with the svn0.eu.freebsd.org mirror: svn: E60: Unable to connect to a repository at URL 'https://svn0.eu.freebsd.org/base/head' svn: E60: Error running context: Operation timed out I hope it's temprorary problem, but please advise if the mirror address has changed. Thanks Anton ___ 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
[head tinderbox] failure on amd64/amd64
TB --- 2014-02-06 10:10:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-06 10:10:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-06 10:10:18 - starting HEAD tinderbox run for amd64/amd64 TB --- 2014-02-06 10:10:18 - cleaning the object tree TB --- 2014-02-06 10:10:18 - /usr/local/bin/svn stat /src TB --- 2014-02-06 10:10:23 - At svn revision 261542 TB --- 2014-02-06 10:10:24 - building world TB --- 2014-02-06 10:10:24 - CROSS_BUILD_TESTING=YES TB --- 2014-02-06 10:10:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-06 10:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-06 10:10:24 - SRCCONF=/dev/null TB --- 2014-02-06 10:10:24 - TARGET=amd64 TB --- 2014-02-06 10:10:24 - TARGET_ARCH=amd64 TB --- 2014-02-06 10:10:24 - TZ=UTC TB --- 2014-02-06 10:10:24 - __MAKE_CONF=/dev/null TB --- 2014-02-06 10:10:24 - cd /src TB --- 2014-02-06 10:10:24 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Feb 6 10:10:30 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools [...] c++ -O2 -pipe -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter -I. -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\x86_64-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/obj/amd64.amd64/src/tmp\ -I/obj/amd64.amd64/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfCFIException.cpp -o DwarfCFIException.o c++ -O2 -pipe -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter -I. -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\x86_64-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/obj/amd64.amd64/src/tmp\ -I/obj/amd64.amd64/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp -o DwarfCompileUnit.o c++ -O2 -pipe -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter -I. -I/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\x86_64-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/obj/amd64.amd64/src/tmp\ -I/obj/amd64.amd64/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp -o DwarfDebug.o /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp: In destructor 'llvm::DwarfDebug::~DwarfDebug()': /src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:212: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libllvmasmprinter *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-06 10:51:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-06 10:51:44 - ERROR: failed to build world TB --- 2014-02-06 10:51:44 - 2213.46 user 210.65 system 2485.23 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full ___ 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: svn0.eu.freebsd.org timed out - temporary problems?
On Thu, Feb 06, 2014 at 01:07:50AM -0800, Anton Shterenlikht wrote: Something wrong with the svn0.eu.freebsd.org mirror: svn: E60: Unable to connect to a repository at URL 'https://svn0.eu.freebsd.org/base/head' svn: E60: Error running context: Operation timed out This should be fixed now. I hope it's temprorary problem, but please advise if the mirror address has changed. Glen pgpoxPMiY46z7.pgp Description: PGP signature
Re: svn0.eu.freebsd.org timed out - temporary problems?
From g...@freebsd.org Thu Feb 6 15:34:12 2014 On Thu, Feb 06, 2014 at 01:07:50AM -0800, Anton Shterenlikht wrote: Something wrong with the svn0.eu.freebsd.org mirror: =20 svn: E60: Unable to connect to a repository at URL 'https://svn0.eu.f= reebsd.org/base/head' svn: E60: Error running context: Operation timed out =20 This should be fixed now. it is Thanks Anton ___ 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: regression: msk0 watchdog timeout and interrupt storm
06.02.2014 06:00, Yonghyeon PYUN пишет: On Sat, Feb 01, 2014 at 12:18:59PM +0400, Boris Samorodov wrote: Hi Yonghyeon and All, (this time it's a CURRENT issue) 31.10.2013 17:33, Boris Samorodov пишет: 30.10.2013 06:16, Yonghyeon PYUN пишет: On Tue, Oct 29, 2013 at 05:38:27PM +0400, Boris Samorodov wrote: From time to time I use a notebook and boot FreeBSD from USB stick. FreeBSD 9.2-i386 works OK. So I tried to use FreeBSD 10.0-i386 BETA2 and the network adapter works for some 10-15 seconds and then stops with diagnostic message msk0:watchdog timeout. I've found similar case at freebsd-current@ with no workaround. Yes, there is an interrupt storm as well. There had been no functional changes for very long time so I'm not sure what's going on here. I've attached local change I have at this moment but I'm afraid it wouldn't address the issue above. I recall jhb also reported interrupt storm in the past but the root cause was not identified yet. Could you change msk_intr() and let me know which interrupt is firing? I've yet to organize a build. Here is some additional info: - mskc0@pci0:3:0:0: class=0x02 card=0xff501179 chip=0x435511ab rev=0x12 hdr=0x00 vendor = 'Marvell Technology Group Ltd.' device = '88E8040T PCI-E Fast Ethernet Controller' class = network subclass = ethernet cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[5c] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[c0] = PCI-Express 2 legacy endpoint max data 128(128) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[130] = Serial 1 b8b063681e00 - Meanwhile some more investigations, vmstat -i for calm and storm: - interrupt total rate irq1: atkbd01025 2 irq9: acpi0 204 0 irq14: ata0 327 0 irq16: uhci0+246 0 irq20: hpet0 22472 52 irq23: uhci2 ehci1 10341 24 irq256: hdac0 52 0 irq257: mskc0258 0 irq258: ahci0221 0 Total 35146 81 - interrupt total rate irq1: atkbd01508 2 irq9: acpi0 234 0 irq14: ata0 409 0 irq16: uhci0+246 0 irq20: hpet0 72288131 irq23: uhci2 ehci1 10846 19 irq256: hdac0 52 0 irq257: mskc04419760 8021 irq258: ahci0221 0 Total4505564 8177 - And vmstat -w1 for calm and storm: - procs memory pagedisks faults cpu r b w avmfre flt re pi pofr sr mm0 ad0 in sy cs us sy id 0 0 0 206928 956040 277 0 2 0 330 4 0 0 117 476 454 0 1 99 0 0 0 206928 956036 0 0 0 0 8 4 0 0 50 123 137 0 0 100 0 0 0 206928 956036 0 0 0 0 0 4 0 0 47 120 92 0 1 99 0 0 0 206928 956036 0 0 0 0 0 4 0 0 43 123 119 0 1 99 0 0 0 206928 956036 0 0 0 0 0 4 0 0 55 132 123 0 1 99 0 0 0 206928 956004 0 0 0 0 0 4 0 0 68 123 185 0 1 99 0 0 0 206928 956036 0 0 0 0 8 4 0 0 86 123 266 0 1 99 0 0 0 206928 956036 0 0 0 0 0 4 0 0 44 125 124 0 0 100 0 0 0 206928 956036 0 0 0 0 0 4 0 0 64 128 164 0 1 99 0 0 0 206928 956036 0 0 0 0 0 4 0 0 42 131 101 0 1 99 - procs memory pagedisks faults cpu r b w avmfre flt re pi pofr sr mm0 ad0 in sy cs us sy id 0 0 0 213648 954676 104 0 1 0 121 4 0 0 22299 204 44262 0 10 90 0 0 0 213648 954672 0 0 0 0 8 4 0 0 112259 123 222379 0 44 56 0 0 0 213648 954672 0 0 0 0 0 4 0 0 111792 123 221489 0 43 57 0 0 0 213648 954672 1 0 0 0 0 4 0 0 109887 183 217754 0 43 57 0 0 0 213648 954668 2 0 0 0 0 4 0 0 109543 146 216963 0 44 56 0 0 0 213648 954668 0 0 0 0 0 4 0 0 110142 123 218187 0 45 55 0 0 0 213648 954660 472 0 0 0 474 4 0 0 109340 717 216674 0 42 57 0 0 0 213648 954656 2 0 0 0 0 4 0 0 109459 147 216831 0 43 57 0 0 0 213648 954656 0 0 0 0 0 4
Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT
Yonghyeon PYUN wrote: On Mon, Feb 03, 2014 at 02:56:37PM +0100, Christian Brueffer wrote: Hi, for some time now we have had two drivers for NVIDIA NForce/MCP network chips, namely nve(4) and nfe(4). The former came first and is based on a binary blob. The latter was later ported from OpenBSD and is blob-free. nfe(4) supports all chips nve(4) supports, in addition to all the newer hardware. In essence, nfe(4) has been the de-facto standard driver for a long time. nve(4) has been commented out in GENERIC since 2007. For this reason I propose deprecating nve(4) in 10-STABLE and removing it from HEAD. Does anyone see a reason not to do this? A couple of users were still using nve(4) in the past. I guess the issue might be lack of code for waking up MAC/PHY from powerdown. nfe(4) already has the needed code and should support all known NVIDIA ethernet controllers with full offloading support. So no objection from me. It seems a good case to remove nve, no objection. Please remove at a leisurely managed pace: (unless code conflicts press for urgency), ie at least one minor release on each major branch should contain a code revocation warning in the manual preferably in a src/[A-Z]*, before the next minor release in same major release sequence might no longer contain old code. ( Not to suggest it wasn't planned similarly anyway, but some changes in other areas of FreeBSD have been rushed, it's good to set an example of planning maturity. ) Some FreeBSD end users inc. customers barely (if even) read announce@, let alone other lists such as these, but some do read manuals, notice code withdrawal warnings. I informed one old customer who was maybe still using nve, others might take a similar opportunity, a subtle way to also invite people to look at FreeBSD [again] ;-) , referring to eg: http://lists.freebsd.org/pipermail/freebsd-current/2014-February/048211.html http://svnweb.freebsd.org/base/release/10.0.0/share/man/man4/nve.4?view=markup http://svnweb.freebsd.org/base/release/10.0.0/share/man/man4/nfe.4?view=markup It seems safe to add a removal warning in http://svnweb.freebsd.org/base/head/share/man/man4/nve.4?view=markup ( there is not one yet at Rev 217468, I just checked. ) Best avoid the obscure word `Deprecated' in manuals: It's not common/ plain English. Maybe a geek import, or USA dialect ? It's not easily internationaly understood English. Best make manuals easier for non native English speakers ( native English too ;-). I am British born bred, whether in English speaking circles in UK or Germany I never hear or read 'deprecated' unless its in BSD context. Few native English speakers I know will be immediately sure of the meaning, it's too obscure. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with . Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ 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: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT
On 6 Feb 2014, at 18:34, Julian H. Stacey j...@berklix.com wrote: Best avoid the obscure word `Deprecated' in manuals: It's not common/ plain English. Maybe a geek import, or USA dialect ? It's not easily internationaly understood English. Best make manuals easier for non native English speakers ( native English too ;-). I am British born bred, whether in English speaking circles in UK or Germany I never hear or read 'deprecated' unless its in BSD context. Few native English speakers I know will be immediately sure of the meaning, it's too obscure. I'd strongly disagree with this. Deprecated is, perhaps, only in common use as jargon, but it's very widespread within the tech field. I don't think I've ever read an API reference that doesn't include the word, for example, and it's even a keyword in many code documentation tools. For example, JavaDoc supports @deprecated and gcc / clang include an __attribute__((deprecated)) that generates a compile-time warning whenever anyone tries to call a deprecated function. I've not come across the word outside of tech uses, but I've also not come across the term network interface outside of tech circles. Deprecated, in this use, may be jargon, but it's very widespread jargon, and requesting it not be used sounds like asking for words like driver or processor also be avoided. David (Also a native English speaker, although familiar with the unofficial fork from Leftpondia) ___ 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: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT
On Thu, Feb 6, 2014 at 6:34 PM, Julian H. Stacey j...@berklix.com wrote: Best avoid the obscure word `Deprecated' in manuals: It's not common/ plain English. Maybe a geek import, or USA dialect ? It's not easily internationaly understood English. Best make manuals easier for non native English speakers ( native English too ;-). I am British born bred, whether in English speaking circles in UK or Germany I never hear or read 'deprecated' unless its in BSD context. Few native English speakers I know will be immediately sure of the meaning, it's too obscure. As another Briton this surprises me: The word deprecate has a clear and specific meaning in all computing, especially in standards, release notes and documentation. It is from latin and is the same base word in all romance languages. It is definitely in common usage in the UK, I would not hesitate to use it any conversation with anyone and expect them to understand its meaning. To my ear there is no clearer word to use for this purpose. Cheers Tom ___ 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
[PATCH] PCI bus number management
I have a patch to teach the PCI bus code and PCI-PCI bridge driver to manage PCI bus numbers. The approach is somewhat similar to how NEW_PCIB manages I/O windows for briges. Each bridge creates an rman to manage the bus numbers for all buses and bridges that live below it. Each bus allocates a bus resource from its parent bridge, and child bridges allocate their ranges from their parent devices. At the top of the PCI tree, the Host-PCI bridges allocate their respective bus ranges from their PCI domain/segment. There isn't really a device node for PCI domains, so I created a helper API that basically auto- creates a PCI bus rman for each domain on first use and then sub-allocates from that for Host-PCI bridges. The current patch (with some extra debugging) is at http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch I would like to commit this to HEAD soon but thought I would post it for some pre-commit testing for the brave. :) If you are really brave, try booting with 'hw.pci.clear_buses=1' which will force the kernel to renumber all buses in the system. If you are really, really brave, try booting with 'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'. (My laptop survives with all those set) Note that the patch only enables bus number management on amd64 and i386. I believe ia64 just needs to define PCI_RES_BUS for this to work since it mandates ACPI. Porting this to other platforms requires handling PCI_RES_BUS rseources for Host-PCI bridges in bus_alloc_resource(), bus_adjust_resource(), and bus_release_resource(). -- John Baldwin ___ 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: [PATCH] PCI bus number management
On Thu, Feb 6, 2014 at 2:37 PM, John Baldwin j...@freebsd.org wrote: I have a patch to teach the PCI bus code and PCI-PCI bridge driver to manage PCI bus numbers. The approach is somewhat similar to how NEW_PCIB manages I/O windows for briges. Each bridge creates an rman to manage the bus numbers for all buses and bridges that live below it. Each bus allocates a bus resource from its parent bridge, and child bridges allocate their ranges from their parent devices. At the top of the PCI tree, the Host-PCI bridges allocate their respective bus ranges from their PCI domain/segment. There isn't really a device node for PCI domains, so I created a helper API that basically auto- creates a PCI bus rman for each domain on first use and then sub-allocates from that for Host-PCI bridges. The current patch (with some extra debugging) is at http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch I would like to commit this to HEAD soon but thought I would post it for some pre-commit testing for the brave. :) If you are really brave, try booting with 'hw.pci.clear_buses=1' which will force the kernel to renumber all buses in the system. If you are really, really brave, try booting with 'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'. (My laptop survives with all those set) Note that the patch only enables bus number management on amd64 and i386. I believe ia64 just needs to define PCI_RES_BUS for this to work since it mandates ACPI. Porting this to other platforms requires handling PCI_RES_BUS rseources for Host-PCI bridges in bus_alloc_resource(), bus_adjust_resource(), and bus_release_resource(). -- John Baldwin I get a 404 - Not Found trying to follow the link. ___ 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: [PATCH] PCI bus number management
On Thu, Feb 6, 2014 at 2:47 PM, Thomas Hoffmann trh...@gmail.com wrote: On Thu, Feb 6, 2014 at 2:37 PM, John Baldwin j...@freebsd.org wrote: I have a patch to teach the PCI bus code and PCI-PCI bridge driver to manage PCI bus numbers. The approach is somewhat similar to how NEW_PCIB manages I/O windows for briges. Each bridge creates an rman to manage the bus numbers for all buses and bridges that live below it. Each bus allocates a bus resource from its parent bridge, and child bridges allocate their ranges from their parent devices. At the top of the PCI tree, the Host-PCI bridges allocate their respective bus ranges from their PCI domain/segment. There isn't really a device node for PCI domains, so I created a helper API that basically auto- creates a PCI bus rman for each domain on first use and then sub-allocates from that for Host-PCI bridges. The current patch (with some extra debugging) is at http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch I would like to commit this to HEAD soon but thought I would post it for some pre-commit testing for the brave. :) If you are really brave, try booting with 'hw.pci.clear_buses=1' which will force the kernel to renumber all buses in the system. If you are really, really brave, try booting with 'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'. (My laptop survives with all those set) Note that the patch only enables bus number management on amd64 and i386. I believe ia64 just needs to define PCI_RES_BUS for this to work since it mandates ACPI. Porting this to other platforms requires handling PCI_RES_BUS rseources for Host-PCI bridges in bus_alloc_resource(), bus_adjust_resource(), and bus_release_resource(). -- John Baldwin I get a 404 - Not Found trying to follow the link. Got it by backing up one level on the link and selecting form the list. ___ 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: [PATCH] PCI bus number management
On Thursday, February 06, 2014 2:47:09 pm Thomas Hoffmann wrote: On Thu, Feb 6, 2014 at 2:37 PM, John Baldwin j...@freebsd.org wrote: I have a patch to teach the PCI bus code and PCI-PCI bridge driver to manage PCI bus numbers. The approach is somewhat similar to how NEW_PCIB manages I/O windows for briges. Each bridge creates an rman to manage the bus numbers for all buses and bridges that live below it. Each bus allocates a bus resource from its parent bridge, and child bridges allocate their ranges from their parent devices. At the top of the PCI tree, the Host-PCI bridges allocate their respective bus ranges from their PCI domain/segment. There isn't really a device node for PCI domains, so I created a helper API that basically auto- creates a PCI bus rman for each domain on first use and then sub-allocates from that for Host-PCI bridges. The current patch (with some extra debugging) is at http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch I would like to commit this to HEAD soon but thought I would post it for some pre-commit testing for the brave. :) If you are really brave, try booting with 'hw.pci.clear_buses=1' which will force the kernel to renumber all buses in the system. If you are really, really brave, try booting with 'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'. (My laptop survives with all those set) Note that the patch only enables bus number management on amd64 and i386. I believe ia64 just needs to define PCI_RES_BUS for this to work since it mandates ACPI. Porting this to other platforms requires handling PCI_RES_BUS rseources for Host-PCI bridges in bus_alloc_resource(), bus_adjust_resource(), and bus_release_resource(). -- John Baldwin I get a 404 - Not Found trying to follow the link. Oops, it is: http://people.freebsd.org/~jhb/patches/pci_bus_rman3.patch -- John Baldwin ___ 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: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT
Hi, Reference: From: David Chisnall thera...@freebsd.org Date: Thu, 6 Feb 2014 18:52:43 + David Chisnall wrote: On 6 Feb 2014, at 18:34, Julian H. Stacey j...@berklix.com wrote: Best avoid the obscure word `Deprecated' in manuals: It's not common/ plain English. Maybe a geek import, or USA dialect ? It's not easily internationaly understood English. Best make manuals easier for non native English speakers ( native English too ;-). I am British born bred, whether in English speaking circles in UK or Germany I never hear or read 'deprecated' unless its in BSD context. Few native English speakers I know will be immediately sure of the meaning, it's too obscure. I'd strongly disagree with this. Deprecated is, perhaps, only in common use as jargon, but it's very widespread within the tech field. I don't think I've ever read an API reference that doesn't include the word, for example, and it's even a keyword in many code documentation tools. For example, JavaDoc supports @deprecated and gcc / clang include an __attribute__((deprecated)) that generates a compile-time warning whenever anyone tries to call a deprecated function. I've not come across the word outside of tech uses, but I've also not come across the term network interface outside of tech circles. Deprecated, in this use, may be jargon, but it's very widespread jargon, and requesting it not be used sounds like asking for words like driver or processor also be avoided. David (Also a native English speaker, although familiar with the unofficial fork from Leftpondia) Uh Huh ;-) http://en.wiktionary.org/wiki/Leftpondia American 1620 fork of English deduced. 1620: When a Mayflower butter maid Deprecated a milk maid giving 20 ounces to a pint, confused USA liquids down to 16 ounces. (Beware man units). Amerian is not always best international English. It's a big early variant of English, but other native English speakers round the globe well outnumber American I believe. (Start with a map of the Commonwealth), many 2nd language people too will help define international English, (as José Manuel Barroso, EU commission president, said), not just natives, eg British or Americans etc, will get to shape international English. Americans often seem to find it harder to grasp what's internationaly portable English, as opposed to American, perhaps because a large country makes a higher percentage of language experience internal national usage. FreeBSD's manual writers, especially non native English manual writers, should not copy Americanisms /or bad nomenclature from one manual to another, but ask themselves if they know better words, to make it easier also for other non native English to read. eg Deprecated is not common English. PS Light relief: http://www.bbc.com/future/story/20140206-can-drones-be-hacked Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with . Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ 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: [PATCH] PCI bus number management
On 02/06/14 14:37, John Baldwin wrote: I have a patch to teach the PCI bus code and PCI-PCI bridge driver to manage PCI bus numbers. The approach is somewhat similar to how NEW_PCIB manages I/O windows for briges. Each bridge creates an rman to manage the bus numbers for all buses and bridges that live below it. Each bus allocates a bus resource from its parent bridge, and child bridges allocate their ranges from their parent devices. At the top of the PCI tree, the Host-PCI bridges allocate their respective bus ranges from their PCI domain/segment. There isn't really a device node for PCI domains, so I created a helper API that basically auto- creates a PCI bus rman for each domain on first use and then sub-allocates from that for Host-PCI bridges. The current patch (with some extra debugging) is at http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch I would like to commit this to HEAD soon but thought I would post it for some pre-commit testing for the brave. :) If you are really brave, try booting with 'hw.pci.clear_buses=1' which will force the kernel to renumber all buses in the system. If you are really, really brave, try booting with 'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'. (My laptop survives with all those set) Note that the patch only enables bus number management on amd64 and i386. I believe ia64 just needs to define PCI_RES_BUS for this to work since it mandates ACPI. Porting this to other platforms requires handling PCI_RES_BUS rseources for Host-PCI bridges in bus_alloc_resource(), bus_adjust_resource(), and bus_release_resource(). Setting all 3 on an Atom D510MO works fine. On a Lenovo W520 though hw.pci.clear_bars=1 causes a lockup during boot. The last few lines with a normal boot are: pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pcib0: decoding 5 range 0-0xfe pci0: ACPI PCI bus on pcib0 secbus=1, subbus=1 pci0:0:1:0: allocated initial secbus range While a verbose boot produces: pcib0: allocated type 3 (0xc400-0xc7ff) for rid 10 of pci:0:0:26:0 pcib0: matched entry for 0x26.INTA pcib0: slot 26 INTA hardwired to IRQ 26 And it ends there. Setting the other 2 are fine though. ___ 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: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT
On 2014-02-06 22:18, Julian H. Stacey wrote: Hi, Reference: From:David Chisnall thera...@freebsd.org Date:Thu, 6 Feb 2014 18:52:43 + David Chisnall wrote: On 6 Feb 2014, at 18:34, Julian H. Stacey j...@berklix.com wrote: Best avoid the obscure word `Deprecated' in manuals: It's not common/ plain English. Maybe a geek import, or USA dialect ? It's not easily internationaly understood English. Best make manuals easier for non native English speakers ( native English too ;-). I am British born bred, whether in English speaking circles in UK or Germany I never hear or read 'deprecated' unless its in BSD context. Few native English speakers I know will be immediately sure of the meaning, it's too obscure. I'd strongly disagree with this. Deprecated is, perhaps, only in common use as jargon, but it's very widespread within the tech field. I don't think I've ever read an API reference that doesn't include the word, for example, and it's even a keyword in many code documentation tools. For example, JavaDoc supports @deprecated and gcc / clang include an __attribute__((deprecated)) that generates a compile-time warning whenever anyone tries to call a deprecated function. I've not come across the word outside of tech uses, but I've also not come across the term network interface outside of tech circles. Deprecated, in this use, may be jargon, but it's very widespread jargon, and requesting it not be used sounds like asking for words like driver or processor also be avoided. David (Also a native English speaker, although familiar with the unofficial fork from Leftpondia) Uh Huh ;-) http://en.wiktionary.org/wiki/Leftpondia American 1620 fork of English deduced. 1620: When a Mayflower butter maid Deprecated a milk maid giving 20 ounces to a pint, confused USA liquids down to 16 ounces. (Beware man units). Amerian is not always best international English. It's a big early variant of English, but other native English speakers round the globe well outnumber American I believe. (Start with a map of the Commonwealth), many 2nd language people too will help define international English, (as José Manuel Barroso, EU commission president, said), not just natives, eg British or Americans etc, will get to shape international English. Americans often seem to find it harder to grasp what's internationaly portable English, as opposed to American, perhaps because a large country makes a higher percentage of language experience internal national usage. FreeBSD's manual writers, especially non native English manual writers, should not copy Americanisms /or bad nomenclature from one manual to another, but ask themselves if they know better words, to make it easier also for other non native English to read. eg Deprecated is not common English. PS Light relief: http://www.bbc.com/future/story/20140206-can-drones-be-hacked Cheers, Julian ___ 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 The problem with 'deprecated' is that it often means 'this is no longer the suggested way to do it', not necessarily 'this method of doing it will soon cease working'. For example, in /etc/rc.conf ifconfig_em0_aliasX is deprecated But it still works, and as far as I am aware, there are no plans to stop supporting it, it is just 'recommended', that you use ipv4_addrs_em0 I think the word deprecated is fine, but it should also be made clear that nve is going away and that you should switch to nfe immediately. -- Allan Jude signature.asc Description: OpenPGP digital signature
