Re: About 32bit binary on amd64
Kostik Belousov kostik...@gmail.com writes:
On Mon, May 24, 2010 at 06:58:56PM +0900, Kohji Okuno wrote:
Thank you for your comments.
In my usage, it works good by the patch appended to this mail.
The patch is probably a start in the right direction. But, it would be
much better to install sys/i386/include to e.g. /usr/include/machine32
and use the pristine i386 files instead of copying them.
I think it'd be much easier to use smth like /usr/include/i386/machine.
So one can shadow /usr/include/machine from cc/c++ wrapper.
#! /bin/sh
skip-path() {
local IFS=:
PATH=$(for p in $PATH; do
case $p in
$1) ;;
*) echo -n $p: ;;
esac
done)
}
skip-path *${0%/*}
exec ${0##*/} -m32 -B/usr/lib32 -isystem/usr/include/i386 $@
Tested only on simple ports like lang/python26 with no deps, e.g.
# here you should put above cc/c++ wrapper into ~/.wrap32/cc
$ (cd ~/.wrap32; for f in c++ gcc g++; do ln -s cc $f; done)
$ export PATH=$HOME/.wrap32:$PATH
$ cd lang/python26
$ make install
Are you interested in going further with the approach ?
___
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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message From: Hans Petter Selasky hsela...@c2i.net To: freebsd-current@freebsd.org Cc: PseudoCylon moonlightak...@yahoo.ca; Ganbold Tsagaankhuu ganb...@mobicom.mn; Ganbold ganb...@gmail.com Sent: Tue, July 6, 2010 12:54:31 AM Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless Hello PseudoCylon is here. Unfortunately it successfully associates without an error. Hi, PseudoCylon: Can you try to reproduce this: 1) Setup OPEN HOST AP (ssid = xxx). 2) Configure WLAN client with: ssid=xxx auth_alg=SHARED key_mgmt=NONE Wait until wpa_cli announces that it tries to associate, but fails. This didn't happen. wpa_cli didn't say anything, just keep re-scanning. There was a change in wpa. So, I'll rebuilt world and retry 3) Then update wpa_supplicant.conf: ssid=xxx auth_alg=OPEN key_mgmt=NONE 4) Enter: reconfigure in wpa_cli (panic should happen shortly due to callback from IEEE802.11 layer which appears to refer a NULL pointer). --HPS For now, do you have any error message? And, are you using committed version of the driver or testing the patch? AK ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
On Wednesday 07 July 2010 12:49:37 PseudoCylon wrote: - Original Message From: Hans Petter Selasky hsela...@c2i.net To: freebsd-current@freebsd.org Cc: PseudoCylon moonlightak...@yahoo.ca; Ganbold Tsagaankhuu ganb...@mobicom.mn; Ganbold ganb...@gmail.com Sent: Tue, July 6, 2010 12:54:31 AM Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless Hello PseudoCylon is here. Unfortunately it successfully associates without an error. Hi, PseudoCylon: Can you try to reproduce this: 1) Setup OPEN HOST AP (ssid = xxx). 2) Configure WLAN client with: ssid=xxx auth_alg=SHARED key_mgmt=NONE Wait until wpa_cli announces that it tries to associate, but fails. This didn't happen. wpa_cli didn't say anything, just keep re-scanning. There was a change in wpa. So, I'll rebuilt world and retry 3) Then update wpa_supplicant.conf: ssid=xxx auth_alg=OPEN key_mgmt=NONE 4) Enter: reconfigure in wpa_cli (panic should happen shortly due to callback from IEEE802.11 layer which appears to refer a NULL pointer). --HPS For now, do you have any error message? And, are you using committed version of the driver or testing the patch? Hi, I tested using the RUM driver in 9-current. I will try to collect some more details on the panic. I think that RUN is also affected. --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: deadlkres() panic
2010/7/1 Bryan Venteicher bry...@daemoninthecloset.org: On a recent -current, I got the following panic from deadlkres: Assertion wchan != NULL failed at /usr/src-nfs/sys/kern/subr_sleepqueue.c:680 Tracing pid 0 tid 100058 td 0xff00024bf7a0 kdb_enter() at kdb_enter+0x3d panic() at panic+0x176 sleepq_type() at sleepq_type+0x56 deadlkres() at deadlkres+0x224 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8074976d30, rbp = 0 --- (Hand transcribed, doadump() hung) deadlkres() came across a TD_IS_SLEEPING()'ing thread that was not a sleepqueue (ie, td-td_wchan == NULL). I don't think this is an invalid state for thread to be in: After adding itself to a sleepq and setting a timeout, the thread calls sleepq_timedwait_sig(). sleepq_catch_signals() determines there is a signal pending so it removes the thread from the sleepq via sleepq_resume_thread(). Returning to sleepq_timedwait_sig(), in the call to sleepq_check_timeout(), the thread is unable to cancel the timeout because it is already firing (likely waiting on thread_lock()). So the thread calls TD_SET_SLEEPING() followed by mi_switch(). deadlkres() then picks up thread_lock(), finding td is TD_IS_SLEEPING() !TD_ON_SLEEPQ(). The attached patch takes care of the panic for me. I think that your analysis and patch are both fine and are committed, along with a small cleanup, as r209761. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: deadlkres() panic
On Wed, Jul 7, 2010 at 14:01, Attilio Rao atti...@freebsd.org wrote: 2010/7/1 Bryan Venteicher bry...@daemoninthecloset.org: On a recent -current, I got the following panic from deadlkres: Assertion wchan != NULL failed at /usr/src-nfs/sys/kern/subr_sleepqueue.c:680 Tracing pid 0 tid 100058 td 0xff00024bf7a0 kdb_enter() at kdb_enter+0x3d panic() at panic+0x176 sleepq_type() at sleepq_type+0x56 deadlkres() at deadlkres+0x224 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8074976d30, rbp = 0 --- (Hand transcribed, doadump() hung) deadlkres() came across a TD_IS_SLEEPING()'ing thread that was not a sleepqueue (ie, td-td_wchan == NULL). I don't think this is an invalid state for thread to be in: After adding itself to a sleepq and setting a timeout, the thread calls sleepq_timedwait_sig(). sleepq_catch_signals() determines there is a signal pending so it removes the thread from the sleepq via sleepq_resume_thread(). Returning to sleepq_timedwait_sig(), in the call to sleepq_check_timeout(), the thread is unable to cancel the timeout because it is already firing (likely waiting on thread_lock()). So the thread calls TD_SET_SLEEPING() followed by mi_switch(). deadlkres() then picks up thread_lock(), finding td is TD_IS_SLEEPING() !TD_ON_SLEEPQ(). The attached patch takes care of the panic for me. I think that your analysis and patch are both fine and are committed, along with a small cleanup, as r209761. Thank you both, I guess a had that panic a few days ago. Updating right now. ___ 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: [CFT] ZFS v15 patch (version 3)
Hi Martin, 2010/7/5 Martin Matuska m...@freebsd.org: Dear FreeBSD community, there has been a ZFS-related discussion at the meetBSD conference in Krakow, Poland and we agreed to push ZFS version 15 (and not 16) to -CURRENT. This is great news! Sorry for the newbie question but does this mean it will be in 8.1 Release? -- - Patrick Donnelly ___ 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: [CFT] ZFS v15 patch (version 3)
On Wed, Jul 7, 2010 at 8:28 AM, Patrick Donnelly batr...@batbytes.com wrote: Hi Martin, 2010/7/5 Martin Matuska m...@freebsd.org: Dear FreeBSD community, there has been a ZFS-related discussion at the meetBSD conference in Krakow, Poland and we agreed to push ZFS version 15 (and not 16) to -CURRENT. This is great news! Sorry for the newbie question but does this mean it will be in 8.1 Release? Highly unlikely :( -Brandon ___ 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: [CFT] ZFS v15 patch (version 3)
On 07/05/2010 07:50, Martin Matuska wrote: Direct link to the patch: http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.patch For full operation (commands zfs allow, unallow, userspace, grouspace) the python port must be installed, otherwise these comands don't work or have only limited functionality. The port will be added to the ports tree soon, you can download it from: http://people.freebsd.org/~mm/patches/zfs/v15/sysutils_py-zfs.tar.gz It should be worth noting for those that have been using the v16 patch in the previous v16 CFT that have installed this port and are downgrading their system to v15 that they will have to recompile the port once the downgrade is complete otherwise this will end up in a Segmentation fault when (zfs [allow/unallow/groupspace/userspace]) is run. I would be very grateful for testing on different architectures, mainly on amd64, i386 and sprarc. Martin, *** The above python port calls /usr/lib/zfs/pyzfs.py which is installed from /usr/src/cddl/contrib/opensolaris/cmd/pyzfs.py that has the following bang line for both the noted files. #! /usr/bin/python2.4 -S Could this be changed to: #! /usr/bin/env python -S *** I think since the integration of python for use with ZFS commands has worked its way in it might just be worth STRONGLY noting somewhere that python is now heavily depended on for these functions. As for stable/8 i386, ZFSv15 has been stable as a rock. I was running v16 with no problems but since it seems unlikely that v16 will make it down to stable/8 I downgraded to v15 on revision 209732. As for the python testing I am still a little bit shaky with but getting used to it. If there is more information that I can provide you with for i386 please let me know or Ill write back with anything if something should arise. Regards Thanks for the great work on this. -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ 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: [CFT] ZFS v15 patch (version 3)
On Wed, Jul 7, 2010 at 6:28 AM, Patrick Donnelly batr...@batbytes.com wrote: Hi Martin, 2010/7/5 Martin Matuska m...@freebsd.org: Dear FreeBSD community, there has been a ZFS-related discussion at the meetBSD conference in Krakow, Poland and we agreed to push ZFS version 15 (and not 16) to -CURRENT. This is great news! Sorry for the newbie question but does this mean it will be in 8.1 Release? No, 8.1-R is close to release so it's too late (normally no new features would be added after the first release candidate so we can have things tested more throughly). A patch will be provided but it's intended for users who are willing to maintain the code and can't wait for 8.2-RELEASE. Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ 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: [CFT] ZFS v15 patch (version 3)
On 07/07/2010 09:28, Patrick Donnelly wrote: Hi Martin, 2010/7/5 Martin Matuska m...@freebsd.org: Dear FreeBSD community, there has been a ZFS-related discussion at the meetBSD conference in Krakow, Poland and we agreed to push ZFS version 15 (and not 16) to -CURRENT. This is great news! Sorry for the newbie question but does this mean it will be in 8.1 Release? You can use this patch: http://people.freebsd.org/~mm/patches/zfs/v15/stable-209274.patch This port http://people.freebsd.org/~mm/patches/zfs/v15/sysutils_py-zfs.tar.gz To upgrade your 8.1-RC2 install to v15 if needed. Please re-read Martin's message for information about the revision needed before the patch. As in a previous message to the lists I have found this to be just as stable as v14 and better than v13 but you will want to have backups of your data or create your own ISO's after the patch has been applied until a snapshot has been made for stable/8 that you can use to recover/access a v15 zpool. Good Luck, -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ 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: [CFT] ZFS v15 patch (version 3)
We decided not to go with v16 - the feature difference for FreeBSD between v15 and v16 is zero. (v16 = Common Multiprotocol SCSI Target (COMSTAR) for ISCSI export of ZVOLS - we don't do ISCSI export (yet))// Of course v16 pools cannot be downgraded. But I provided the patch for testing only, not for production :-) You can consider the latest patch (v15 v3) to be more in direction production - it is much more complete and very closely follows Solaris 10. If someone strictly needs v16 (maybe because upgrading a pool) it is just a small patch to be added, I can provide it if requested. Dňa 7. 7. 2010 18:04, jhell wrote / napísal(a): On 07/05/2010 07:50, Martin Matuska wrote: Direct link to the patch: http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.patch For full operation (commands zfs allow, unallow, userspace, grouspace) the python port must be installed, otherwise these comands don't work or have only limited functionality. The port will be added to the ports tree soon, you can download it from: http://people.freebsd.org/~mm/patches/zfs/v15/sysutils_py-zfs.tar.gz It should be worth noting for those that have been using the v16 patch in the previous v16 CFT that have installed this port and are downgrading their system to v15 that they will have to recompile the port once the downgrade is complete otherwise this will end up in a Segmentation fault when (zfs [allow/unallow/groupspace/userspace]) is run. I would be very grateful for testing on different architectures, mainly on amd64, i386 and sprarc. Martin, *** The above python port calls /usr/lib/zfs/pyzfs.py which is installed from /usr/src/cddl/contrib/opensolaris/cmd/pyzfs.py that has the following bang line for both the noted files. #! /usr/bin/python2.4 -S Could this be changed to: #! /usr/bin/env python -S *** The python port (the one updated with v15-3) does install a pyzfs.py with a correct header, see the Makefile: http://people.freebsd.org/~mm/patches/zfs/v15/sysutils_py-zfs.tar.gz I will commit the python port to the ports tree right after it gets tagged, we are still having a discussion about it's versioning (maybe starting from 1.0?) I think since the integration of python for use with ZFS commands has worked its way in it might just be worth STRONGLY noting somewhere that python is now heavily depended on for these functions. The pythonized functions are: zfs allow/unallow (don't work without python), userspace/groupspace (limited functionality without python) As for stable/8 i386, ZFSv15 has been stable as a rock. I was running v16 with no problems but since it seems unlikely that v16 will make it down to stable/8 I downgraded to v15 on revision 209732. As for the python testing I am still a little bit shaky with but getting used to it. If there is more information that I can provide you with for i386 please let me know or Ill write back with anything if something should arise. What is going to happen, v15 goes to head next week with a 2-month MFC period. I will provide patches for stable/8 and 8.1-release. Regards Thanks for the great work on this. ___ 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: [CFT] ZFS v15 patch (version 3)
If the target is FreeBSD 9 instead of 8.1, why not merge ZFS v19? 15 really doesn't give any major enhancements over 14 and FreeBSD 9 isn't coming out any time. 19 would give much need log device removal and triple parity RAID-Z. Both of which are well tested at this point via OpenSolaris. -J 2010/7/5 Martin Matuska m...@freebsd.org: Dear FreeBSD community, there has been a ZFS-related discussion at the meetBSD conference in Krakow, Poland and we agreed to push ZFS version 15 (and not 16) to -CURRENT. An upgrade to version 16 gives us no valuable features (to be true, no features at all besides ability to import v16 pools). As ZFS v15 is already being used in the Solaris 10 enterprise world, we can consider it well-tested. The goal is to provide a filesystem compatible with Solaris 10 update 8, which may attract new users to FreeBSD. Existing users will get the userquota/groupquota features for ZFS and be able to import Solaris 10 update 8 pools. Import was done by walking through the path of bugfixes from Solaris 10, including pre-v15 bugfixes and almost all post-v15 bugfixes. Few patches are irrelevant to our code (Solaris-specific features) or modify the zvol part, these have been left out. I have prepared a new patch that includes almost all revision numbers Solaris 10 has integrated (we have several of the revisions already in our tree). Patch also includes updated manpages and may be considered as a candidate for head. Link to the patch information file, including all imported revisions, bug-ids and reference to Solairis 10 patch numbers: http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.html http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.txt Direct link to the patch: http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.patch The patch applies cleanly against head and stable/8. I am running a patched 8.1 (RC) without any problems so far. To patch 8.1 (RC), you need to apply revision 209274 from stable/8 before the patch: http://people.freebsd.org/~mm/patches/zfs/v15/stable-209274.patch For full operation (commands zfs allow, unallow, userspace, grouspace) the python port must be installed, otherwise these comands don't work or have only limited functionality. The port will be added to the ports tree soon, you can download it from: http://people.freebsd.org/~mm/patches/zfs/v15/sysutils_py-zfs.tar.gz For people just wanting to try the new features, I am providing mfsBSD ISO's with ZFS-on-root install (don't forget the -V 15 flag to the zfsinstall command): http://mfsbsd.vx.sk/iso/8.1rc2-zfsv15-v3.iso (without symbols, 99 MB) http://mfsbsd.vx.sk/iso/8.1rc2-zfsv15-v3-debug.iso (with symbols, 188 MB) I would be very grateful for testing on different architectures, mainly on amd64, i386 and sprarc. Thank you for testing! ___ 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: [CFT] ZFS v15 patch (version 3)
On Wed, Jul 7, 2010 at 1:25 PM, Jason J. W. Williams jasonjwwilli...@gmail.com wrote: If the target is FreeBSD 9 instead of 8.1, why not merge ZFS v19? 15 really doesn't give any major enhancements over 14 and FreeBSD 9 isn't coming out any time. 19 would give much need log device removal and triple parity RAID-Z. Both of which are well tested at this point via OpenSolaris. these are very valid points, but I am not sure that anyone has zfs v19 patches -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.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: [CFT] ZFS v15 patch (version 3)
Hello, . You wrote 7 июля 2010 г., 22:25:20: If the target is FreeBSD 9 instead of 8.1, why not merge ZFS v19? 15 really doesn't give any major enhancements over 14 and FreeBSD 9 isn't coming out any time. 19 would give much need log device removal and triple parity RAID-Z. Both of which are well tested at this point via OpenSolaris. Is here any ZFS history, in date - pool version - new features format? I understand, that it is more solaris-specific question, but I can not formulate request for Google to find out answer by myself :( -- // Black Lion AKA Lev Serebryakov l...@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: [CFT] ZFS v15 patch (version 3)
In the last episode (Jul 07), Lev Serebryakov said: You wrote 7 2010 ?., 22:25:20: If the target is FreeBSD 9 instead of 8.1, why not merge ZFS v19? 15 really doesn't give any major enhancements over 14 and FreeBSD 9 isn't coming out any time. 19 would give much need log device removal and triple parity RAID-Z. Both of which are well tested at this point via OpenSolaris. Is here any ZFS history, in date - pool version - new features format? http://hub.opensolaris.org/bin/view/Community+Group+zfs/nn where nn is the zpool version you want info on. This only tells you about changes to the physical filesystem format, though. Other bugfixes to the zfs codebase won't be listed here. You'd have to walk through the commit history at http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/ for that. -- Dan Nelson dnel...@allantgroup.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: [CFT] ZFS v15 patch (version 3)
http://docs.sun.com/app/docs/doc/819-5461/gjxle?l=ena=view 2010/7/7 Lev Serebryakov l...@freebsd.org: Hello, . You wrote 7 июля 2010 г., 22:25:20: If the target is FreeBSD 9 instead of 8.1, why not merge ZFS v19? 15 really doesn't give any major enhancements over 14 and FreeBSD 9 isn't coming out any time. 19 would give much need log device removal and triple parity RAID-Z. Both of which are well tested at this point via OpenSolaris. Is here any ZFS history, in date - pool version - new features format? I understand, that it is more solaris-specific question, but I can not formulate request for Google to find out answer by myself :( -- // Black Lion AKA Lev Serebryakov l...@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 ___ 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: [CFT] ZFS v15 patch (version 3)
Martin Matuska m...@freebsd.org writes: Hello, We decided not to go with v16 - the feature difference for FreeBSD between v15 and v16 is zero. (v16 = Common Multiprotocol SCSI Target (COMSTAR) for ISCSI export of ZVOLS - we don't do ISCSI export (yet))// Is there any hope to see COMSTAR in FreeBSD anytime soon ? Regards Éric Masson -- BJ Certes, la charte autorise de s'éloigner du sujet BJ en cours d'enfilade. Ça ne doit pas être très pratique. -+- MT in http://www.le-gnu.net : J'avance, tu recules -+- ___ 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
[panic] Race in IEEE802.11 layer towards device drivers
Hi, When supplying wpa_supplicant.conf with incorrect passwords, but a valid SSID, I have seen kernel panics several times when using USB based WLAN dongles. When only supplying a valid password, no panic has been seen. How to reproduce: 1) configure invalid password 2) wpa_cli: reconfigure 3) configure valid password 4) wpa_cli: reconfigure 5) goto 1 The USB commands which are executed inside the newstate callback usually take very little time, but still not as little time as PCI read/writes. I've forced slower operation in the newstate callback, and can reproduce warning printouts from the IEEE802.11 layer in FreeBSD. Try to apply the following patch to your USB code: http://p4web.freebsd.org/@@180604?ac=10 In my opinion the deferring of all states to a single task is wrong. There should be at least one task per possible state, and the queuing mechanism should follow the last-queued is last executed rule. This is not the case with the task-queue mechanism in the kernel. See the USB code's task-queue replacement which I think the IEEE802.11 stack in FreeBSD could take advantage of. src/sys/dev/usb/usb_process.c Description of panics. I didn't have core dump enabled on this box, so please bear over with the following hand-written notes: 1) A vap-iv_bss == NULL, inside ratectl task in RUM driver. 2) A memcpy() fails inside the iee80211...newstate_cb() 3) This and similar printouts are seen: wlan0: ieee80211_new_state_locked: pending AUTH - ASSOC transition lost --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: [CFT] ZFS v15 patch (version 3)
2010/7/5 Martin Matuska m...@freebsd.org:
Dear FreeBSD community,
there has been a ZFS-related discussion at the meetBSD conference in
Krakow, Poland and we agreed to push ZFS version 15 (and not 16) to
-CURRENT.
An upgrade to version 16 gives us no valuable features (to be true, no
features at all besides ability to import v16 pools).
As ZFS v15 is already being used in the Solaris 10 enterprise world, we
can consider it well-tested.
The goal is to provide a filesystem compatible with Solaris 10 update 8,
which may attract new users to FreeBSD.
Existing users will get the userquota/groupquota features for ZFS and be
able to import Solaris 10 update 8 pools.
Import was done by walking through the path of bugfixes from Solaris 10,
including pre-v15 bugfixes and almost all post-v15 bugfixes.
Few patches are irrelevant to our code (Solaris-specific features) or
modify the zvol part, these have been left out.
I have prepared a new patch that includes almost all revision numbers
Solaris 10 has integrated (we have several of the revisions already in
our tree).
Patch also includes updated manpages and may be considered as a
candidate for head.
Link to the patch information file, including all imported revisions,
bug-ids and reference to Solairis 10 patch numbers:
http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.html
http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.txt
Direct link to the patch:
http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.patch
The patch applies cleanly against head and stable/8.
using head from 3 hours ago, this patch does not apply cleanly
http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3-extension.patch
FNFS# cat sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c.rej
***
*** 529,540
if ((flag (FSYNC | FDSYNC)) (count == 1))
atomic_dec_32(zp-z_sync_cnt);
- /*
-* Clean up any locks held by this process on the vp.
-*/
- cleanlocks(vp, ddi_get_pid(), 0);
- cleanshares(vp, ddi_get_pid());
-
if (!zfs_has_ctldir(zp) zp-z_zfsvfs-z_vscan
ZTOV(zp)-v_type == VREG
!(zp-z_phys-zp_flags ZFS_AV_QUARANTINED)
--- 535,540
if ((flag (FSYNC | FDSYNC)) (count == 1))
atomic_dec_32(zp-z_sync_cnt);
if (!zfs_has_ctldir(zp) zp-z_zfsvfs-z_vscan
ZTOV(zp)-v_type == VREG
!(zp-z_phys-zp_flags ZFS_AV_QUARANTINED)
***
*** 1055,1060
acl_ids)) != 0)
goto out;
if (zfs_acl_ids_overquota(zfsvfs, acl_ids)) {
error = EDQUOT;
goto out;
}
--- 1101,1107
acl_ids)) != 0)
goto out;
if (zfs_acl_ids_overquota(zfsvfs, acl_ids)) {
+ zfs_acl_ids_free(acl_ids);
error = EDQUOT;
goto out;
}
***
*** 2208,2213
return (error);
}
if (zfs_acl_ids_overquota(zfsvfs, acl_ids)) {
zfs_dirent_unlock(dl);
ZFS_EXIT(zfsvfs);
return (EDQUOT);
--- 2243,2249
return (error);
}
if (zfs_acl_ids_overquota(zfsvfs, acl_ids)) {
+ zfs_acl_ids_free(acl_ids);
zfs_dirent_unlock(dl);
ZFS_EXIT(zfsvfs);
return (EDQUOT);
***
*** 3373,3382
if (attrzp)
VN_RELE(ZTOV(attrzp));
- if (aclp) {
zfs_acl_free(aclp);
- aclp = NULL;
- }
if (fuidp) {
zfs_fuid_info_free(fuidp);
--- 3412,3419
if (attrzp)
VN_RELE(ZTOV(attrzp));
+ if (aclp)
zfs_acl_free(aclp);
if (fuidp) {
zfs_fuid_info_free(fuidp);
FNFS#
--
Sam Fourman Jr.
Fourman Networks
http://www.fourmannetworks.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: [CFT] ZFS v15 patch (version 3)
Eric Masson schrieb: Martin Matuska m...@freebsd.org writes: We decided not to go with v16 - the feature difference for FreeBSD between v15 and v16 is zero. (v16 = Common Multiprotocol SCSI Target (COMSTAR) for ISCSI export of ZVOLS - we don't do ISCSI export (yet))// Is there any hope to see COMSTAR in FreeBSD anytime soon ? and Infiniband!? ___ 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: [CFT] ZFS v15 patch (version 3)
On 07/07/2010 14:20, Martin Matuska wrote: Of course v16 pools cannot be downgraded. But I provided the patch for testing only, not for production :-) You can consider the latest patch (v15 v3) to be more in direction production - it is much more complete and very closely follows Solaris 10. If someone strictly needs v16 (maybe because upgrading a pool) it is just a small patch to be added, I can provide it if requested. Sorry, should have been more clear. I downgraded the version in the kernel and the utilities/libs from v16 - v15 not the on disk versions. Regards, -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ 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] Race in IEEE802.11 layer towards device drivers
On 8 July 2010 07:13, Hans Petter Selasky hsela...@c2i.net wrote: Hi, When supplying wpa_supplicant.conf with incorrect passwords, but a valid SSID, I have seen kernel panics several times when using USB based WLAN dongles. When only supplying a valid password, no panic has been seen. How to reproduce: 1) configure invalid password 2) wpa_cli: reconfigure 3) configure valid password 4) wpa_cli: reconfigure 5) goto 1 The USB commands which are executed inside the newstate callback usually take very little time, but still not as little time as PCI read/writes. I've forced slower operation in the newstate callback, and can reproduce warning printouts from the IEEE802.11 layer in FreeBSD. Try to apply the following patch to your USB code: http://p4web.freebsd.org/@@180604?ac=10 In my opinion the deferring of all states to a single task is wrong. There should be at least one task per possible state, and the queuing mechanism should follow the last-queued is last executed rule. This is not the case with the task-queue mechanism in the kernel. You dont say why it should be this way, do you have an example of a problem this fixes? I think the single state thread is correct. The whole thing works on state transitions, you dont just set a state. Description of panics. I didn't have core dump enabled on this box, so please bear over with the following hand-written notes: 1) A vap-iv_bss == NULL, inside ratectl task in RUM driver. 2) A memcpy() fails inside the iee80211...newstate_cb() 3) This and similar printouts are seen: wlan0: ieee80211_new_state_locked: pending AUTH - ASSOC transition lost Can you see if you can get a core dump, or at least a DDB trace and the output from `show vap addr` Andrew ___ 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: [CFT] ZFS v15 patch (version 3)
05.07.2010 14:50, Martin Matuska пишет: Thank you for testing! FreeBSD open.vvnews.info 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #1: Wed Jul 7 14:12:05 UTC 2010 r...@open.vvnews.info:/usr/obj/usr/src/sys/SMP64R amd64 Jul 7 14:39:00 opensolaris kernel: device_attach: est1 attach returned 6 Jul 7 14:39:00 opensolaris kernel: p4tcc1: CPU Frequency Thermal Control on cpu1 Jul 7 14:39:00 opensolaris kernel: ZFS filesystem version 4 Jul 7 14:39:00 opensolaris kernel: ZFS storage pool version 15 Jul 7 14:39:00 opensolaris kernel: Timecounters tick every 1.000 msec Jul 7 14:39:00 opensolaris kernel: ncp_load: loaded # zpool status -v pool: zsolaris state: ONLINE scrub: scrub completed after 0h15m with 0 errors on Wed Jul 7 15:11:41 2010 config: NAME STATE READ WRITE CKSUM zsolaris ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 cache gpt/disk0ONLINE 0 0 0 errors: No known data errors Thanks! Work fine! -- Best regards, Andrei V. Lavreniyuk. ___ 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
