(no subject)
On Wed, Sep 24, 2008 at 09:32:52AM +1000, jonathan michaels wrote: > thank you gentle peoples for working out this solution. Unfortunately it has not been 'worked out' with the decision-makers. It has been suggested. Doing s/suggested/agreed to/ is not an automatic process. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7: buildworld failed with MODULES_WITH_WORLD=
On Wed, Sep 24, 2008 at 01:27:18AM +0800, Eugene Grosbein wrote: > I've just tried to build NanoBSD from 7.0-STABLE sources > with MODULES_WITH_WORLD knob enabled and it failed. > Note that NanoBSD uses make -j3 by default and I have dualcore system. > > ===> sys/modules/nfslockd (depend) > @ -> /usr/local/src/sys > machine -> /usr/local/src/sys/i386/include > echo "#define INET6 1" > opt_inet6.h > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h > rm -f .depend > mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I. -I@ > -I@/contrib/altq /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_clnt.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_server.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_svc.c > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_xdr.c > /usr/local/src/sys/modules/nfslockd/../../nlm/sm_inter_xdr.c > In file included from > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c:48: > @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory > In file included from > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c:56: > @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory > mkdep: compile failed > *** Error code 1 I see this problem was fixed in HEAD nearly month ago, but not in RELENG_7. Please perform MFC. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp multicast forwarding problems
On Tue, Sep 23, 2008 at 11:36:38AM -0700, Jack Vogel wrote: > LOL, sorry to disappoint you but I'm not responsible for fxp, Intel didn't > write > it, and i've never touched it :) Now that wouldnt mean that I can't look at > it, > but I am very busy right now, so unless there's no alternative I'd rather not. > > On Tue, Sep 23, 2008 at 3:06 AM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > On Tue, Sep 23, 2008 at 10:46:25AM +0100, Bruce M Simpson wrote: > >> Hi, > >> > >> Whilst doing some QA work on XORP on my desktop, which has fxp0 and > >> msk0, fxp0 got totally hosed. > >> I was running PIM-SM and IGMPv2 router-mode on the box at the time. > >> > >> I wonder if this is related to the problems with fxp multicast > >> transmission I saw back in April. > >> I'm a bit concerned about this as fxp is still a very widespread and > >> useful network chip. > >> > >> I am running 7.0-RELEASE-p4/amd64. > >> sysctls for dev.fxp.0 are set to their default values. > >> > >> I'm not expert on the fxp driver internals, but perhaps someone else has > >> seen this kind of problem before. Multicast-promiscuous mode (aka > >> ALLMULTI) was enabled on the interface. I know some NICs have problems > >> with this, or don't even support it. > >> > >> The errors look like this: > >> fxp0: SCB timeout: 0x10 0x0 0x80 0x0 > >> fxp0: SCB timeout: 0x10 0x0 0x80 0x0 > >> fxp0: DMA timeout > >> ... repeated ... > >> > >> Attempted workarounds which don't work to un-wedge the chip: > >> Reload the fxp0 microcode with "ifconfig fxp0 link0" > >> Forcibly unloading the kernel module and reloading it > >> Unpatching and repatching at the switch (a cheap 10/100 one) > >> Enabling and disabling promiscuous mode > >> Twiddling dev.fxp.0.noflow > >> > >> The link status looks fine, but the card will not send or receive traffic. > >> A warm reboot was enough to get things back up again. > >> > >> regards, > >> BMS > > > > Adding Jack Vogel, who's responsible for fxp(4). Ha, wow! I totally made the assumption you maintained fxp(4) based upon of em(4). Seemed logical, but once again, I failed the team. Regardless, thanks for looking into this when time permits. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proposed change to support policy for FreeBSD Releases
On Sep 23, 2008, at 4:45 PM, Colin Percival wrote: jonathan michaels wrote: On Tue, Sep 23, 2008 at 01:37:03PM -0700, Jo Rhett wrote: Some quite lively offline discussion has come to conclusion with the following suggestions to change the support policy. Obviously, this is what we feel would be a good idea, but it's obviously open to discussion and there's nobody demanding anything here. It just seems "better". Thanks for the suggestions, but it might have helped to avoid confusion if you had contacted the FreeBSD security team privately before announcing your ideas here... I'm sorry, I'm confused. This spawned from an ongoing conversation on this list. Rather than have the dialog spin around, I figured it would be better to post a specific example of what I thought. No it hasn't. The FreeBSD Security team hasn't agreed to anything yet. Yes, absolutely to that. As posted this is my own idea, adjusted some based on input from various others, none of whom are on the freebsd security team. I'd love to hear what the freebsd security team thinks. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proposed change to support policy for FreeBSD Releases
jonathan michaels wrote: On Tue, Sep 23, 2008 at 01:37:03PM -0700, Jo Rhett wrote: Some quite lively offline discussion has come to conclusion with the following suggestions to change the support policy. Obviously, this is what we feel would be a good idea, but it's obviously open to discussion and there's nobody demanding anything here. It just seems "better". Thanks for the suggestions, but it might have helped to avoid confusion if you had contacted the FreeBSD security team privately before announcing your ideas here... Final The final minor release on a given branch will be supported by the Security Officer for a minimum of 24 months after the release. thank you gentle peoples for working out this solution. it has given me some much needed clarity as regards forward moving planning. No it hasn't. The FreeBSD Security team hasn't agreed to anything yet. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proposed change to support policy for FreeBSD Releases
freebsd-stable et al ... On Tue, Sep 23, 2008 at 01:37:03PM -0700, Jo Rhett wrote: > Some quite lively offline discussion has come to conclusion with the > following suggestions to change the support policy. Obviously, this > is what we feel would be a good idea, but it's obviously open to > discussion and there's nobody demanding anything here. It just seems > "better". > > Old text: > > Each branch is supported by the Security Officer for a limited time o/ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ O\ whole heap of content sniped for brevity. > > a minimum of 24 months after the release. > > Proposed (starting point for discussion for) new text: > > Each branch is supported by the Security Officer for a limited time > only, and is designated as one of `Early adopter', `Normal', or > 'Final'. The designation is used as a guideline for determining the > lifetime of the branch as follows. > > Early adopter > Releases which are published from the -CURRENT branch will be for support of my hardware and any 'new' machines that might wander by .. i like these two definitions, the clarity of teh time line i mean, Early Adopter / Normal > Normal > Releases which are published from a -STABLE branch will be but, in particular i like this (Final) as a place to find some certainty and a place to plan the next step as regards freebsd upgrade path and future hardware acquisitions .. a safe place to plan and look froward from ... > Final > The final minor release on a given branch will be supported by > the Security Officer for a minimum of 24 months after the release. o/ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ O\ whole heap of contents sniped for brevity. thank you gentle peoples for working out this solution. it has given me some much needed clarity as regards forward moving planning. as well as looking to very clearly simplify the desicion making process as regards, not just, 'which freebsd to use' but when to move and what release to move to. as well as helping with the going forward hardware acquisions processes. not all gifts make good freebsd platforms. it helps to know with some kind of certainty wht hardware is being supported/worked on and still in pre-development stage so to speak. at any rate a good place to start with as regards this whole 'support' business .. makes sence to me .. thanks, gang. keep up teh good work .. very much appreciated most kind regards / appreciations. jonathan -- powered by .. QNX, OS9 and freeBSD -- http://caamora com au/operating system === appropriate solution in an inappropriate world === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-stable: a hung process - scheduler bug?
Robert Watson написав(ла): Sounds a lot like a lock leak/deadlock. Other than DDB output or a crashdump, which would allow us to explore some more, there's probably not much to be done with the box at this point other than reset. Sorry about that. Well, to reproduce you can try to build OpenOffice.org from any of the editors/openoffice.org-3-* ports. Set the environment variables MAXPROCESSES and MAXPROCS to the number of CPUs in your SMP-computer. Even if it does not hang like it did here, you may be able to observe the leak... Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible UDP deadlock/panic fix
On Tue, 23 Sep 2008, Mario Sergio Fujikawa Ferreira wrote: That seems to be working. I've been up and running for 7 hours now with your patch. The machine is a bit slow but I have both WITNESS and INVARIANTS enabled so as to make sure everything is fine. I've now merged the fix to stable/7, thanks to both of you for reporting the problem. Robert N M Watson Computer Laboratory University of Cambridge Rergads, Mario Robert Watson wrote: Attached is an MFC candidate for a patch I just merged to 8.x, which corrects the UDP lock recursion issue both of you were running into. If it settles well for a couple of days in HEAD then I'll go ahead and request an MFC from re@, but your confirmation as to whether or not this corrects the specific symptoms you are seeing would be very helpful. I was able to confirm that it eliminated what appeared to be the same problem here when I attempted to reproduce it based on the information you provided, so I'm hopeful.\ Thanks, Robert N M Watson Computer Laboratory University of Cambridge Property changes on: . ___ Modified: svn:mergeinfo Merged /head/sys:r183265 Index: netinet6/udp6_usrreq.c === --- netinet6/udp6_usrreq.c(revision 183265) +++ netinet6/udp6_usrreq.c(working copy) @@ -975,13 +975,23 @@ error = EINVAL; goto out; } + +/* + * XXXRW: We release UDP-layer locks before calling + * udp_send() in order to avoid recursion. However, + * this does mean there is a short window where inp's + * fields are unstable. Could this lead to a + * potential race in which the factors causing us to + * select the UDPv4 output routine are invalidated? + */ +INP_WUNLOCK(inp); +INP_INFO_WUNLOCK(&udbinfo); if (sin6) in6_sin6_2_sin_in_sock(addr); pru = inetsw[ip_protox[IPPROTO_UDP]].pr_usrreqs; -error = ((*pru->pru_send)(so, flags, m, addr, control, +/* addr will just be freed in sendit(). */ +return ((*pru->pru_send)(so, flags, m, addr, control, td)); -/* addr will just be freed in sendit(). */ -goto out; } } #endif ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-stable: a hung process - scheduler bug?
On Tue, 23 Sep 2008, Mikhail Teterin wrote: Robert Watson написав(ла): Could you try procstat -kk on the process, does that shed any light? When I was trying `procstat -k', I was getting the message: PIDTID COMM TDNAME KSTACK procstat: sysctl: kern.proc.kstack unavailable procstat: options DDB or options STACK required in kernel That was with a single `-k'. I can't do anything now, because -- after an attempt to start `systat 1 -vm' -- the system hosed and would not start new processes. The existing ones, such as the cvs-over ssh are stuck in: load: 0.00 cmd: ssh 59098 [proctree] 0.41u 0.17s 0% 0k Sounds a lot like a lock leak/deadlock. Other than DDB output or a crashdump, which would allow us to explore some more, there's probably not much to be done with the box at this point other than reset. Sorry about that. Robert N M Watson Computer Laboratory University of Cambridge___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-stable: a hung process - scheduler bug?
Robert Watson написав(ла): Could you try procstat -kk on the process, does that shed any light? When I was trying `procstat -k', I was getting the message: PIDTID COMM TDNAME KSTACK procstat: sysctl: kern.proc.kstack unavailable procstat: options DDB or options STACK required in kernel That was with a single `-k'. I can't do anything now, because -- after an attempt to start `systat 1 -vm' -- the system hosed and would not start new processes. The existing ones, such as the cvs-over ssh are stuck in: load: 0.00 cmd: ssh 59098 [proctree] 0.41u 0.17s 0% 0k Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming Releases Schedule...
John, we're already committed to upgrade to 6.3 (since it will currently be supported longer than 6.4). 6.2 support isn't part of this conversation, it has entirely revolved around support periods for upcoming releases. On Sep 23, 2008, at 1:10 PM, John Baldwin wrote: Jo, so it seems to me that you could just start by maintaining your own set of extended support patches for the FreeBSD releases you care about. I don't think you have to be a committer or secteam@ member to do this. It does mean that you might not be able to fix a bug in, say, 6.2 at the same exact time the advisory goes out at first, but you could take the patch from the advisory and apply it to your local 6.2 tree and then update your "cumulative patch" (would probably want to use some sort of source code control for this where you basically branch from FreeBSD X.Y where X.Y is a vendor branch of sorts). That would let you build the "street cred", as it were, to be able to get the patches directly into FreeBSD more easily. To start with it is probably going to be a bit slow as far as getting things committed directly to FreeBSD proper as it means finding a committer who has the time to test and review your patch and then commit it. However, the "Unofficial FreeBSD 6.2 Patchset" can be updated more quickly since it is something that would be under your control. Also, doing this will give you insight into exactly what is required to support a release after it is EOL'd in a much more direct fashion than an e-mail thread. -- John Baldwin -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-stable: a hung process - scheduler bug?
On Tue, 23 Sep 2008, Mikhail Teterin wrote: 37126 33012 8371 2425 2425 1 mi - FreeBSD ELF64 dmake PIDTID COMM TDNAME CPU PRI STATE WCHAN 37126 100724 dmake- 1 193 sleep - There are no problems ktrace-ing 33012, but nothing comes from there, as that process simply waits for its child. I guess, the child -- 37126 was (v)forked to launch a compiler or some such and remains stuck in between (v)fork and exec somewhere... (lots of details elided) Yes, there's a period during exec where attaching debuggers isn't allowed, so if something gets wedged or otherwise lost there, ktrace isn't much use. On the other hand, if it's stuck there, then there are no syscalls going on anyway. Could you try procstat -kk on the process, does that shed any light? Another alternative, if you have DDB compiled in, is to break to the debugger and do a stack trace, or to use gdb on /dev/mem if you have a kernel.symbols. This may help us understand more about what is going on. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
proposed change to support policy for FreeBSD Releases
Some quite lively offline discussion has come to conclusion with the following suggestions to change the support policy. Obviously, this is what we feel would be a good idea, but it's obviously open to discussion and there's nobody demanding anything here. It just seems "better". Old text: Each branch is supported by the Security Officer for a limited time only, and is designated as one of `Early adopter', `Normal', or `Extended'. The designation is used as a guideline for determining the lifetime of the branch as follows. Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. Extended Selected releases will be supported by the Security Officer for a minimum of 24 months after the release. Proposed (starting point for discussion for) new text: Each branch is supported by the Security Officer for a limited time only, and is designated as one of `Early adopter', `Normal', or 'Final'. The designation is used as a guideline for determining the lifetime of the branch as follows. Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. A release which is not the final minor release of a branch will be additionally supported by a minimum of 6 months past the release date of the succeeding version. For example X.1 will be supported for 12 months or until 6 months past the release date of X.2, whichever comes later. Final The final minor release on a given branch will be supported by the Security Officer for a minimum of 24 months after the release. OBSERVATIONS: 1. This avoids the need for the well-documented chicken-and-egg problem of trying to guess which release is the final release. 2. This is a consistent policy in line with many other vendor policies. 3. This rewards forward movement in the branch. And finally, as I've done the match carefully, 4. It would appear to *reduce* rather than enlarge the support requirements for the security team. Unless a minor release comes out less than 6 months after a previous release, only two versions would ever be supported at the same time. In recent history 3 minor releases in the same branch have been supported more often than not. Example under current policy: 6.5 comes out in July of 2009. For July -> October the security team will need to support 3 releases: 6.3, 6.4 and 6.5. From November 2009 through January 2010 the security team will need to support 6.3 and 6.5, but not 6.4. Revised under the existing policy: Support for 6.3 expires in April of 2009. (more than 12 months past release and 6 months after the release of 6.4). Support for 6.4 expires in January of 2010. Support for 6.5 would expire in July of 2011 or 6 months after the release of 6.6. ^NOTE: this example is probably unfeasible since 6.3 already has a published support period ended in January 2010, but this will prevent a similar occurrence happening in future releases. Note2: This new policy would not change the support period for 6.4 if it is the final release, but it does completely resolve the need to "guess" whether or not it will be the final release. The notable change that I believe will encourage business participation in the testing/evaluation process is that 6.4 is guaranteed to be supported either 24 months, or at least 6 months past the release date of 6.5. (recent history suggests this would be 15-19 months). This encourages businesses to test and evaluate 6.4 NOW, rather than waiting until a decision about the support policy is made. Repeat from the top: nobody is demanding anything. I think this policy would make a lot more sense, and would promote forward movement. Feel free to correct me if we overlooked anything. Thanks. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-stable: a hung process - scheduler bug?
On Tuesday 23 September 2008 02:25:05 pm Paul B. Mahol wrote: > > The OS is: FreeBSD 7.0-STABLE/amd64 from Sat Jul 26, 2008 and the box is > > otherwise perfectly functional. The scheduling-related options are set > > as such: > > > > options SCHED_4BSD # 4BSD scheduler > > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B > > real-time extensions > > > > Let me know, what else I can do to help fix this bug -- I'm going to > > reboot the machine tonight... Should I switch to SCHED_ULE as a > > work-around? > > SCHED_BSD4 is suboptimal for 4 CPUs, and it is replaced with SCHED_ULE > on 7 STABLE. SCHED_4BSD should still work fine. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7: something is very wrong with UDP?
On Saturday 20 September 2008 05:58:03 am Oleg V. Nauman wrote: > Quoting Robert Watson <[EMAIL PROTECTED]>: > >>> This is approximately the date of my last UDP MFC. Could you try > >>> backing out just src/sys/netinet6/udp6_usrreq.c revision 1.81.2.7 > >>> and see if that helps? (specifically, restore the use of > >>> sosend_generic instead of sosend_dgram) > > > > If you can show that it's definitely a problem with the change to > > sosend_dgram for UDPv6 socket send, then it might suggest it's the same > > problem that it is related to the UDPv46 code there. In which case I > > will propose we back out that portion of the change in the 7-stable > > branch until it's known to be resolved -- I don't want other people > > tripping over this. > > Sorry for false alarm regarding UDP issues.. Have noticed that my > clock is stop incrementing ( it explaining the zeroes in traceroute > output also ). It gave me idea what is related to this issue so > performed backout revision 1.243.2.4 of src/sys/dev/acpica/acpi.c and > it fixes my issues.. Looks like it stops incrementing the timecounters > on my laptop.. > Ironically speaking I was this ACPI behavior change initiator ( I was > reporting "ACPI HPET stops working on my RELENG_7" at July 19 to > [EMAIL PROTECTED]) so jhb@ implemented a patch and it was working for > me those days. Something was changed during the next 2 months so this > patch causing issues instead the success on my hardware. I will play a > bit with kern.timecounter.choice at Monday and report it back to jhb@ > then. The HPET is only used for "time of day". It does not drive the internal timers used by the kernel. If you find that the latest acpi.c makes a difference, you will need to start with before and after verbose dmesgs. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming Releases Schedule...
Jo, so it seems to me that you could just start by maintaining your own set of extended support patches for the FreeBSD releases you care about. I don't think you have to be a committer or secteam@ member to do this. It does mean that you might not be able to fix a bug in, say, 6.2 at the same exact time the advisory goes out at first, but you could take the patch from the advisory and apply it to your local 6.2 tree and then update your "cumulative patch" (would probably want to use some sort of source code control for this where you basically branch from FreeBSD X.Y where X.Y is a vendor branch of sorts). That would let you build the "street cred", as it were, to be able to get the patches directly into FreeBSD more easily. To start with it is probably going to be a bit slow as far as getting things committed directly to FreeBSD proper as it means finding a committer who has the time to test and review your patch and then commit it. However, the "Unofficial FreeBSD 6.2 Patchset" can be updated more quickly since it is something that would be under your control. Also, doing this will give you insight into exactly what is required to support a release after it is EOL'd in a much more direct fashion than an e-mail thread. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-stable: a hung process - scheduler bug?
> However, what I'm seeing on my system today is evidence of the scheduler > having a bug, rather than merely being suboptimal. If the old scheduler is > still maintained and supposed to work (however sub-optimally) in 4-CPU > configurations, I'd expect either inquiries for more debug-information or > assurances, that the bug is known and worked on. I'm no expert, but I don't think you can necessarily conclude that it is the scheduler yet. It very well may be, but I agree that someone with more expertise hopefully will ask for more detailed debug/trace information to pin down where the problem lies. > In the July 26th sys/conf/NOTES file the SCHED_BSD4 is still on the default > option GENERIC for i386 and amd64 has ULE as the default in RELENG_7. Regards, Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-stable: a hung process - scheduler bug?
Josh Carroll написав(ла): However, what I'm seeing on my system today is evidence of the scheduler having a bug, rather than merely being suboptimal. If the old scheduler is still maintained and supposed to work (however sub-optimally) in 4-CPU configurations, I'd expect either inquiries for more debug-information or assurances, that the bug is known and worked on. I'm no expert, but I don't think you can necessarily conclude that it is the scheduler yet. It very well may be, but I agree that someone with more expertise hopefully will ask for more detailed debug/trace information to pin down where the problem lies. Although the machine seemed fine, it would not launch new processes ever since I tried to start `systat 1 -vm' -- something systat does at start-up must've wedged the system... A process, that was running (cvs over ssh) is currently stuck (according to Ctrl-T) in: load: 0.00 cmd: ssh 59098 [proctree] 0.41u 0.17s 0% 0k I'll reboot it, when I get back home... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7: buildworld failed with MODULES_WITH_WORLD=
On Wed, Sep 24, 2008 at 02:14:01AM +0800, Eugene Grosbein wrote:
> On Wed, Sep 24, 2008 at 01:27:18AM +0800, Eugene Grosbein wrote:
>
> > I've just tried to build NanoBSD from 7.0-STABLE sources
> > with MODULES_WITH_WORLD knob enabled and it failed.
> > Note that NanoBSD uses make -j3 by default and I have dualcore system.
> >
> > ===> sys/modules/nfslockd (depend)
> > @ -> /usr/local/src/sys
> > machine -> /usr/local/src/sys/i386/include
> > echo "#define INET6 1" > opt_inet6.h
> > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p
> > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q
> > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h
> > rm -f .depend
> > mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I. -I@
> > -I@/contrib/altq /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c
> > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_clnt.c
> > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c
> > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_server.c
> > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_svc.c
> > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_xdr.c
> > /usr/local/src/sys/modules/nfslockd/../../nlm/sm_inter_xdr.c
> > In file included from
> > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c:48:
> > @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory
> > In file included from
> > /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c:56:
> > @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory
> > mkdep: compile failed
> > *** Error code 1
>
> This is easily repeatable without involving NanoBSD stuff,
> just with 'cd /usr/src; make -j3 MODULES_WITH_WORLD=yes buildworld'.
>
> I think this patch should be applied, at least it works for me:
>
> --- sys/modules/nfslockd/Makefile.orig2008-08-09 16:07:45.0
> +0800
> +++ sys/modules/nfslockd/Makefile 2008-09-24 02:02:23.0 +0800
> @@ -10,7 +10,7 @@
> nlm_prot_svc.c \
> nlm_prot_xdr.c \
> sm_inter_xdr.c
> -SRCS+= opt_inet6.h
> +SRCS+= opt_inet6.h opt_nfs.h
>
> .if !defined(KERNBUILDDIR)
> NFS_INET6?= 1 # 0/1 - requires INET6 to be configured in kernel
> @@ -19,6 +19,9 @@
> opt_inet6.h:
> echo "#define INET6 1" > ${.TARGET}
> .endif
> +
> +opt_nfs.h:
> + echo -n > ${.TARGET}
> .endif
>
> .include
First chunk of your patch was already committed by Paul Saab as r181040.
You may ask him to do MFC and merge second chunk, if needed.
pgpJTXKPbx1zP.pgp
Description: PGP signature
Re: fxp multicast forwarding problems
LOL, sorry to disappoint you but I'm not responsible for fxp, Intel didn't write it, and i've never touched it :) Now that wouldnt mean that I can't look at it, but I am very busy right now, so unless there's no alternative I'd rather not. Jack On Tue, Sep 23, 2008 at 3:06 AM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > On Tue, Sep 23, 2008 at 10:46:25AM +0100, Bruce M Simpson wrote: >> Hi, >> >> Whilst doing some QA work on XORP on my desktop, which has fxp0 and >> msk0, fxp0 got totally hosed. >> I was running PIM-SM and IGMPv2 router-mode on the box at the time. >> >> I wonder if this is related to the problems with fxp multicast >> transmission I saw back in April. >> I'm a bit concerned about this as fxp is still a very widespread and >> useful network chip. >> >> I am running 7.0-RELEASE-p4/amd64. >> sysctls for dev.fxp.0 are set to their default values. >> >> I'm not expert on the fxp driver internals, but perhaps someone else has >> seen this kind of problem before. Multicast-promiscuous mode (aka >> ALLMULTI) was enabled on the interface. I know some NICs have problems >> with this, or don't even support it. >> >> The errors look like this: >> fxp0: SCB timeout: 0x10 0x0 0x80 0x0 >> fxp0: SCB timeout: 0x10 0x0 0x80 0x0 >> fxp0: DMA timeout >> ... repeated ... >> >> Attempted workarounds which don't work to un-wedge the chip: >> Reload the fxp0 microcode with "ifconfig fxp0 link0" >> Forcibly unloading the kernel module and reloading it >> Unpatching and repatching at the switch (a cheap 10/100 one) >> Enabling and disabling promiscuous mode >> Twiddling dev.fxp.0.noflow >> >> The link status looks fine, but the card will not send or receive traffic. >> A warm reboot was enough to get things back up again. >> >> regards, >> BMS > > Adding Jack Vogel, who's responsible for fxp(4). > > -- > | Jeremy Chadwickjdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-stable: a hung process - scheduler bug?
On 9/23/08, Mikhail Teterin <[EMAIL PROTECTED]> wrote: > Hello! > > I was trying to build OpenOffice using all of my 4 CPUs. To be able to > do other work on the machine comfortably, I ran the build under nice, > and assigned real-time priority to the two Xorg processes. > The build started at about 23:10 last night, and hung at 23:46. The > procstat output for the make's process group is: > > PID PPID PGID SID TSID THR LOGINWCHAN EMUL > COMM > 8371 2425 8371 2425 2425 1 mi wait FreeBSD ELF64 make > 12254 8371 8371 2425 2425 1 mi wait FreeBSD ELF64 sh > 12255 12254 8371 2425 2425 1 mi pause FreeBSD ELF64 > tcsh > 12262 12255 8371 2425 2425 1 mi wait FreeBSD ELF64 > perl5.8.8 > 33010 12262 8371 2425 2425 1 mi wait FreeBSD ELF64 > perl5.8.8 > 33011 33010 8371 2425 2425 1 mi wait FreeBSD ELF64 sh > 33012 33011 8371 2425 2425 1 mi wait FreeBSD ELF64 dmake > 37126 33012 8371 2425 2425 1 mi - FreeBSD ELF64 dmake > > The last line worries me greatly... According to "procstat -t", there is > only one thread there: > > PIDTID COMM TDNAME CPU PRI STATE > WCHAN > 37126 100724 dmake- 1 193 sleep - > > And trying to "ktrace -p 37126" returns (even to root, even in /tmp): > > ktrace: ktrace.out: Operation not permitted > > There are no problems ktrace-ing 33012, but nothing comes from there, as > that process simply waits for its child. I guess, the child -- 37126 was > (v)forked to launch a compiler or some such and remains stuck in between > (v)fork and exec somewhere... > > The OS is: FreeBSD 7.0-STABLE/amd64 from Sat Jul 26, 2008 and the box is > otherwise perfectly functional. The scheduling-related options are set > as such: > > options SCHED_4BSD # 4BSD scheduler > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B > real-time extensions > > Let me know, what else I can do to help fix this bug -- I'm going to > reboot the machine tonight... Should I switch to SCHED_ULE as a > work-around? SCHED_BSD4 is suboptimal for 4 CPUs, and it is replaced with SCHED_ULE on 7 STABLE. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7: buildworld failed with MODULES_WITH_WORLD=
On Wed, Sep 24, 2008 at 01:27:18AM +0800, Eugene Grosbein wrote:
> I've just tried to build NanoBSD from 7.0-STABLE sources
> with MODULES_WITH_WORLD knob enabled and it failed.
> Note that NanoBSD uses make -j3 by default and I have dualcore system.
>
> ===> sys/modules/nfslockd (depend)
> @ -> /usr/local/src/sys
> machine -> /usr/local/src/sys/i386/include
> echo "#define INET6 1" > opt_inet6.h
> awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p
> awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q
> awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h
> rm -f .depend
> mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I. -I@
> -I@/contrib/altq /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c
> /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_clnt.c
> /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c
> /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_server.c
> /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_svc.c
> /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_xdr.c
> /usr/local/src/sys/modules/nfslockd/../../nlm/sm_inter_xdr.c
> In file included from
> /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c:48:
> @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory
> In file included from
> /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c:56:
> @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory
> mkdep: compile failed
> *** Error code 1
This is easily repeatable without involving NanoBSD stuff,
just with 'cd /usr/src; make -j3 MODULES_WITH_WORLD=yes buildworld'.
I think this patch should be applied, at least it works for me:
--- sys/modules/nfslockd/Makefile.orig 2008-08-09 16:07:45.0 +0800
+++ sys/modules/nfslockd/Makefile 2008-09-24 02:02:23.0 +0800
@@ -10,7 +10,7 @@
nlm_prot_svc.c \
nlm_prot_xdr.c \
sm_inter_xdr.c
-SRCS+= opt_inet6.h
+SRCS+= opt_inet6.h opt_nfs.h
.if !defined(KERNBUILDDIR)
NFS_INET6?=1 # 0/1 - requires INET6 to be configured in kernel
@@ -19,6 +19,9 @@
opt_inet6.h:
echo "#define INET6 1" > ${.TARGET}
.endif
+
+opt_nfs.h:
+ echo -n > ${.TARGET}
.endif
.include
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-stable: a hung process - scheduler bug?
Paul B. Mahol написав(ла): Let me know, what else I can do to help fix this bug -- I'm going to reboot the machine tonight... Should I switch to SCHED_ULE as a work-around? SCHED_BSD4 is suboptimal for 4 CPUs, and it is replaced with SCHED_ULE on 7 STABLE. Thanks, Paul for the explanation. I've heard of some problems still lingering in the ULE and figured, I'll stay with the BSD-scheduler for a while. I guess, it is time to switch. However, what I'm seeing on my system today is evidence of the scheduler having a bug, rather than merely being suboptimal. If the old scheduler is still maintained and supposed to work (however sub-optimally) in 4-CPU configurations, I'd expect either inquiries for more debug-information or assurances, that the bug is known and worked on. In the July 26th sys/conf/NOTES file the SCHED_BSD4 is still on the default option Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming Releases Schedule...
On Sep 23, 2008, at 12:45 AM, Ian Smith wrote: It also doesn't seem reasonable to expect that decision to be rushed in advance of the necessary evaluation of the success or otherwise of both 6.4 and 7.1 releases - especially when we're talking about these being only a month or so away anyway. Let me try to say this one other way. If you want businesses or anyone really who doesn't have unlimited time and energy to help evaluate, test, etc this release prior to it coming out, shouldn't you make it worth their while? Supporting 6.3 for longer than 6.4 doesn't make it worth anyone's time or attention to evaluate 6.4. Which means that it becomes significantly more likely that 6.4 will ship with a major problem that could or should have been caught in pre- release testing. The current policy of "not deciding until after the fact" for support periods could in fact be implemented with a reasonable policy that doesn't require a psychic to determine the likely failure or not of a release. I've proposed one. I'm sure that there are better ways to say it, but I'd really appreciate it if you guys would take the problem seriously. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming Releases Schedule...
On Sep 23, 2008, at 12:45 AM, Ian Smith wrote: I mean seriously, if you were to say "We will support 6.4 for 24 months *unless* we find it necessary to release 6.5 then I'd be totally happy. But that's not what is being said. I believe that's exactly what has been said. rwatson@ and simon@ have both made it exceedingly clear, to me anyway, that if 6.4 is to be the last release on the 6.x branch - as appears to be likely but cannot be stated definitely at this time, for reasons clearly given and understood - then it will indeed be supported for 24 months. It doesn't seem reasonable to expect 24 months stated support for 6.4 if it turns out not to be the last release - that would then apply to 6.5. Have you read any of the existing thread? Right now 6.4 will go out of support 3 months before 6.3. Which might or might not change at some point in the future. Isn't this obviously a fairly major problem for any business or even any person to want to spend any time to test/evaluate/etc 6.4? What I proposed in my message (which you completely ignored) was an incremental support policy that builds on each release, instead of actually promoting the idea of skipping releases. This may not be a good idea -- it was just a toss out there, but it makes a lot more sense than the existing policy. Could you at least respond to the issues raised here? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RELENG_7: buildworld failed with MODULES_WITH_WORLD=
Hi! I've just tried to build NanoBSD from 7.0-STABLE sources with MODULES_WITH_WORLD knob enabled and it failed. Note that NanoBSD uses make -j3 by default and I have dualcore system. ===> sys/modules/nfslockd (depend) @ -> /usr/local/src/sys machine -> /usr/local/src/sys/i386/include echo "#define INET6 1" > opt_inet6.h awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I. -I@ -I@/contrib/altq /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_clnt.c /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_server.c /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_svc.c /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_xdr.c /usr/local/src/sys/modules/nfslockd/../../nlm/sm_inter_xdr.c In file included from /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_advlock.c:48: @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory In file included from /usr/local/src/sys/modules/nfslockd/../../nlm/nlm_prot_impl.c:56: @/nfsclient/nfs.h:40:21: error: opt_nfs.h: No such file or directory mkdep: compile failed *** Error code 1 Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
7.0-stable: a hung process - scheduler bug?
Hello! I was trying to build OpenOffice using all of my 4 CPUs. To be able to do other work on the machine comfortably, I ran the build under nice, and assigned real-time priority to the two Xorg processes. The build started at about 23:10 last night, and hung at 23:46. The procstat output for the make's process group is: PID PPID PGID SID TSID THR LOGINWCHAN EMUL COMM 8371 2425 8371 2425 2425 1 mi wait FreeBSD ELF64 make 12254 8371 8371 2425 2425 1 mi wait FreeBSD ELF64 sh 12255 12254 8371 2425 2425 1 mi pause FreeBSD ELF64 tcsh 12262 12255 8371 2425 2425 1 mi wait FreeBSD ELF64 perl5.8.8 33010 12262 8371 2425 2425 1 mi wait FreeBSD ELF64 perl5.8.8 33011 33010 8371 2425 2425 1 mi wait FreeBSD ELF64 sh 33012 33011 8371 2425 2425 1 mi wait FreeBSD ELF64 dmake 37126 33012 8371 2425 2425 1 mi - FreeBSD ELF64 dmake The last line worries me greatly... According to "procstat -t", there is only one thread there: PIDTID COMM TDNAME CPU PRI STATE WCHAN 37126 100724 dmake- 1 193 sleep - And trying to "ktrace -p 37126" returns (even to root, even in /tmp): ktrace: ktrace.out: Operation not permitted There are no problems ktrace-ing 33012, but nothing comes from there, as that process simply waits for its child. I guess, the child -- 37126 was (v)forked to launch a compiler or some such and remains stuck in between (v)fork and exec somewhere... The OS is: FreeBSD 7.0-STABLE/amd64 from Sat Jul 26, 2008 and the box is otherwise perfectly functional. The scheduling-related options are set as such: options SCHED_4BSD # 4BSD scheduler options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions Let me know, what else I can do to help fix this bug -- I'm going to reboot the machine tonight... Should I switch to SCHED_ULE as a work-around? Thanks! Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming Releases Schedule...
On Tue, 23 Sep 2008, Ian Smith wrote: >On Mon, 22 Sep 2008, Jo Rhett wrote: > > I think you are using "last release" in a different way. "the last release" > > is always the most release release. Right now 6.3 will have support for > > longer than 6.4 will, which is the nature of the problem I raised. If you > > always supported the most recent release for 24 months then we wouldn't have > > any problem. > >Jo, it seems to be you who are trying to use "last" in an unusual way. >The "last release on a branch" is not the latest one, but the last one. >For 4.x that was .11 and for 5.x it was .5, where last means just that. Let's stop using the word "last" for the time being and instead circumvent the ambiguity via "previous" and "final", perhaps? Maybe if official documentation were updated to avoid this same ambiguity there'd be less misunderstanding too. -Derek. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible UDP deadlock/panic fix
On September 22, 2008, Robert Watson wrote: > your confirmation as to whether or not this corrects the > specific symptoms you are seeing would be very helpful. 14+ hours under load with the patch and all is well. Thanks! -- Norbert. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: iwn(4) (Intel 4965 wireless) backport
On Tue, 2008-09-23 at 16:08 +0300, Stefan Lambrev wrote: > Hi Gavin, > > Gavin Atkinson wrote: > > On Thu, 2008-09-04 at 18:48 +0100, Gavin Atkinson wrote: > > > >> On Thu, 2008-09-04 at 11:32 -0600, Dan Allen wrote: > >> > >>> On 4 Sep 2008, at 10:29 AM, Gavin Atkinson wrote: > >>> > >>> > This is supported by the iwn(4) driver in CURRENT, and it should be > quite easy to port the driver to 7-STABLE. If you're interested in > reinstalling FreeBSD and testing a backported driver, I'm sure this > can be sorted. > > >>> I am interested in doing this. Please advise on how I can get these > >>> bits. > >>> > >> I've got hold of a laptop with the 4965 chipset in it, if nobody beats > >> me to it I'll have a go at backporting the driver. > >> > > > > OK, I've backported the iwn(4) driver for the Intel 4965 wireless > > chipset to 7-STABLE. > > > > You need both of: > > http://people.freebsd.org/~gavin/iwn-7/iwn-7.tgz > > > Loading if_iwn.ko make a nice reboot on my laptop. > No messages just a reset... FreeBSD 7.0-STABLE #29: Tue Jul 29 16:13:47 > EEST 2008 i386 > May be I should try with more recent -stable ? Are you loading this while in X or on the console? If X, can you try from a console and see if anything else happens before the reboot (like a panic)? I don't believe there are any changes between 7.0 and stable that would result in a panic under an earlier version. You could try recompiling your kernel with "options GDB/KDB/DDB" and "makeoptions DEBUG=-g" and see if you get dropped to the debugger, if you do the result of the command "bt" would be very useful. Thanks, Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: iwn(4) (Intel 4965 wireless) backport
Hi Gavin, Gavin Atkinson wrote: On Thu, 2008-09-04 at 18:48 +0100, Gavin Atkinson wrote: On Thu, 2008-09-04 at 11:32 -0600, Dan Allen wrote: On 4 Sep 2008, at 10:29 AM, Gavin Atkinson wrote: This is supported by the iwn(4) driver in CURRENT, and it should be quite easy to port the driver to 7-STABLE. If you're interested in reinstalling FreeBSD and testing a backported driver, I'm sure this can be sorted. I am interested in doing this. Please advise on how I can get these bits. I've got hold of a laptop with the 4965 chipset in it, if nobody beats me to it I'll have a go at backporting the driver. OK, I've backported the iwn(4) driver for the Intel 4965 wireless chipset to 7-STABLE. You need both of: http://people.freebsd.org/~gavin/iwn-7/iwn-7.tgz Loading if_iwn.ko make a nice reboot on my laptop. No messages just a reset... FreeBSD 7.0-STABLE #29: Tue Jul 29 16:13:47 EEST 2008 i386 May be I should try with more recent -stable ? http://people.freebsd.org/~gavin/iwn-7/iwn-7.diff Both are relative to /usr and are against 7-STABLE (although may well apply to 7.0-RELEASE cleanly). Please note that there are a couple of issues with this driver that aren't seen with the driver in -HEAD. Firstly, it only supports B/G channels, it doesn't work with 802.11a. Apparently this is due to a firmware issue which the driver in -HEAD works around, although I don't know how yet. Secondly, there may be a slight issue with regulatory domains. I'm not certain about this, but I was seeing issues while trying to associate to an access point on channel 13g, changing the AP to channel 1g fixes things. Even with those two caveats, I can say that so far in my testing it's been working very well. However, even if the driver works for you, I'm pretty sure it's too late for a merge before 7.1. Lastly, as the laptop is on loan to me and I'm going to have to give it back soon, I don't know if I'll have a chance to do any further work on this driver. I'm still interested in stories of success or otherwise. Thanks, Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Announcement: PmcTools callchain capture for RELENG_7
Hello, A new patch is available that was done just after dtrace backport. You can find it like the previous one on the pmc wiki. It also include some new bugfix from head. Fabien Le 13 juil. 08 à 07:05, Joseph Koshy a écrit : Hello List(s), I am very pleased to announce a patch, by Fabien Thomas, that brings PmcTools' callchain capture features to 7-STABLE. Thank you, Fabien! The patch is linked to from the PmcTools wiki page: http://wiki.freebsd.org/PmcTools. The current file name is: "patch-callchain-FreeBSD-7- STABLE-2008-07-12.gz". As the file name indicates, it should apply against a 7-STABLE tree of 2008-07-12 vintage. To apply the patch: % cd /home/src-7x # or whereever your RELENG_7 tree resides % patch < PATCH-FILE Then you should follow the full procedure to update userland and kernel from source as spelled out in src/UPDATING. Please note that HWPMC(4) log files that contain callchain information are not binary compatible with prior versions of pmc(3) and pmcstat(8). Please do test on your systems and let Fabien and me know how you fared. Koshy
Re: Possible UDP deadlock/panic fix
Hi, That seems to be working. I've been up and running for 7 hours now with your patch. The machine is a bit slow but I have both WITNESS and INVARIANTS enabled so as to make sure everything is fine. Rergads, Mario Robert Watson wrote: Attached is an MFC candidate for a patch I just merged to 8.x, which corrects the UDP lock recursion issue both of you were running into. If it settles well for a couple of days in HEAD then I'll go ahead and request an MFC from re@, but your confirmation as to whether or not this corrects the specific symptoms you are seeing would be very helpful. I was able to confirm that it eliminated what appeared to be the same problem here when I attempted to reproduce it based on the information you provided, so I'm hopeful.\ Thanks, Robert N M Watson Computer Laboratory University of Cambridge Property changes on: . ___ Modified: svn:mergeinfo Merged /head/sys:r183265 Index: netinet6/udp6_usrreq.c === --- netinet6/udp6_usrreq.c(revision 183265) +++ netinet6/udp6_usrreq.c(working copy) @@ -975,13 +975,23 @@ error = EINVAL; goto out; } + +/* + * XXXRW: We release UDP-layer locks before calling + * udp_send() in order to avoid recursion. However, + * this does mean there is a short window where inp's + * fields are unstable. Could this lead to a + * potential race in which the factors causing us to + * select the UDPv4 output routine are invalidated? + */ +INP_WUNLOCK(inp); +INP_INFO_WUNLOCK(&udbinfo); if (sin6) in6_sin6_2_sin_in_sock(addr); pru = inetsw[ip_protox[IPPROTO_UDP]].pr_usrreqs; -error = ((*pru->pru_send)(so, flags, m, addr, control, +/* addr will just be freed in sendit(). */ +return ((*pru->pru_send)(so, flags, m, addr, control, td)); -/* addr will just be freed in sendit(). */ -goto out; } } #endif ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp multicast forwarding problems
On Tue, Sep 23, 2008 at 10:46:25AM +0100, Bruce M Simpson wrote: > Hi, > > Whilst doing some QA work on XORP on my desktop, which has fxp0 and > msk0, fxp0 got totally hosed. > I was running PIM-SM and IGMPv2 router-mode on the box at the time. > > I wonder if this is related to the problems with fxp multicast > transmission I saw back in April. > I'm a bit concerned about this as fxp is still a very widespread and > useful network chip. > > I am running 7.0-RELEASE-p4/amd64. > sysctls for dev.fxp.0 are set to their default values. > > I'm not expert on the fxp driver internals, but perhaps someone else has > seen this kind of problem before. Multicast-promiscuous mode (aka > ALLMULTI) was enabled on the interface. I know some NICs have problems > with this, or don't even support it. > > The errors look like this: > fxp0: SCB timeout: 0x10 0x0 0x80 0x0 > fxp0: SCB timeout: 0x10 0x0 0x80 0x0 > fxp0: DMA timeout > ... repeated ... > > Attempted workarounds which don't work to un-wedge the chip: > Reload the fxp0 microcode with "ifconfig fxp0 link0" > Forcibly unloading the kernel module and reloading it > Unpatching and repatching at the switch (a cheap 10/100 one) > Enabling and disabling promiscuous mode > Twiddling dev.fxp.0.noflow > > The link status looks fine, but the card will not send or receive traffic. > A warm reboot was enough to get things back up again. > > regards, > BMS Adding Jack Vogel, who's responsible for fxp(4). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fxp multicast forwarding problems
Hi, Whilst doing some QA work on XORP on my desktop, which has fxp0 and msk0, fxp0 got totally hosed. I was running PIM-SM and IGMPv2 router-mode on the box at the time. I wonder if this is related to the problems with fxp multicast transmission I saw back in April. I'm a bit concerned about this as fxp is still a very widespread and useful network chip. I am running 7.0-RELEASE-p4/amd64. sysctls for dev.fxp.0 are set to their default values. I'm not expert on the fxp driver internals, but perhaps someone else has seen this kind of problem before. Multicast-promiscuous mode (aka ALLMULTI) was enabled on the interface. I know some NICs have problems with this, or don't even support it. The errors look like this: fxp0: SCB timeout: 0x10 0x0 0x80 0x0 fxp0: SCB timeout: 0x10 0x0 0x80 0x0 fxp0: DMA timeout ... repeated ... Attempted workarounds which don't work to un-wedge the chip: Reload the fxp0 microcode with "ifconfig fxp0 link0" Forcibly unloading the kernel module and reloading it Unpatching and repatching at the switch (a cheap 10/100 one) Enabling and disabling promiscuous mode Twiddling dev.fxp.0.noflow The link status looks fine, but the card will not send or receive traffic. A warm reboot was enough to get things back up again. regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming Releases Schedule...
On Mon, 22 Sep 2008, Jo Rhett wrote: > On Sep 21, 2008, at 1:57 AM, Robert Watson wrote: > > This is precisely what we already do -- we guarantee we will support the > > last release on a branch for 24 months after the release. The point of > > concern being discussed is that we can't tell you for sure which minor > > release will be the last release at the time that release goes out the > > door, because the extent to which we keep releasing on old branches depends > > in large part on how the new branch looks. > > I think you are using "last release" in a different way. "the last release" > is always the most release release. Right now 6.3 will have support for > longer than 6.4 will, which is the nature of the problem I raised. If you > always supported the most recent release for 24 months then we wouldn't have > any problem. Jo, it seems to be you who are trying to use "last" in an unusual way. The "last release on a branch" is not the latest one, but the last one. For 4.x that was .11 and for 5.x it was .5, where last means just that. > I mean seriously, if you were to say "We will support 6.4 for 24 months > *unless* we find it necessary to release 6.5 then I'd be totally happy. But > that's not what is being said. I believe that's exactly what has been said. rwatson@ and simon@ have both made it exceedingly clear, to me anyway, that if 6.4 is to be the last release on the 6.x branch - as appears to be likely but cannot be stated definitely at this time, for reasons clearly given and understood - then it will indeed be supported for 24 months. It doesn't seem reasonable to expect 24 months stated support for 6.4 if it turns out not to be the last release - that would then apply to 6.5. It also doesn't seem reasonable to expect that decision to be rushed in advance of the necessary evaluation of the success or otherwise of both 6.4 and 7.1 releases - especially when we're talking about these being only a month or so away anyway. While I do thank Robert and others for the level of patient detail gone into to explain all of this and other aspects of release and security engineering to you, me and everyone else, I rather hope re@ can be let alone to get on with the real work, beyond this 90+ message thread .. my 1.1%, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
