Re: Mixed ashift?
On 2016-03-31 02:13, Dustin Marquess wrote: > I have what I think is a pretty normal setup.. a bunch of HDDs plus 2 SSDs > (one ZIL, one SLOG). > > The HDDs are standard 512 byte sector drives. The SSDs have 8k page sizes. > > In Illumos I added the SSDs to sd.conf and created the zpool and it shows > the HDDs as ashift 9 and the SSDs as ashift 13, like normal: > > # zdb -C | grep ashift > ashift: 9 > ashift: 9 > ashift: 9 > ashift: 9 > ashift: 13 > > The question is, how to replicate this in FreeBSD? The old "gnop" method > doesn't work anymore, and setting "vfs.zfs.min_auto_ashift=13" causes it to > use 13 for the HDDs, which seems like a waste. Is this not supported? > > Thanks! > -Dustin > ___ > 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" > gnop should work, and you'd set the ashift before you add the devices. So add the hard drives with it set to 9, then set it to 13 and add the SLOG -- Allan Jude signature.asc Description: OpenPGP digital signature
Mixed ashift?
I have what I think is a pretty normal setup.. a bunch of HDDs plus 2 SSDs (one ZIL, one SLOG). The HDDs are standard 512 byte sector drives. The SSDs have 8k page sizes. In Illumos I added the SSDs to sd.conf and created the zpool and it shows the HDDs as ashift 9 and the SSDs as ashift 13, like normal: # zdb -C | grep ashift ashift: 9 ashift: 9 ashift: 9 ashift: 9 ashift: 13 The question is, how to replicate this in FreeBSD? The old "gnop" method doesn't work anymore, and setting "vfs.zfs.min_auto_ashift=13" causes it to use 13 for the HDDs, which seems like a waste. Is this not supported? Thanks! -Dustin ___ 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: Booting FreeBSD on a RPI3
Nice to know, thanks a lot :) > El 30 març 2016, a les 1:38, Adrian Chadd va > escriure: > > Hi, > > It's under active development right now. Stay tuned. > > > -a > > > On 29 March 2016 at 13:58, Gala IT wrote: >> Hi, >> >> Being that it’s a 64-bit system and RPI2 images don’t work, is there any >> procedure already established to build an image to boot on a Raspberry Pi 3? >> >> Should Crochet work? How? >> >> Thanks, >> David. >> ___ >> 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" ___ 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: accessing a PCIe register from userspace through kmem or other ways ?
On Wed, Mar 30, 2016 at 10:47 AM, Luigi Rizzo wrote: > Hi, > I'd like to test the rate at which I can access device registers > on a PCIe card, and was wondering whether I need to patch a device > driver, or perhaps I can use /dev/kmem once I figure out where > the registers are mapped ? > You do not need to patch a device driver. Have you looked at libpciaccess? This should give you everything you need. -Jim > thanks > 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-2217533 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -+--- > ___ > 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" > ___ 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"
accessing a PCIe register from userspace through kmem or other ways ?
Hi, I'd like to test the rate at which I can access device registers on a PCIe card, and was wondering whether I need to patch a device driver, or perhaps I can use /dev/kmem once I figure out where the registers are mapped ? thanks 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-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ 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: Need some help with ports and rebuilding the world
On Wed, 30 Mar 2016, Aleksander Alekseev wrote: CPUTYPE?=native CFLAGS+=-O2 -pipe CXXFLAGS+=-O2 -pipe These will bite with no provocation, and prevent ports that want to set their own flags from using them. Frankly as a rule of thumb I prefer binary packages. But how would you recommend to change these lines? You see if I use ports I would like compiled code to be optimized and preferably for local CPU. Don't set them at all, just remove those lines from make.conf. Well, let me be more specific. It is probably safe to set CPUTYPE, although choosing native has caused problems for me, where specifically setting a type like core-avx2 has been fine. It is just the CFLAGS and CXXFLAGS that are best not set. When not set, the world and kernel build will use safe defaults, but ports that can safely override those flags for better performance can do so. ___ 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: HEAD does not build bwn (after r297405 ?)
Am 30.03.16 um 13:08 schrieb Jia-Shiun Li: On Wed, Mar 30, 2016 at 2:06 PM, Rainer Hurling mailto:rhur...@gwdg.de>> wrote: If I try to build most recent HEAD (r297407), I get the following error: I suspect r297405 with its migration of time_* macros to be the reason? Adrian Chadd fixed that in r297409. Thanks for the info. I already noticed it and rebuild my box. Works fine so far. -Jia-Shiun. ___ 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"
FreeBSD_HEAD_amd64_gcc4.9 - Build #1140 - Still Failing
FreeBSD_HEAD_amd64_gcc4.9 - Build #1140 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1140/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1140/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1140/console Change summaries: 297409 by adrian: [bwn] fix time_before -> ieee80211_time_before() Noticed by: Jia-Shiun Li 297408 by pfg: freopen(3): prevent uninitialized errno. Revert r297407 and redo it cleanly. Pointed out by: Jukka A. Ukkonen CID:1018720 MFC after: 1 week 297407 by pfg: freopen(3): prevent uninitialized errno. The case doesn't look very likely but clean the possibility nevertheless CID:1018720 MFC after: 1 week 297406 by np: Remove unnecessary dequeue_mutex (added in r294610) from the iWARP connection manager. Examining so_comp without synchronization with iw_so_event_handler is a harmless race. Submitted by: Krishnamraju Eraparaju @ Chelsio Reviewed by:Steve Wise @ Open Grid Computing Sponsored by: Chelsio Communications 297405 by adrian: [net80211] migrate the time_* macros to ieee80211_* namespace. It turns out that these will clash very annoyingly with the linux macros in the linuxkpi layer, so let the wookie^Wlinux win. The only user that I can find is ath(4), so fix it there too. 297404 by adrian: [net80211] Add fields to decode uAPSD fields. It turns out that madwifi actually has the basics for uAPSD implemented but it was never ported to FreeBSD. I may eventually port most of the pieces; I'll see how it goes! Obtained from: Madwifi 297403 by markj: Fix the lladdr copy in in6_lltable_dump_entry() after r292978. This bug caused "ndp -a" to show the wrong link layer address for neighbour cache entries. PR: 208067 297402 by pfg: Small typo. 297401 by kib: Do not access buffer if bread(9) or cluster_read(9) failed. On error, the functions free the buffer and set the pointer to NULL. Also remove useless call to brelse(9) on the error path. PR: 208275 Submitted by: Fabian Keil MFC after: 2 weeks 297400 by glebius: The sendfile(2) allows to send extra data from userspace before the file data (headers). Historically the size of the headers was not checked against the socket buffer space. Application could easily overcommit the socket buffer space. With the new sendfile (r293439) the problem remained, but a KASSERT was inserted that checked that amount of data written to the socket matches its space. In case when size of headers is bigger that socket space, KASSERT fires. Without INVARIANTS the new sendfile won't panic, but would report incorrect amount of bytes sent. o With this change, the headers copyin is moved down into the cycle, after the sbspace() check. The uio size is trimmed by socket space there, which fixes the overcommit problem and its consequences. o The compatibility handling for FreeBSD 4 sendfile headers API is pushed up the stack to syscall wrappers. This required a copy and paste of the code, but in turn this allowed to remove extra stack carried parameter from fo_sendfile_t, and embrace entire compat code into #ifdef. If in future we got more fo_sendfile_t function, the copy and paste level would even reduce. Reviewed by:emax, gallatin, Maxim Dounin Tested by: Vitalij Satanivskij Sponsored by: Netflix 297399 by kib: Type of the interrupt handlers on x86 cannot be expressed in C. Simplify and unify placeholder type definitions. Reviewed by:jhb Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D5771 297398 by kib: Fix several bugs in r297374: - fix UP build [1] - do not obliterate initial reading of rdtsc by the loop counter [2] - restore the meaning of the argument -1 to native_lapic_ipi_wait() as wait until LAPIC acknowledge without timeout - correct formula for calculating loop iteration count for 1us, it was inverted, and ensure that even on unlikely slow CPUs at least one check for ack is performed. Reported by:Michael Butler [1], rpokala[2], jhb[3] Tested by: Michael Butler Pointy hat to: kib Sponsored by: The FreeBSD Foundation 297397 by markj: Modify nd6_llinfo_timer() to acquire the nd6 lock before the LLE lock. When expiring a neighbour cache entry we may need to look up the associated default router, which requires the nd6 read lock. To avoid an LOR, the nd6 lock should be acquired first. X-MFC-With: r296063 Tested by: Larry Rosenman (previous revision) 297396 by mav: Modify "4958 zdb trips assert on pools with ashift >= 0xe". Unlike Illumos FreeBSD has concept of logical ashift, that specifies really minimal vdev block size that can be accessed. This knowledge allows properly pad physical I/O and correctly assert its alignment. This change fixes L2ARC write errors when device has logical sector size above 512 bytes. MFC after: 1 month
Re: HEAD does not build bwn (after r297405 ?)
On Wed, Mar 30, 2016 at 2:06 PM, Rainer Hurling wrote: > If I try to build most recent HEAD (r297407), I get the following error: > > I suspect r297405 with its migration of time_* macros to be the reason? > > Adrian Chadd fixed that in r297409. -Jia-Shiun. ___ 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: Add USB product id for i-tec USB 2.0 Docking Station
Hi, Am Mittwoch, 30. März 2016 12:21 CEST, Kurt Jaeger schrieb: > Hi! > > > > in mid 2015 I did submit a patch[1] to add an USB product ID to > > > improve the out-of-the-box experience for owners of i-tec USB 2.0 > > > Docking Stations. As there is no state change on the report since > > > then, I am wondering if I did address this the wrong way. > > > > You did everything OK. > > hselasky committed the fix to HEAD (thanks!) > > There's one thing you could have done earlier in the release cycle > for 10.3: Nudge on -current or -stable about the PR so that > it can still be put into 10.3. I think it will be too late for 10.3 now 8-( Thanks, I will followup earlier next time. Anyway - at the time I did the patch the udl driver was not existing in 10.x series. Best regards, Matthias ___ 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: Add USB product id for i-tec USB 2.0 Docking Station
Hi! > > in mid 2015 I did submit a patch[1] to add an USB product ID to > > improve the out-of-the-box experience for owners of i-tec USB 2.0 > > Docking Stations. As there is no state change on the report since > > then, I am wondering if I did address this the wrong way. > > You did everything OK. hselasky committed the fix to HEAD (thanks!) There's one thing you could have done earlier in the release cycle for 10.3: Nudge on -current or -stable about the PR so that it can still be put into 10.3. I think it will be too late for 10.3 now 8-( -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ 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: Add USB product id for i-tec USB 2.0 Docking Station
On 03/30/16 11:32, Kurt Jaeger wrote: Hi! in mid 2015 I did submit a patch[1] to add an USB product ID to improve the out-of-the-box experience for owners of i-tec USB 2.0 Docking Stations. As there is no state change on the report since then, I am wondering if I did address this the wrong way. You did everything OK. It just never found its way to a committer with time to test and commit. Please assign the PR to hselasky @ freebsd . org or send me a link. Thank you. --HPS ___ 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: Add USB product id for i-tec USB 2.0 Docking Station
Hi! > in mid 2015 I did submit a patch[1] to add an USB product ID to > improve the out-of-the-box experience for owners of i-tec USB 2.0 > Docking Stations. As there is no state change on the report since > then, I am wondering if I did address this the wrong way. You did everything OK. It just never found its way to a committer with time to test and commit. Hmm. -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ 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"
Add USB product id for i-tec USB 2.0 Docking Station
Hi, in mid 2015 I did submit a patch[1] to add an USB product ID to improve the out-of-the-box experience for owners of i-tec USB 2.0 Docking Stations. As there is no state change on the report since then, I am wondering if I did address this the wrong way. I'd appreciate of one of the developers could review the report and provide advise in case I did a mistake. Many thanks in advance & best regards, Matthias [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201084 ___ 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"
FreeBSD_HEAD_i386 - Build #2726 - Fixed
FreeBSD_HEAD_i386 - Build #2726 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2726/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2726/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2726/console Change summaries: 297409 by adrian: [bwn] fix time_before -> ieee80211_time_before() Noticed by: Jia-Shiun Li 297408 by pfg: freopen(3): prevent uninitialized errno. Revert r297407 and redo it cleanly. Pointed out by: Jukka A. Ukkonen CID:1018720 MFC after: 1 week ___ 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 slow and shaky network stability
On 29 Mar, To: ohart...@zedat.fu-berlin.de wrote: > On 28 Mar, Don Lewis wrote: >> On 28 Mar, O. Hartmann wrote: > >> If I get a chance, I try booting my FreeBSD 11 machine with less RAM to >> see if that is a trigger. > > I just tried cranking hw.physmen down to 8 GB on 11.0-CURRENT r297204, > GENERIC kernel. /boot/loader.conf contains: > geom_mirror_load="YES" > kern.geom.label.disk_ident.enable="0" > kern.geom.label.gptid.enable="0" > zfs_load="YES" > vboxdrv_load="YES" > hw.physmem="8G" > > /etc/sysctl.conf contains: > kern.ipc.shm_allow_removed=1 > > No /etc/src.conf and nothing of that should matter in /etc/make.conf. > > > This is what I see after running > poudriere ports -p whatever -u > > last pid: 2102; load averages: 0.24, 0.52, 0.36up 0+00:06:54 > 14:13:51 > 52 processes: 1 running, 51 sleeping > CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > Mem: 95M Active, 20M Inact, 1145M Wired, 39K Buf, 5580M Free > ARC: 595M Total, 256M MFU, 248M MRU, 16K Anon, 14M Header, 78M Other > Swap: 40G Total, 40G Free > > No swap used, inactive memory low, no interactivity problems. Next I'll > try r297267, which is what I believe you are running. I scanned the > commit logs between r297204 and r297267 and didn't see anything terribly > suspicious looking. No problems here with r297267 either. I did a bunch of small poudriere runs since the system was first booted. Usable RAM is still dialed back to 8 GB. A bit of swap is in use, mostly because nginx, which has been unused since the system was booted, got swapped out. Inactive memory is low now that poudriere is done. last pid: 75471; load averages: 0.21, 0.15, 0.19up 0+07:36:07 00:24:00 50 processes: 1 running, 49 sleeping CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 5988K Active, 14M Inact, 2641M Wired, 41K Buf, 4179M Free ARC: 790M Total, 575M MFU, 169M MRU, 16K Anon, 9618K Header, 36M Other Swap: 40G Total, 50M Used, 40G Free Do you use tmpfs? Anything stored in there will get stashed in inactive memory and/or swap. ___ 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"
