Re: [FAQ] FBSD on a USB stick
On Fri, Mar 5, 2010 at 5:16 AM, Giovanni Trematerra
wrote:
> Instead of this patch people can use kern.cam.boot_delay
> Just set a delay in ms.
> That works on 8-STABLE too.
>
> On Mon, Mar 1, 2010 at 5:31 PM, Hans Petter Selasky wrote:
>> Hi,
>>
>> Sometimes the USB sticks won't get detected in time. You can fix this by
>> using
>> the following simple quick and dirty patch.
>>
>> --HPS
>>
>> ==
>> --- sys/kern/vfs_mount.c (revision 204512)
>> +++ sys/kern/vfs_mount.c (local)
>> @@ -1656,6 +1656,8 @@
>> UMA_ALIGN_PTR, UMA_ZONE_NOFREE);
>> devfs_first();
>>
>> +repeat:
>> +
>> /*
>> * We are booted with instructions to prompt for the root filesystem.
>> */
>> @@ -1725,9 +1727,10 @@
>> * Everything so far has failed, prompt on the console if we haven't
>> * already tried that.
>> */
>> - if (!asked)
>> - if (!vfs_mountroot_ask())
>> - goto mounted;
>> + if (!asked) {
>> + pause("WDISK", 1*hz);
>> + goto repeat;
>> + }
>>
>> panic("Root mount failed, startup aborted.");
I agree with Giovanni as it's easier to customize than the
proposed patch above; it'll be nice when the work has been done where
hacks like these won't be required (waits in anticipation for scottl's
cam work).
Thanks!
-Garrett
___
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: propose: all arch move into a separate dir
On Thu, Mar 4, 2010 at 11:13 AM, Mark Linimon wrote: > There are two chief problems with a large-scale reorg of our src tree: > > - There are many companies who use FreeBSD as part of their business. > In the case of ISPs or companies who use FreeBSD as a base of their > products, this would make it much harder for them to synchronize > their local changes with the master repository as changes occur. > > - We have a large number of existing Problem Reports containing patches > against our src tree. These patches would be in the same situation. > > These are the reasons we've avoided doing so in the past, no matter how > much 'cleaner' things might wind up being. I'm going to come off ignorant as well because I don't have the necessary history in the past attempts to reorganize this -- but would it make sense to gradually work in the changes over an extended period of time and encourage better directory structure in the short-term for new code or would it be too much of a blooming mess to consider. Probably the latter due to the inherent inconsistency with the rework, but I figured I should ask. Thanks! -Garrett ___ 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: propose: all arch move into a separate dir
On Thu, Mar 4, 2010 at 11:33 AM, paradox wrote: > so, I really do not understand why it is so difficult to move a few folders > in the shared folder is a big problem > as is done in openbsd and netbsd > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/?only_with_tag=MAIN > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/ > as you can see > > Well, maybe my thoughts will be understood, then when the folder > /usr/src/sys/ number of architectures to increase to ~ 50, then keep them all > in one folder /usr/src/sys/ this is just a file cesspool without logical > structure I haven't looked at NetBSD or OpenBSD's directory layouts, but Linux is #ifdef hell to work through just to figure out what the frak is going on in the kernel. That seems to be an excellent example of what _not_ to do when organizing architecture specific files, and from what I saw it also allowed for a greater set of feature disparity between architectures because not all camps had to implement feature X.Y.Z as they had their own underlying code to do the common code; granted, that's probably the way it's setup in any architecture-specific sourcebase, but it's a lot more difficult to understand and maintain (or at least it was for me trying to figure out what was going on). FWIW, NetBSD's charter has been to run their OS on a number of architectures, not just a primary set of architectures; OpenBSD's charter differs -- if we all were NetBSD or OpenBSD, then we'd all be using the same thing. But we aren't and that's probably not going to change anytime soon [at least not without community backing and a considerable amount of engineering effort on someone or some group's behalf]. Thanks, -Garrett ___ 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"
ndisgen on FreeBSD-9.0-CURRENT-201002-i386
I tried ndisgen to convert BCMWL564.SYS using FreeBSD-9.0-CURRENT FEB-2010(x86). The files I had were : It gave an error stating BCM43XX64.CAT(unrequired), BCM43XX.CAT(unrequired), bcmwl5.inf and BCMWL564.SYS I had successfully compiled the 32-bit and 64-bit driver on FreeBSD 8.0 (the 64-BIT couldn't be used on FreeBSD amd64 though) This time on FreeBSD-9.0-CURRENT while trying ndisgen the following files got created: bus_if.h device_if.h windrv.h and windrv.o and ndisgen echoed an error == Generating Makefile... done Building kernel module.. "/usr/share/mk/bsd.kmod.mk", line 12: "can't find kernel source tree" build failed. Exiting. == It didn't generate the .ko file Just wanted to know if this error is because 9.0 kernel is still under development. I'll be trying ndisgen with the 32 bit bcmwl5 driver as well. Regards, -- Azim http://my.opera.com/quakerdoomer http://solidmecca.co.nr http://winautopwn.co.nr -- http://www.fastmail.fm - Same, same, but different... ___ 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: propose: all arch move into a separate dir
Alex Keda writes: > Let's wait another 10 years, and, coming at last to understand > that this must be done, and do it was 20 times harder. First, all architectures are not equal in FreeBSD's eyes. Look for "Tier 1 architectures" in the docs and mailing lists. Second, if you want this badly enough ... then convince us. Build a system; do the work; _document it_ (what you did, how long it took, how many files were involved, etc.); and show us why your way is worth it. There are others who want this; maybe you can get them to help. If it really is worth the effort, I have faith it'll get done. Robert Huff ___ 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"
CFT: msk(4) Rx checksum offloading support
Finally I managed to understand how Rx checksum offloading works on Yukon II controllers. The patch at the following URL will add Rx checksum offloading support to msk(4) controllers. http://people.freebsd.org/~yongari/msk/msk.csum.patch The patch was generated against HEAD. Controllers(Yukon Extreme and Yukon FE+) which use more matured Rx checksum offloading does not need this patch. msk(4) already supported Rx checksum offloading for these controllers. This patch is for old Yukon controllers(Yukon EC, Yukon EC Ultra, Yukon FE and Yukon Ultra2). Due to known issues, Rx checksum offloading for Yukon XL was still disabled. I did not see much differences with/without Rx checksum offloading on my box but I guess it may show some differences on notebook systems. The patch also includes some diagnostic message like "Rx checksum value mismatch!" to detect possible hardware checksum logic failure so if you see this message please let me know. Thanks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem with new bwn driver on -CURRENT
On Fri, 2010-03-05 at 16:16 -0800, Weongyo Jeong wrote: > On Fri, Mar 05, 2010 at 04:44:34PM -0500, Joe Marcus Clarke wrote: > > On 3/5/10 3:53 PM, Weongyo Jeong wrote: > > > On Thu, Mar 04, 2010 at 12:12:02AM -0500, Joe Marcus Clarke wrote: > > >> On Wed, 2010-03-03 at 15:14 -0800, Weongyo Jeong wrote: > > When it occurs again, I will get you the details and the full dmesg. > > Do > > you want a verbose dmesg, or a standard one? > > >>> > > >>> I think a standard one is enough. Thank you. > > >> > > >> Here you go. This is on -CURRENT from about 30 minutes ago. Thanks for > > >> looking into this. > > >> > > >> http://www.marcuscom.com/downloads/salami.dmesg > > > > > > Thank you for dmesg. It looks using PIO mode is only a way to avoid > > > this problem. > > > > > > I looked sources and problems of other Broadcom wireless driver for LP > > > PHY users. They also encounters this issue and are trying to solve > > > this but no luck and no perfect patch until now. > > > > > > Recently AFAIK wireless-test git of linux adopted a patch `gracefully > > > convert DMA to PIO mode' to solve it. > > > > > > Additionally some guys tolds some success story when they disabled ACPI > > > but it looks it's not a perfect solution. > > > > > > IIRC you said PIO worked for association with your AP but no further > > > traffic. However I wonder that this is weird for me because paths of > > > sending management frames and sending data frames are same. Could you > > > please recheck whether PIO mode worked? I'll try to test PIO mode on my > > > environment again. > > > > I can absolutely confirm PIO mode does NOT work with my card. I tested > > on a clean power-up. The card associates, but does not pass any > > traffic. I do not see the same decryption messages that I do with DMA mode. > > OK. I'd like to see some verbose message from bwn(4) after applying > attached patch with email. Could you please test with it and show me > dmesg? > > I tested 3 broadcom card whose revisions are 5 and 9 and it looks it's > working. > > I have one LP PHY device, half MiniPCI-E for laptop, but could not test > with this patch because I could not turn on RF; it's connected with > desktop using converter MiniPCI-E to PCI-E though normally it looks > MiniPCI-E devices are turned on using H/W RF switch. Here are two dmesg outputs. Both were taken with this patch. One is with PIO mode, and the other is with (working) DMA mode. The names indicate which is which. http://www.marcuscom.com/downloads/salami_pio.dmesg http://www.marcuscom.com/downloads/salami_dma.dmesg Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: propose: all arch move into a separate dir
On Fri, Mar 05, 2010 at 11:16:41AM +, Doug Rabson wrote: > I think you misunderstand. Some of us old-timers have been having this > discussion repeatedly for well over ten years. It always ends up the same > way - a re-org might make the source tree marginally prettier but the > consequences for long-term maintenance and supporting downstream > contributors outweigh any possible benefit. Having the same conversation > every two years with the same outcome gets annoying. To be fair - two years ago we were not using a source control system that understood moves within the repository. To do this two years ago, we had to make a choice between three poor paths of how to do CVS moves - repo copy (breaks date-based checkout), delete-add pairs (looses history), or copy the entire repository move files and use new repo for new releases and existing repo for old releases. Juniper now also uses Subversion - so with sufficient warning and planning, Juniper could consume a move of the CPU directories moving under arch/. Juniper also had a CVS based tree reorg 1.5 years go - taking the third path above. Please don't use Juniper as an reason to not move forward with this change. -- -- David (obr...@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: propose: all arch move into a separate dir
On Sat, Mar 06, 2010 at 01:28:24AM -0800, Garrett Cooper wrote: > FWIW, NetBSD's charter has been to run their OS on a number of > architectures, not just a primary set of architectures; OpenBSD's > charter differs -- if we all were NetBSD or OpenBSD, then we'd all be > using the same thing. But we aren't and that's probably not going to > change anytime soon [at least not without community backing and a We aren't? At this point it seems any architecture an be brought into FreeBSD without regard to critical mass or ability to support it to the standards of our past. I do believe FreeBSD's character does not include chasing every embedded platform where there is energy and talent for the initial port. -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ 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: propose: all arch move into a separate dir
On Fri, Mar 05, 2010 at 12:01:30PM +0100, Svein Skogen (Listmail Account) wrote: > Oh, so because a lot of the programmers behind it receive wages, and the > project itself won't commit ritual suicide by basically blocking the > companies using FreeBSD from returning improvements they make to the > project itself, it should be renamed. Svein, A source layout change is the lest of the problems pushing code back from companies using FreeBSD. When $WORK rearranged our FreeBSD-based tree, we simply provided a perl script to run over patch files that fixed up the patch. sed -e 's,sys/amd64,sys/arch/amd64,g' patchfile > newpatchfile isn't that hard to do... The fact that we totally rototilled the bge and em drivers FreeBSD 6.1->6.2 is a MUCH bigger problem to the commercial users of FreeBSD and their patch sets. [medium seriousness bug fixes were done by a full MFC of the driver, vs. just spot fixing the needed changes] -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ 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: propose: all arch move into a separate dir
On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote: > On Fri, 5 Mar 2010, Poul-Henning Kamp wrote: >> In message , Robert >> Watso n writes: >>> Doing that kind of rearrangement [...] would be a nightmare for anyone >>> with large [...] patches, so I'd say we could pretty much rule that out >>> outright. >> >> I would say that we should do it occasionally, to encourage these FreeBSD >> users to contribute as many of their local changes back to the project, as >> possible :-) > > Absolutely -- and rearranging a tree is a good way to invalidate all those > patches as well :-). No, not it isn't. Provide a script to convert path's in the diff. This is what $LARGE_FREEBSD_USER did when it rearranged it source tree. It was done by creating a copy of the CVS repo and moved files around. Old releases stayed in the old repo, and new releases done from the new repo. 'diff | fixpatch | patch -p0' were used to move code between sandboxes. -- -- David (obr...@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"
Core i5 AES acceleration
Does FreeBSD currently support cryptographic acceleration for AES on the Core i5 CPU? I searched, but couldn't find anything, and the crypto(4) manpage only lists these divers in "see also:" glxsb(4),hifn(4), ipsec(4), padlock(4), safe(4), ubsec(4) ___ 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: Core i5 AES acceleration
David Ehrmann wrote: Does FreeBSD currently support cryptographic acceleration for AES on the Core i5 CPU? I searched, but couldn't find anything, and the crypto(4) manpage only lists these divers in "see also:" no, but if you write a driver for it we will... :-) (most things in open source happen because someone needs it.) glxsb(4),hifn(4), ipsec(4), padlock(4), safe(4), ubsec(4) ___ 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"
