please (re) test if_ath in -HEAD
Hi all, For those of you who are testing out my if_ath changes, I'd really appreciate it if you'd update to -HEAD and re-test. I've done a variety of changes to the radio setup and found/fixed a few bugs in the TX path. It's quite possible these have introduced regressions. I'd like to make sure that I haven't broken legacy (11abg) support in weird/wonderful ways. I'd also like to make sure that I haven't broken/changed the behaviour or performance of the NICs in any way. Please give things a good thrashing and let me know the results. I'm still working towards debugging and enabling basic 11n support, but I need to first make sure that I haven't broken legacy operation in any way. Thanks, Adrian ___ 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: Request for review/testing: switching the default installer
On 03/03/2011 02:22, Baptiste Daroussin wrote: While working on this maybe it would be interesting to now use makefs instead of mkisofs, making installer generation 100% self hosting. makefs has recently been updating to a recent version from netbsd and now support iso9660, I already managed to create bootable livecd with it. That would be very nice. There is a weird situation now where you can't do ISO creation within 'make release' without also building ports, which is a lot of overhead. I "solved" this problem by scripting the ISO creation as a separate step, but it felt kludgy to me. Another nice improvement in this space would be to be able to select the specific ISO(s) that you want to create. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: HEADS UP: ZFSv28 is in!
Alexander Leidinger wrote: > Quoting Fabian Keil (from Thu, 3 Mar > 2011 13:01:30 +0100): > > > Alexander Leidinger wrote: > > > >> On Mon, 28 Feb 2011 19:21:29 +0100 Fabian Keil > >> wrote: > >> > >> > Pawel Jakub Dawidek wrote: > >> > > >> > > I just committed ZFSv28 to HEAD. > >> > > >> > I updated the system without removing the tuning for ZFSv15 > >> > first, and somehow this completely messed up the performance. > >> > Booting the system took more than ten minutes and even once > >> > it was up it was next to unresponsive. > >> > > >> > I'm not sure which sysctl was to blame, but after removing > >> > all but vfs.zfs.arc_max="800M" and rebooting, the problem > >> > was gone. > >> > >> When you add the tuning back, does it take minutes again to boot? If > >> not, I assume it was cleaning up some leftovers the old version was not > >> able to cleanup. > > > > I haven't tried that yet, but as I didn't upgrade the system's > > storage pool I don't think ZFS is supposed to do any such clean-ups. > > AFAIK the new code knows how to remove some superfluous parts in your > pool (no matter at which version the pool is), which the old code just > skipped over. Such leftovers may not be in all pools, they show up > just in some use cases. For this reason I asked to verify by adding > the tuning back to this system (if possible). I don't have an exact list of sysctls I used earlier, but after commenting in all the zfs sysctls in loader.conf (some of which must have been commented out for quite some time) the problem was back. I interrupted the boot process after 14 minutes at which point the ezjail rc script was running for several minutes already, but still busy with the first jail. Usually this takes only a few seconds. The sysctls used were: #vfs.zfs.txg.timeout=5 Seems to be the default now. # vfs.zfs.zil_disable=1 No longer supported. # vfs.zfs.prefetch_disable=0 The default seems to be 1. # vfs.zfs.write_limit_override=15 Clearly the value makes no sense, so this may not have been active at the time of the update. I had a back-ported patch to add the sysctl, so at least in theory it should have caused problems with v15, too, unless there was a sanity check to ignore obviously incorrect values. The auto-tuned write-limit values are: vfs.zfs.write_limit_max: 258863616 vfs.zfs.write_limit_min: 33554432 # vfs.zfs.vdev.max_pending=15 The auto-tuned value is 10. vfs.zfs.arc_max="800M" # vfs.zfs.arc_min="500M" # vfs.zfs.vdev.cache.size="5M" The auto-tuned value is 10485760 which seems close enough. # vfs.zfs.txg.synctime=1 This sysctl doesn't seem to exist (anymore). #vfs.zfs.cache_flush_disable=1 The default is 0. # vfs.zfs.txg.write_limit_override=134217728 Doesn't seem to exist (anymore) either. #vfs.zfs.vdev.max_pending=2 #vfs.zfs.vdev.min_pending=1 The auto-tuned values are vfs.zfs.vdev.min_pending: 4 vfs.zfs.vdev.max_pending: 10 > If it is not a production-like system which does not accept downtime, > this verification consumes less resources than sending out a developer > hunting for a problem which may not even exist. It wasn't my intention to send anyone hunting. Fabian signature.asc Description: PGP signature
Re: /netflow.c:301: error: 'struct netflow' has no member named 'zone6'
On 03/03/11 17:25, O. Hartmann wrote: I get the shown error message while compiling a customized kernel since the last two days (/usr/src/ up to date). Is this an well known issue or is there something wrong with my config? Oliver /usr/src/sys/modules/netgraph/netflow/../../../netgraph/netflow/netflow.c: In function 'expire_flow': /usr/src/sys/modules/netgraph/netflow/../../../netgraph/netflow/netflow.c:286: error: 'struct netflow' has no member named 'zone6' /usr/src/sys/modules/netgraph/netflow/../../../netgraph/netflow/netflow.c:301: error: 'struct netflow' has no member named 'zone6' *** Error code 1 Stop in /usr/src/sys/modules/netgraph/netflow. *** Error code 1 Stop in /usr/src/sys/modules/netgraph. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/TELESTO. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Do not reply on this, sorry. Just one minute after I sent the message, there was an update that solved the problem. Oliver ___ 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"
/netflow.c:301: error: 'struct netflow' has no member named 'zone6'
I get the shown error message while compiling a customized kernel since the last two days (/usr/src/ up to date). Is this an well known issue or is there something wrong with my config? Oliver /usr/src/sys/modules/netgraph/netflow/../../../netgraph/netflow/netflow.c: In function 'expire_flow': /usr/src/sys/modules/netgraph/netflow/../../../netgraph/netflow/netflow.c:286: error: 'struct netflow' has no member named 'zone6' /usr/src/sys/modules/netgraph/netflow/../../../netgraph/netflow/netflow.c:301: error: 'struct netflow' has no member named 'zone6' *** Error code 1 Stop in /usr/src/sys/modules/netgraph/netflow. *** Error code 1 Stop in /usr/src/sys/modules/netgraph. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/TELESTO. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ 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: ZFSv28 is in!
On Thu, 3 Mar 2011, Fabian Keil wrote: When you add the tuning back, does it take minutes again to boot? If not, I assume it was cleaning up some leftovers the old version was not able to cleanup. I haven't tried that yet, but as I didn't upgrade the system's storage pool I don't think ZFS is supposed to do any such clean-ups. The new code likely does things like search for and reclaim leaked space. Older zfs versions had some some bugs which could result in failing to reclaim space after a large file is deleted. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.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: urtw0: could not allocate USB transfers
On 03/03/11 08:25 AM, Hans Petter Selasky wrote: > On Thursday 03 March 2011 14:07:52 Etienne Robillard wrote: > >> ieee80211_newstate_cb >> > Hi, > > I think the problem is in the ieee80211 layer not draining its taskqueues > properly and/or other activities. It crashes in USB because it is accessing > freed memory or NULL pointers most likely. > > --HPS > X-UID: 11309 > Status: > X-Keywords: > > Content-Length: 0 > > nice debugging! out of curiosity, what is OFDM and why is it faster than "unknown subtype" as when using rt2870 ? $ dmesg run0: <1.0> on usbus1 run0: MAC/BBP RT2872 (rev 0x0202), RF RT2720 (MIMO 1T2R), address 00:14:d1:67:a5:de run0: firmware RT2870 loaded run0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps run0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps t_delta 15.fd8648f984182166 too short wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: 00:14:d1:67:a5:de wlan0: link state changed to UP $ kldload /boot/kernel/ipfw.ko link_elf_obj: symbol in6_clearscope undefined linker_load_file: Unsupported file type wlan0: link state changed to DOWN wlan0: link state changed to UP $ ifconfig wlan0: flags=8843 metric 0 mtu 1500 ether 00:00:00:00:00:00 inet 192.168.0.101 netmask 0xff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet OFDM/12Mbps mode 11g status: associated ssid dlink2 channel 2 (2417 MHz 11g) bssid 00:00:00:00:00:00 country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60 protmode CTS wme Cheers! :) -- Etienne Robillard Company: Green Tea Hackers Club Occupation: Software Developer (and CEO) E-mail: e...@gthcfoundation.org Work phone: 450-936-2123 Website (Company): https://gthc.org/ Website (Blog): https://gthc.org/blog/ PGP public key fingerprint:F2A9 32EA 8E7C 460F 1728 A1A7 649C 7F17 A086 DDEC During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell If a free society cannot help the many who are poor, it cannot save the few who are rich. -- John F. Kennedy ___ 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: urtw0: could not allocate USB transfers
On Thursday 03 March 2011 14:07:52 Etienne Robillard wrote: > ieee80211_newstate_cb Hi, I think the problem is in the ieee80211 layer not draining its taskqueues properly and/or other activities. It crashes in USB because it is accessing freed memory or NULL pointers most likely. --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: urtw0: could not allocate USB transfers
On 03/03/11 06:42 AM, Hans Petter Selasky wrote: > On Thursday 03 March 2011 12:26:20 Etienne Robillard wrote: > >> On 03/03/11 02:45 AM, Hans Petter Selasky wrote: >> >> I forwarded this thread on -current. >> >> Please also find below a stack trace produced with option >> KDB_UNATTENDED for the rt28700 driver (if_rt28700). >> >> On another side note, I have not being able to load >> the runfw firmware module anymore after having updated >> the src tree for 8.2-STABLE ? >> >> $ sudo kldload /boot/kernel/runfw.ko >> kldload: can't load /boot/kernel/runfw.ko: Exec format error >> > Here is your real error in dmesg: > >> KLD runfw.ko: depends on firmware - not available or version mismatch >> linker_load_file: Unsupported file type >> > You need to kldload firmware.ko or make sure 'device firmware' is in > your kernel config. > Hi, Many thanks. This explains the change of behavior attempting to kldload runfw.ko without the firmware assist module. :) However I find strange that run(4) requires such a firmware to be preloaded when the rt2870 driver doesn't require it! Cheers, >>> Maybe that's due to a missing MODULE_DEPEND() line in the .c file of >>> urtw0. >>> >>> --HPS >>> >> Hi, >> >> Thanks for the input. I realize the urtw(4) and the pseudo rt2870 drivers >> may be missing a MODULE_DEPEND macro but this issue is not as annoying >> than the repeated page faults happening when the card is trying >> to reassociate itself with a router. >> > Hi, > > Could you re-point me at one of those page faults, like DDB backtrace? > > You are using 9-current? > > --HPS > > Hi, Thanks for the feedback. It seems to affect unconditionally at least run(4) and rt2870 which isn't in the src tree yet. I copy-paste below a full dmesg output showing the requested backtrace. Also on Linux, its possible to force modules using a external firmware to not being built as a module. Would it be possible to add a similar option to /etc/src.conf to prevent building modules requiring a external firmware such as run(4) when building the kernel ? Waiting on "WCTRL" with the following non-sleepable locks held: exclusive sleep mutex rt28700_com_loc (rt28700_com_loc) r = 0 (0xff8001466018) locked @ net80211/ieee80211_node.c:653 KDB: stack backtrace: #0 0x804e0da0 at kdb_backtrace+0x60 #1 0x804effec at _witness_debugger+0x2c #2 0x804f1672 at witness_warn+0x322 #3 0x8047a85d at _cv_wait+0x6d #4 0x80400e73 at usbd_do_request_flags+0x4f3 #5 0x8102e0cb at rt2870_io_vendor_req+0x9b #6 0x8102e232 at rt2870_io_mac_write_multi+0x52 #7 0x8102e2ac at rt2870_io_mac_write+0x1c #8 0x81032f2d at rt2870_newassoc+0x12d #9 0x805893d2 at sta_newstate+0x5a2 #10 0x81039a7d at rt2870_vap_newstate+0x4d #11 0x805817a1 at ieee80211_newstate_cb+0x161 #12 0x804eb6b7 at taskqueue_run_locked+0xb7 #13 0x804eb7a0 at taskqueue_thread_loop+0x50 #14 0x804906d5 at fork_exit+0x115 #15 0x8064bc4e at fork_trampoline+0xe Regards, -- Etienne Robillard Company: Green Tea Hackers Club Occupation: Software Developer (and CEO) E-mail: e...@gthcfoundation.org Work phone: 450-936-2123 Website (Company): https://gthc.org/ Website (Blog): https://gthc.org/blog/ PGP public key fingerprint:F2A9 32EA 8E7C 460F 1728 A1A7 649C 7F17 A086 DDEC During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell If a free society cannot help the many who are poor, it cannot save the few who are rich. -- John F. Kennedy ___ 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: ZFSv28 is in!
Quoting Fabian Keil (from Thu, 3 Mar 2011 13:01:30 +0100): Alexander Leidinger wrote: On Mon, 28 Feb 2011 19:21:29 +0100 Fabian Keil wrote: > Pawel Jakub Dawidek wrote: > > > I just committed ZFSv28 to HEAD. > > I updated the system without removing the tuning for ZFSv15 > first, and somehow this completely messed up the performance. > Booting the system took more than ten minutes and even once > it was up it was next to unresponsive. > > I'm not sure which sysctl was to blame, but after removing > all but vfs.zfs.arc_max="800M" and rebooting, the problem > was gone. When you add the tuning back, does it take minutes again to boot? If not, I assume it was cleaning up some leftovers the old version was not able to cleanup. I haven't tried that yet, but as I didn't upgrade the system's storage pool I don't think ZFS is supposed to do any such clean-ups. AFAIK the new code knows how to remove some superfluous parts in your pool (no matter at which version the pool is), which the old code just skipped over. Such leftovers may not be in all pools, they show up just in some use cases. For this reason I asked to verify by adding the tuning back to this system (if possible). If it is not a production-like system which does not accept downtime, this verification consumes less resources than sending out a developer hunting for a problem which may not even exist. Bye, Alexander. -- A short cut is the longest distance between two points. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: login.conf: maxproc does not work when command running from cron?
2011/3/3 Alex Keda : > 03.03.2011 11:52, Alex Keda пишет: >> >> I create login class: >> lissyara# grep id100 --after-context=7 /etc/login.conf >> id100:\ >> :coredumpsize=1:\ >> :cputime=60s:\ >> :maxproc=12:\ >> :openfiles=32:\ >> :priority=20:\ >> :tc=default: >> >> lissyara# > > another parameters (I test cputime, priority) work correct > Indeed. and I was able to reproduce it too, fyi. That doesn't really work because cron doesn't perform further fork()s after RLIMIT_NPROC limit is set, but it only exec() a task. E.g. my cron implementation used at work does an additional fork necessary for some teardown work thus it doesn't suffer from this problem. -- wbr, pluknet ___ 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: login.conf: maxproc does not work when command running from cron?
03.03.2011 15:11, Sergey Kandaurov пишет: 2011/3/3 Alex Keda: 03.03.2011 11:52, Alex Keda пишет: I create login class: lissyara# grep id100 --after-context=7 /etc/login.conf id100:\ :coredumpsize=1:\ :cputime=60s:\ :maxproc=12:\ :openfiles=32:\ :priority=20:\ :tc=default: lissyara# another parameters (I test cputime, priority) work correct Indeed. and I was able to reproduce it too, fyi. That doesn't really work because cron doesn't perform further fork()s after RLIMIT_NPROC limit is set, but it only exec() a task. it's not good. it's problem for some situations - hosting servers, etc... E.g. my cron implementation used at work does an additional fork necessary for some teardown work thus it doesn't suffer from this problem. what's your cron implementation? ___ 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: ZFSv28 is in!
Alexander Leidinger wrote: > On Mon, 28 Feb 2011 19:21:29 +0100 Fabian Keil > wrote: > > > Pawel Jakub Dawidek wrote: > > > > > I just committed ZFSv28 to HEAD. > > > > I updated the system without removing the tuning for ZFSv15 > > first, and somehow this completely messed up the performance. > > Booting the system took more than ten minutes and even once > > it was up it was next to unresponsive. > > > > I'm not sure which sysctl was to blame, but after removing > > all but vfs.zfs.arc_max="800M" and rebooting, the problem > > was gone. > > When you add the tuning back, does it take minutes again to boot? If > not, I assume it was cleaning up some leftovers the old version was not > able to cleanup. I haven't tried that yet, but as I didn't upgrade the system's storage pool I don't think ZFS is supposed to do any such clean-ups. I also don't see any similar issues when importing other v15 pools. Fabian signature.asc Description: PGP signature
Re: urtw0: could not allocate USB transfers
On Thursday, March 03, 2011 12:26:20 Etienne Robillard wrote: > On 03/03/11 02:45 AM, Hans Petter Selasky wrote: > > > I forwarded this thread on -current. > > Please also find below a stack trace produced with option KDB_UNATTENDED > for the rt28700 driver (if_rt28700). > > On another side note, I have not being able to load > the runfw firmware module anymore after having updated > the src tree for 8.2-STABLE ? > > $ sudo kldload /boot/kernel/runfw.ko > kldload: can't load /boot/kernel/runfw.ko: Exec format error > > >>> Here is your real error in dmesg: > >>> > KLD runfw.ko: depends on firmware - not available or version mismatch > linker_load_file: Unsupported file type > > >>> You need to kldload firmware.ko or make sure 'device firmware' is in your > >>> kernel config. > >>> > >> Hi, > >> > >> Many thanks. This explains the change of behavior attempting to kldload > >> runfw.ko > >> without the firmware assist module. :) > >> > >> However I find strange that run(4) requires such a firmware to be preloaded > >> when the rt2870 driver doesn't require it! > >> > >> Cheers, > >> > > > > Maybe that's due to a missing MODULE_DEPEND() line in the .c file of urtw0. > > > > --HPS > > > > > > Hi, > > Thanks for the input. I realize the urtw(4) and the pseudo rt2870 drivers > may be missing a MODULE_DEPEND macro but this issue is not as annoying > than the repeated page faults happening when the card is trying > to reassociate itself with a router. urtw(4) has no firmware, run(4) has the appropriate depend line. The rt2870 driver is not in-tree, contact the maintainter. > I also noticed the same (random) page faults with the run(4) driver as > well but since I don't use a driver > requiring a external firmware to be loaded, I would prefer fixing the > errors in the generic > wireless code happening unconditionally with run(4), rt2870, and > possibly urtw(4). Plus, > a external firmware seems not necessary for using at least the TEW-644UB > wireless adapter! You should by now have noticed that you can't use a Realtek driver with a Ralink chipset, or the other way around. So please stop calling both broken in one mail. Also, again, the rt2870 driver isn't in-tree, contact the maintainer. -- Bernhard ___ 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: urtw0: could not allocate USB transfers
On Thursday 03 March 2011 12:26:20 Etienne Robillard wrote: > On 03/03/11 02:45 AM, Hans Petter Selasky wrote: > I forwarded this thread on -current. > > Please also find below a stack trace produced with option > KDB_UNATTENDED for the rt28700 driver (if_rt28700). > > On another side note, I have not being able to load > the runfw firmware module anymore after having updated > the src tree for 8.2-STABLE ? > > $ sudo kldload /boot/kernel/runfw.ko > kldload: can't load /boot/kernel/runfw.ko: Exec format error > >>> > >>> Here is your real error in dmesg: > KLD runfw.ko: depends on firmware - not available or version mismatch > linker_load_file: Unsupported file type > >>> > >>> You need to kldload firmware.ko or make sure 'device firmware' is in > >>> your kernel config. > >> > >> Hi, > >> > >> Many thanks. This explains the change of behavior attempting to kldload > >> runfw.ko > >> without the firmware assist module. :) > >> > >> However I find strange that run(4) requires such a firmware to be > >> preloaded when the rt2870 driver doesn't require it! > >> > >> Cheers, > > > > Maybe that's due to a missing MODULE_DEPEND() line in the .c file of > > urtw0. > > > > --HPS > > Hi, > > Thanks for the input. I realize the urtw(4) and the pseudo rt2870 drivers > may be missing a MODULE_DEPEND macro but this issue is not as annoying > than the repeated page faults happening when the card is trying > to reassociate itself with a router. Hi, Could you re-point me at one of those page faults, like DDB backtrace? You are using 9-current? --HPS > > I also noticed the same (random) page faults with the run(4) driver as > well but since I don't use a driver > requiring a external firmware to be loaded, I would prefer fixing the > errors in the generic > wireless code happening unconditionally with run(4), rt2870, and > possibly urtw(4). Plus, > a external firmware seems not necessary for using at least the TEW-644UB > wireless adapter! > > Cheers, > > Etienne ___ 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: Can't update CLang-based system
On Mon, Feb 28, 2011 at 09:06, Dimitry Andric wrote:
> On 2011-02-28 04:30, Tim Kientzle wrote:
>>
>> I have a FreeBSD-CURRENT AMD64 system here that was last updated at
>> r215029.
>>
>> I'm trying to update it to r219079, but the build fails in lib/libz when
>> it tries to compile gvmat64.S. It looks like the Makefile here has a
>> workaround for clang on AMD64, but it doesn't seem to actually be working in
>> this case.
>
> For this to work, you must put the following fragment in /etc/make.conf,
> *not* in /etc/src.conf.
>
> .if !defined(CC) || ${CC} == "cc"
> CC=clang
> .endif
> .if !defined(CXX) || ${CXX} == "c++"
> CXX=clang++
> .endif
> # Don't die on warnings
> NO_WERROR=
> WERROR=
>
> The problem with src.conf is that is only read when make encounters a
> .include or statement, which usually is at
> the end of a Makefile. Thus, any checks done on ${CC} or ${CXX} in the
> beginning of a Makefile pick up only the default value.
Hi. This worked for me.
Thanks for your help
--
Marcelo Rossi
"This e-mail is provided "AS IS" with no warranties, and confers no rights."
"I have nothing against God, I just hate His fan club"
___
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: urtw0: could not allocate USB transfers
On 03/03/11 02:45 AM, Hans Petter Selasky wrote: > I forwarded this thread on -current. Please also find below a stack trace produced with option KDB_UNATTENDED for the rt28700 driver (if_rt28700). On another side note, I have not being able to load the runfw firmware module anymore after having updated the src tree for 8.2-STABLE ? $ sudo kldload /boot/kernel/runfw.ko kldload: can't load /boot/kernel/runfw.ko: Exec format error >>> Here is your real error in dmesg: >>> KLD runfw.ko: depends on firmware - not available or version mismatch linker_load_file: Unsupported file type >>> You need to kldload firmware.ko or make sure 'device firmware' is in your >>> kernel config. >>> >> Hi, >> >> Many thanks. This explains the change of behavior attempting to kldload >> runfw.ko >> without the firmware assist module. :) >> >> However I find strange that run(4) requires such a firmware to be preloaded >> when the rt2870 driver doesn't require it! >> >> Cheers, >> > > Maybe that's due to a missing MODULE_DEPEND() line in the .c file of urtw0. > > --HPS > > Hi, Thanks for the input. I realize the urtw(4) and the pseudo rt2870 drivers may be missing a MODULE_DEPEND macro but this issue is not as annoying than the repeated page faults happening when the card is trying to reassociate itself with a router. I also noticed the same (random) page faults with the run(4) driver as well but since I don't use a driver requiring a external firmware to be loaded, I would prefer fixing the errors in the generic wireless code happening unconditionally with run(4), rt2870, and possibly urtw(4). Plus, a external firmware seems not necessary for using at least the TEW-644UB wireless adapter! Cheers, Etienne -- Etienne Robillard Company: Green Tea Hackers Club Occupation: Software Developer (and CEO) E-mail: e...@gthcfoundation.org Work phone: 450-936-2123 Website (Company): https://gthc.org/ Website (Blog): https://gthc.org/blog/ PGP public key fingerprint:F2A9 32EA 8E7C 460F 1728 A1A7 649C 7F17 A086 DDEC During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell If a free society cannot help the many who are poor, it cannot save the few who are rich. -- John F. Kennedy ___ 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: Request for review/testing: switching the default installer
2011/3/3 Paul Schenkeveld : > On Wed, Mar 02, 2011 at 09:36:58AM -0600, Nathan Whitehorn wrote: >> On 02/28/11 09:20, John Baldwin wrote: >> > On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote: >> >> There are some changes to the distribution format involved in this >> >> patch, which are outlined below, and about which I would also appreciate >> >> feedback: >> >> - The src tree is not split up into pieces (e.g. ssbin) as with sysinstall >> > I would at least like to have src split up into two pieces: >> > >> > 1) would be equivalent of sbase and ssys of old distributions, so you could >> > choose to just install kernel sources along with the top-level Makefile >> > bits >> > to build kernels. I commonly install this subset on production machines >> > so I >> > can install a custom kernel in a pinch. >> > >> > 2) would be everything else in the source tree. >> >> This is a little bit tricky, since it involves inter-distribution >> dependencies which don't currently exist (e.g. you need sbase for ssys >> to be useful, and for severythingelse to be useful). I suppose that the >> top-level Makefile bits are small and could end up in both archives, >> where one can overwrite the other with the same thing. Would that solve >> your problem? >> -Nathan > > Why not put the toplevel Makefiles, README and perhaps COPYRIGHT and > MAINTAINERS file into base? This way there are no inter-dependencies > between src parts, /usr/src will consume only a modest bit of space > in base but documents wat ont would be able to do is sbase/ssys were > installed. > > Regards, > > Paul Schenkeveld > ___ > freebsd-a...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscr...@freebsd.org" > While working on this maybe it would be interesting to now use makefs instead of mkisofs, making installer generation 100% self hosting. makefs has recently been updating to a recent version from netbsd and now support iso9660, I already managed to create bootable livecd with it. regards, Bapt ___ 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: login.conf: maxproc does not work when command running from cron?
03.03.2011 11:52, Alex Keda пишет: I create login class: lissyara# grep id100 --after-context=7 /etc/login.conf id100:\ :coredumpsize=1:\ :cputime=60s:\ :maxproc=12:\ :openfiles=32:\ :priority=20:\ :tc=default: lissyara# another parameters (I test cputime, priority) work correct ___ 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: Request for review/testing: switching the default installer
On Wed, Mar 02, 2011 at 09:36:58AM -0600, Nathan Whitehorn wrote: > On 02/28/11 09:20, John Baldwin wrote: > > On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote: > >> There are some changes to the distribution format involved in this > >> patch, which are outlined below, and about which I would also appreciate > >> feedback: > >> - The src tree is not split up into pieces (e.g. ssbin) as with sysinstall > > I would at least like to have src split up into two pieces: > > > > 1) would be equivalent of sbase and ssys of old distributions, so you could > > choose to just install kernel sources along with the top-level Makefile bits > > to build kernels. I commonly install this subset on production machines so > > I > > can install a custom kernel in a pinch. > > > > 2) would be everything else in the source tree. > > This is a little bit tricky, since it involves inter-distribution > dependencies which don't currently exist (e.g. you need sbase for ssys > to be useful, and for severythingelse to be useful). I suppose that the > top-level Makefile bits are small and could end up in both archives, > where one can overwrite the other with the same thing. Would that solve > your problem? > -Nathan Why not put the toplevel Makefiles, README and perhaps COPYRIGHT and MAINTAINERS file into base? This way there are no inter-dependencies between src parts, /usr/src will consume only a modest bit of space in base but documents wat ont would be able to do is sbase/ssys were installed. Regards, Paul Schenkeveld ___ 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"
login.conf: maxproc does not work when command running from cron?
I create login class: lissyara# grep id100 --after-context=7 /etc/login.conf id100:\ :coredumpsize=1:\ :cputime=60s:\ :maxproc=12:\ :openfiles=32:\ :priority=20:\ :tc=default: lissyara# then, run command: lissyara# cap_mkdb -v /etc/login.conf cap_mkdb: 10 capability records lissyara# add user: lissyara# grep ^test1234 /etc/master.passwd test1234:$1$kj/WOTuN$vLGcOBPv9ro8eljOe.ChA1:1002:1004:id100:0:0:User &:/home/test1234:/bin/sh lissyara# add cron job for user: lissyara# crontab -l -u test1234 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 lissyara# after some time I see lot sleep processes in ps output lissyara# ps -auxww | grep ^test1234 | grep sleep | wc -l 130 lissyara# 130 > 12 If I running commands from ssh session - all OK, I cannot run more than maxproc processes... tested on 8.1 (i386), 8.2 (i386), -CURRENT (amd64) ___ 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: Request for review/testing: switching the default installer
In article <4d6e6c43.4010...@freebsd.org> Nathan Whitehorn writes: >> Do you have a plan to add a floppy support as boot device? Pc98 >> machines which can boot from CD-ROM are very limited. So we usually >> use FD for boot media to install. > > No, I hadn't thought about this. If there aren't any machines you care > about that don't have a CD drive at all, we could try a > CD-bootloader-on-a-floppy as a solution. I think a totally floppy > based install would be very difficult to arrange, however. The boot-only-floppy image is very useful for us. --- TAKAHASHI Yoshihiro ___ 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"
