Re: vfs_bio.c revision 259200 breaks writing to tape drive on current
On 12/23/13, 8:31 AM, Konstantin Belousov wrote: On Sun, Dec 22, 2013 at 09:54:49AM -0800, Manfred Antar wrote: The change to vfs_bio.c in revision 259200 breaks writing to scsi tape drive on i386 and sparc64 on current. I don't have any other machines to test on. here is example: r259199: (/)4794}mt rew (/)4795}tar cvf /dev/sa0 kernel a kernel r259200: (/)4781}mt rew (/)4782}tar cvf /dev/sa0 kernel a kerneltar: Write error the changes between the two revisions: line 3682 removed: bp-b_resid = bip-bio_resid; /* XXX: remove */ I noticed this when trying to do a dump and getting end of tape error. tried different tape drives , different cables no change. backed out r259200 to 259199 and everything works as before. Manfred Show me the kdump of the tar commands on both revisions. I had to do all sorts of special handling back in the 1.x days to get tape drives to work correctly. length and resid ahndlign were susceptible to failure in hte various different schemes of how tape drive s shoud work (variable lenght records, fixed length and ather variations I forget) . ___ 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: vfs_bio.c revision 259200 breaks writing to tape drive on current
At 11:31 PM 12/22/2013, you wrote: On Sun, Dec 22, 2013 at 09:54:49AM -0800, Manfred Antar wrote: The change to vfs_bio.c in revision 259200 breaks writing to scsi tape drive on i386 and sparc64 on current. I don't have any other machines to test on. here is example: r259199: (/)4794}mt rew (/)4795}tar cvf /dev/sa0 kernel a kernel r259200: (/)4781}mt rew (/)4782}tar cvf /dev/sa0 kernel a kerneltar: Write error the changes between the two revisions: line 3682 removed: bp-b_resid = bip-bio_resid; /* XXX: remove */ I noticed this when trying to do a dump and getting end of tape error. tried different tape drives , different cables no change. backed out r259200 to 259199 and everything works as before. Manfred Show me the kdump of the tar commands on both revisions. It will take me a few hours, back to work today. Same thing happens with dump too. The Tape drives are SCSI Quantum DLT used on both machines i386 and sparc64 (Sun Netra) using version 258174 of vfs_bio.c on current kernels, I was able to do a full dump of both machines without a problem. The error is when trying to read or write to the tape drive. What is the exact command for kdump that you want ? I can do it when I get home this afternoon. Thanks Manfred ___ 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: GHCi vs iconv_open
On 12/22/13 13:35, d...@gmx.com wrote: After a recent installworld, GHCi (``ghc -i'' from lang/ghc) fails like so: % ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... ghc: /usr/local/lib/ghc-7.6.3/base-4.6.0.1/HSbase-4.6.0.1.o: unknown symbol `iconv_open' ghc: unable to load package `base' Running portupgrade to rebuild all (most) ports didn't help. Where's the issue / Do what? I recently ran into the same problem on 10.0, and thanks to Gabor Pali (p...@freebsd.org) ghci is working again for me. Here's what he said: ... You can find a patch in ports/184806 [1] that resolves the problem. I have not yet come to commit this file as I have not finished with the large-scale testing, but it is very likely that it will be added to the port soon. Cheers, Gabor [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=184806 -- Richard Kuhns r...@wintek.com Direct: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: Problem with ebook reader on usb
On Sun, 8 Dec 2013 22:54:25 +0100 Marc UBM Bocklet ubm.free...@gmail.com wrote: On Sun, 8 Dec 2013 22:44:33 +0100 Marc UBM Bocklet ubm.free...@gmail.com wrote: Hiho! :-) I got myself a new ebook reader (Onyx M92), but encountered a strange problem when connecting it to my freebsd machine. Shortly after mounting it, the device gets disconnected (causing the mounted storage to disappear). There is no such behavior with Windows 7. uname -a: FreeBSD xxx 11.0-CURRENT FreeBSD 11.0-CURRENT #11 r258254M: Sun Nov 17 13:38:01 CET 2013 xxx:/usr/obj/usr/src/sys/SUBMARINE_SMP amd64 Following up: With FreeBSD xxx 11.0-CURRENT FreeBSD 11.0-CURRENT #16 r258254:259095M: Sun Dec 15 08:53:22 CET 2013 xxx:/usr/obj/usr/src/sys/SUBMARINE_SMP amd64 the problem has disappeared. Bye Marc ___ 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: Problem with ebook reader on usb
On 12/23/13 15:23, Marc UBM wrote: On Sun, 8 Dec 2013 22:54:25 +0100 Marc UBM Bocklet ubm.free...@gmail.com wrote: On Sun, 8 Dec 2013 22:44:33 +0100 Marc UBM Bocklet ubm.free...@gmail.com wrote: Hiho! :-) I got myself a new ebook reader (Onyx M92), but encountered a strange problem when connecting it to my freebsd machine. Shortly after mounting it, the device gets disconnected (causing the mounted storage to disappear). There is no such behavior with Windows 7. uname -a: FreeBSD xxx 11.0-CURRENT FreeBSD 11.0-CURRENT #11 r258254M: Sun Nov 17 13:38:01 CET 2013 xxx:/usr/obj/usr/src/sys/SUBMARINE_SMP amd64 Following up: With FreeBSD xxx 11.0-CURRENT FreeBSD 11.0-CURRENT #16 r258254:259095M: Sun Dec 15 08:53:22 CET 2013 xxx:/usr/obj/usr/src/sys/SUBMARINE_SMP amd64 the problem has disappeared. Hi, Thank you! Probably one of the XHCI patches. --HPS ___ 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: vfs_bio.c revision 259200 breaks writing to tape drive on current
On Mon, Dec 23, 2013 at 05:35:23AM -0800, Manfred Antar wrote: At 11:31 PM 12/22/2013, you wrote: On Sun, Dec 22, 2013 at 09:54:49AM -0800, Manfred Antar wrote: The change to vfs_bio.c in revision 259200 breaks writing to scsi tape drive on i386 and sparc64 on current. I don't have any other machines to test on. here is example: r259199: (/)4794}mt rew (/)4795}tar cvf /dev/sa0 kernel a kernel r259200: (/)4781}mt rew (/)4782}tar cvf /dev/sa0 kernel a kerneltar: Write error the changes between the two revisions: line 3682 removed: bp-b_resid = bip-bio_resid; /* XXX: remove */ I noticed this when trying to do a dump and getting end of tape error. tried different tape drives , different cables no change. backed out r259200 to 259199 and everything works as before. Manfred Show me the kdump of the tar commands on both revisions. It will take me a few hours, back to work today. Same thing happens with dump too. The Tape drives are SCSI Quantum DLT used on both machines i386 and sparc64 (Sun Netra) using version 258174 of vfs_bio.c on current kernels, I was able to do a full dump of both machines without a problem. The error is when trying to read or write to the tape drive. What is the exact command for kdump that you want ? I can do it when I get home this afternoon. Thanks Manfred ktrace -i tar ... kdump -s some.file I need some.file. pgpOf9kvjmroF.pgp Description: PGP signature
Re: makefs enhancement for better rock-ridge support
On 18 December 2013 09:27, Kurt Lidl l...@pix.net wrote: A while ago, it was reported that the ISO images that FreeBSD generates have a variety of problems (thread starts here): http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073050.html And again for the 10.0 releases: http://lists.freebsd.org/pipermail/freebsd-stable/2013-December/076284.html Looking into this, it appears that the various bugs in the Rock Ridge extensions have been fixed, except for the actual lack of recording the serial numbers in the correct place of the Rock Ridge data. As it turns out, it is almost trivial to fix this. Patch is attached to this message, which will probably be stripped out by the mailing list, but should be available as an attachment from the mail server. On Wed, Dec 18, 2013 at 11:41:49PM -0800, Adrian Chadd wrote: Would you mind filing a PR? -a This was filed as: http://www.freebsd.org/cgi/query-pr.cgi?pr=185138 -Kurt ___ 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
A tweak to HWPMC hooks to improve code generation
The HWPMC hooks are never invoked except when using the soft PMC feature for performance monitoring. This trivial patch hints as much to the compiler, which then moves some fairly lengthy code sequences out of the locking primitives (in particular), reducing their runtime footprint. This patch was reviewed by Attilio Rao. Anton pmckern.diff Description: pmckern.diff ___ 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: 11.0-CURRENT panic while running a bhyve instance
Hi Markiyan, Fixed in r259737: http://svnweb.freebsd.org/changeset/base/259737 best Neel On Fri, Dec 13, 2013 at 2:35 PM, Markiyan Kushnir markiyan.kush...@gmail.com wrote: 2013/12/13 John Baldwin j...@freebsd.org: On Friday, December 13, 2013 5:46:20 am Markiyan Kushnir wrote: Forgot to fill the Subject: header, re-posting it fixed. The mailing lists strips attachments, can you post it at a URL? Shared here: https://drive.google.com/file/d/0B9Q-zpUXxqCnem5iYTVqLUxrcWo4cmlhdkM1c2lJa2dKak5R/edit?usp=sharing -- Markiyan. -- Markiyan -- Forwarded message -- From: Markiyan Kushnir markiyan.kush...@gmail.com Date: 2013/12/13 Subject: To: freebsd-current@freebsd.org, freebsd-virtualizat...@freebsd.org I started some ports to compile inside a bhyve instance: root@vm:~ # uname -a FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r259250: Thu Dec 12 14:17:32 EET 2013 r...@vm.mkushnir.zapto.org:/ usr/obj/usr/src.svnup/sys/MAREK amd64 and left it running unattended. Approx. 2 hours later the host went to panic. The bhyve instance survived after the panic and I could be able to complete my ports compilation. core.txt attached (gzipped) ___ 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 -- 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 ___ 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 can we use __builtin_prefetch() directly in our kernel sources ?
On Monday, December 16, 2013 11:50:14 am Luigi Rizzo wrote: Is it ok in kernel code to use __builtin_prefetch() and assume that all supported compilers will do the right thing for all architectures ? I am asking is because I need to use prefetch() in a small number of places in my netmap code, and nothing in our kernel sources uses __builtin_prefetch() directly. In the (very few, mostly 10G drivers) cases where prefetch() is used the drivers redefine the function themselves as some inline asm() or an empty #define prefetch(x) This also happens in many places in the linux kernel, for what matters (relevant because hte netmap kernel code also needs to compile there). Anyways, so far in the netmap code i have followed the established practice but my (re)definition of prefetch() in netmap_kern.h clashes with some in the individual drivers, so I'd rather find a better way. H, have you considered using a 'netmap_prefetch' macro or the like? You can likely just use __builtin_prefetch() on FreeBSD I think, but that might also let you avoid collisions on Linux as well. I think you can use __builtin_prefetch(), I'm just not sure, and it's kind of ugly to see __builtin_*() in code directly IMHO. -- 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: kasserts behind invariants
On Friday, December 13, 2013 4:50:25 pm Sean Bruno wrote: I guess this may have been argued before, but I don't see why we would want to hide specific things like: sys/kern/subr_lock.c /* Check for double-init and zero object. */ KASSERT(!lock_initalized(lock), (lock \%s\ %p already initialized, name, lock)); If I hadn't completely missed the fact that I had INVARIANTS activated, I'd never have found out why this vendor driver was being so completely stupid and crashing my machine. If I find things like this that I want old KASSERT behavior on (panic if true) and I don't want to run INVARIANTS, is that possible? KASSERT has never been enabled sans INVARIANTS. -- 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: panic with deactivated geom mirror (both 9.2 and 10.0-RC2)
On Wednesday, December 18, 2013 11:52:54 pm Kurt Lidl wrote: Greetings all - I've got a completely reproducible panic when issuing a 'gmirror status' command on a recently deactivated gmirror. NOTE: This only happens on a machine with more than 1 CPU. I filed a bug report on it: http://www.freebsd.org/cgi/query-pr.cgi?pr=184985 Script to reproduce the panic: (assumes /dev/ada0p3 is a scratch partition) while : do gmirror label -v scratch /dev/ada0p3 newfs /dev/mirror/scratch mount /dev/mirror/scratch /mnt umount -f /mnt gmirror deactivate scratch /dev/ada0p3 gmirror status scratch done I've attached the core.txt.0 file from the crash under 10.0-RC2. Probably stripped by the mailing list. A copy is at http://www.pix.net/staff/lidl/freebsd/core.txt.0 Can you do 'frame 9' and then 'p *gp' and 'p *sc' in kgdb? -- 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: new Xorg (KMS, etc.) for Radeon 9600
On Wednesday, December 18, 2013 2:43:28 pm Adrian Chadd wrote: [snip] So the standard trop of UNLOCK/WORK/RELOCK is pretty dangerous. There's no state re-validation going on when you re-acquire that lock. So, although it meets the lock requirements, it may not be 'correct'. It's scattered throughout the code base (wifi drivers aren't an exception here either, sigh.) Just something to keep in mind when you validate the 'correctness' of this kind of lock hack. Agreed. It needs fixing, but the fix needs to be correct. -- 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: [HEADS UP] xorg version switch in CURRENT
On Tuesday, December 17, 2013 3:07:56 pm Steve Kargl wrote: On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote: To get VT switching when using KMS drivers (ATI, Intel) please use newcons: https://wiki.freebsd.org/Newcons or if that is not possible, force the use of the vesa driver for xorg. It appears that newcons is unusable with a static kernel. Adding 'device drm2' and 'device i915kms' to my kernel config results in a quick death to 'make buldkernel'. That isn't due to newcons AFAIK. I don't think that setup worked with syscons either. I think it could probably never have worked with syscons, but it should in theory be fixable with newcons. -- 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: [HEADS UP] xorg version switch in CURRENT
On Tuesday, December 17, 2013 3:15:33 pm Adrian Chadd wrote: I'm rapidly wondering if building this way should become unsupported. Too muxh unknown stuff is needed at startup and wed have to load all firmware bits to make it remotely work. The Intel driver (i915kms) does not need firmware bits. Radeon does, but those could be statically compiled in for people who want this. The drivers should be fixed. They never worked with syscons because syscons didn't work once KMS was enabled, but they should be able to work with newcons. -- 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
[head tinderbox] failure on i386/i386
TB --- 2013-12-23 19:50:20 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-23 19:50:20 - 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 --- 2013-12-23 19:50:20 - starting HEAD tinderbox run for i386/i386 TB --- 2013-12-23 19:50:20 - cleaning the object tree TB --- 2013-12-23 19:50:20 - /usr/local/bin/svn stat /src TB --- 2013-12-23 19:50:25 - At svn revision 259782 TB --- 2013-12-23 19:50:26 - building world TB --- 2013-12-23 19:50:26 - CROSS_BUILD_TESTING=YES TB --- 2013-12-23 19:50:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-23 19:50:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-23 19:50:26 - SRCCONF=/dev/null TB --- 2013-12-23 19:50:26 - TARGET=i386 TB --- 2013-12-23 19:50:26 - TARGET_ARCH=i386 TB --- 2013-12-23 19:50:26 - TZ=UTC TB --- 2013-12-23 19:50:26 - __MAKE_CONF=/dev/null TB --- 2013-12-23 19:50:26 - cd /src TB --- 2013-12-23 19:50:26 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Mon Dec 23 19:50:35 UTC 2013 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 stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Mon Dec 23 22:59:47 UTC 2013 TB --- 2013-12-23 22:59:47 - generating LINT kernel config TB --- 2013-12-23 22:59:47 - cd /src/sys/i386/conf TB --- 2013-12-23 22:59:47 - /usr/bin/make -B LINT TB --- 2013-12-23 22:59:47 - cd /src/sys/i386/conf TB --- 2013-12-23 22:59:47 - /usr/sbin/config -m LINT TB --- 2013-12-23 22:59:47 - building LINT kernel TB --- 2013-12-23 22:59:47 - CROSS_BUILD_TESTING=YES TB --- 2013-12-23 22:59:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-23 22:59:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-23 22:59:47 - SRCCONF=/dev/null TB --- 2013-12-23 22:59:47 - TARGET=i386 TB --- 2013-12-23 22:59:47 - TARGET_ARCH=i386 TB --- 2013-12-23 22:59:47 - TZ=UTC TB --- 2013-12-23 22:59:47 - __MAKE_CONF=/dev/null TB --- 2013-12-23 22:59:47 - cd /src TB --- 2013-12-23 22:59:47 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Dec 23 22:59:47 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] In file included from /src/sys/contrib/dev/acpica/include/platform/acfreebsd.h:73: /src/sys/sys/systm.h:306:20: error: redefinition of 'cpu_ticks' as different kind of symbol extern cpu_tick_f *cpu_ticks; ^ ./machine/cpu.h:86:10: note: previous definition is here return (cpu_ticks()); ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-23 23:21:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-23 23:21:30 - ERROR: failed to build LINT kernel TB --- 2013-12-23 23:21:30 - 10190.92 user 1860.75 system 12669.42 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.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: 11.0-CURRENT panic while running a bhyve instance
Works for me (I'm at r259742), no panic. Thanks! -- Markiyan. 2013/12/23 Neel Natu neeln...@gmail.com: Hi Markiyan, Fixed in r259737: http://svnweb.freebsd.org/changeset/base/259737 best Neel On Fri, Dec 13, 2013 at 2:35 PM, Markiyan Kushnir markiyan.kush...@gmail.com wrote: 2013/12/13 John Baldwin j...@freebsd.org: On Friday, December 13, 2013 5:46:20 am Markiyan Kushnir wrote: Forgot to fill the Subject: header, re-posting it fixed. The mailing lists strips attachments, can you post it at a URL? Shared here: https://drive.google.com/file/d/0B9Q-zpUXxqCnem5iYTVqLUxrcWo4cmlhdkM1c2lJa2dKak5R/edit?usp=sharing -- Markiyan. -- Markiyan -- Forwarded message -- From: Markiyan Kushnir markiyan.kush...@gmail.com Date: 2013/12/13 Subject: To: freebsd-current@freebsd.org, freebsd-virtualizat...@freebsd.org I started some ports to compile inside a bhyve instance: root@vm:~ # uname -a FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r259250: Thu Dec 12 14:17:32 EET 2013 r...@vm.mkushnir.zapto.org:/ usr/obj/usr/src.svnup/sys/MAREK amd64 and left it running unattended. Approx. 2 hours later the host went to panic. The bhyve instance survived after the panic and I could be able to complete my ports compilation. core.txt attached (gzipped) ___ 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 -- 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 ___ 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
device vtnet - device virtio_net?
Hi, GENERIC has # VirtIO support device virtio # Generic VirtIO bus (required) device virtio_pci # VirtIO PCI device device vtnet # VirtIO Ethernet device device virtio_blk # VirtIO Block device device virtio_scsi # VirtIO SCSI device device virtio_balloon # VirtIO Memory Balloon device Maybe it's just my OCD kicking in, but why is vtnet not named virtio_net? That would be consistent with the other virtio device names. Cheers, Jos -- Jos Backus jos at catnook.com ___ 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: A tweak to HWPMC hooks to improve code generation
Hm! Cool! I'll give this a spin tomorrow on my frequently-very-lock-busy boxes and get back to you. -a On 23 December 2013 09:52, Rang, Anton anton.r...@isilon.com wrote: The HWPMC hooks are never invoked except when using the soft PMC feature for performance monitoring. This trivial patch hints as much to the compiler, which then moves some fairly lengthy code sequences out of the locking primitives (in particular), reducing their runtime footprint. This patch was reviewed by Attilio Rao. 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 ___ 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: device vtnet - device virtio_net?
- Original Message - Hi, GENERIC has # VirtIO support device virtio # Generic VirtIO bus (required) device virtio_pci # VirtIO PCI device device vtnet # VirtIO Ethernet device device virtio_blk # VirtIO Block device device virtio_scsi # VirtIO SCSI device device virtio_balloon # VirtIO Memory Balloon device Maybe it's just my OCD kicking in, but why is vtnet not named virtio_net? That would be consistent with the other virtio device names. That's what I picked 3 some years ago and it is too late to change it. I believe my thinking at the time was to match most other Ethernet drives: the module name is if_vtnet, so use vtnet in the kernel config. Cheers, Jos -- Jos Backus jos at catnook.com ___ 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
