Re: revisiting tunables under Safe Mode menu option
on 01/03/2012 03:34 Devin Teske said the following: > > +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe > Mode knows about ACPI but only acts on it when being enabled). Can you explain why? +1 for having both menu items and each doing its own thing without any entanglement :-) -- Andriy Gapon ___ 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: No working IDE in FreeBSD!
On 2012-Feb-28, 15:44, Pietro Cerutti wrote: > On 2012-Feb-26, 11:48, O. Hartmann wrote: > > On 02/23/12 14:38, Eduardo Morras wrote: > > > At 12:22 23/02/2012, O. Hartmann wrote: > > > Codelite, i use it and works fine (Freebsd 8.2) with Clang. Version on > > > ports is 3.0 not 3.5. On the webpage you have information about how to > > > configure for use with clang/llvm. > > > > Codelite looks nice. But why is codelite setup in editors/codelite and > > not in devel/codelite as other IDEs? > > > > By the way, do all IDEs supported by FreeBSD suffer from being outdated > > and aged eons? CodeLite 3.5 is at this very moment the most recent > > version and claims to provide a much better LLVM/CLANG support. > > > > Hope I can convince the maintainer by sending a PR ;-) > > I am working on an update to codelite to 3.5.5375. However, it contains > a lot of Linux specific things that I'll need to track down before I can > commit the update. In particular, clang/llvm support and the database > designer components are causing me problems. > > Anyway, the updated version will hit the ports tree within several days. I have just updated codelite to 3.5.5375. This update includes optional support for MySQL and PostgreSQL in Database Explorer, and clang-based code completion. Enjoy, -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpKFtQnYwQWF.pgp Description: PGP signature
Re: revisiting tunables under Safe Mode menu option
on 01/03/2012 03:07 Kevin Oberman said the following: > I disabled APIC with a tunable (hint.apic.0.disabled=1). The T43 has > no BIOS setting to turn it off. > > I have some time and still have the computer and it is up and running > 9-Stable. In theory, I am retired, but still work part-time job at > Lawrence Berkeley and have a contract with another university that > will end sin a few weeks. I should be able to spend some time looking > at it, but I may be tied up with those at times. > > I am NOT a programmer any more. My last kernel hacking was done in > assembly on a VAX (or, maybe and Alpha) running VMS about 25 years > ago. If you want me to help, I'll try, but I'll probably need detailed > instructions and, since the system is owned by the U.S. government, I > can't allow others to access it. I think that obtaining verbose boot logs for both cases would be a nice start. If you can't get the log as a text (e.g. via serial console) for the APIC case, then a series of digital camera screenshots would be fine too. P.S. Here seems to be a dmesg of FreeBSD 7 successfully booting on T43 with APIC enabled: http://www.4ucode.com/Study/Topic/1091620 -- Andriy Gapon ___ 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] modular kernel config
On Feb 21, 2012, at 3:35 PM, Alexander Leidinger wrote: > Hi, > > I created a kernel config for i386/amd64 (should work on -current and 9.x) > and a suitable loader.conf which: > - tries to provide as much features as GENERIC (I lost one or two disk > controllers, they are not available as a module... or I didn't find > them) > - incorporates some more features based upon a poll on stable@ > (see below) > - loads as much as possible as a module > > I've compile-tested them on i386 and amd64, but I didn't had time yet to give > it a try on a spare machine. I may get some time next week to test (i386 > only). It would be nice if someone could help testing: > - compile the kernel > - make _sure_ you have a way to recover the system in case > the new kernel+loader.conf fails > - verify that the example loader.conf contains all devices > which are important for you > - copy the example loader.conf to /boot/loader.conf > - give it a try > > You can download from > http://www.Leidinger.net/FreeBSD/current-patches/ > The files are > - i386_SMALL > - i386_SMALL_loader.conf > - amd64_SMALL > - amd64_SMALL_loader.conf > I didn't provide direct links for eqch one on purpose. If you do not know how > to recover a system with an unsuitable loader.conf, don't give this a try > (you could check a diff between GENERIC and SMALL, and make sure all removed > devices which are imporant for you are in the loader.conf). They should work > on -current and on 9.x, for 8.x I'm not sure if it woll work without removing > some stuff (GENERIC on 8.x comes without some more debugging options, make > sure you don't get surprised by them, but those may not be the only > differences). > > I didn't use the name MODULAR on purpose, I've chosen a name where the first > letter does not yet exist in the kernel config directory, to make > tab-completion more easy. If you are not happy with the name, keep your > opinion for yourself please, until after you tested this on a (maybe virtual) > system. > > The loader.conf was generated with a script from a diff between GENERIC and > SMALL, if there's a name mismatch between the config-name and the > module-name, the script may have missed the module (I added some missing > sound modules, but I may have overlooked something). You better double-check > before giving it a try. The loader.conf is also supposed to disable some > features (at the end of the file) which are new compared to what is in > GENERIC, if the particular feature could cause a change in behavior. > > The new stuff in the kernel config compared to GENERIC is (in order of number > of requests from users): > - IPSEC (+ device enc + IPSEC_NAT_T) > - ALTQ > - SW_WATCHDOG > - QUOTA > - IPSTEALTH (disabled in loader.conf) > - IPFIREWALL_FORWARD (touches every packet, power users which need > a bigger PPS but not this feature can recompile the kernel, > discussed with julian@) > - FLOWTABLE (disabled in loader.conf) > - BPF_JITTER > > In the poll there where some more options requested, but most of them can be > handled via the loader or sysctl (e.g. the firewalls can be loaded as > modules). For some of them I added some comments at the end of the SMALL > config to make it more easy to find the correct way of configuring them. > Doc-committers may want to have a look, maybe there's an opportunity to > improve existing documentation. > > I'm interested in success reports, failure reports, and reports about missing > stuff in loader.conf (mainly compared to the devices available in GENERIC, > but missing stuff which could help getting a system installed and booted is > welcome even if what you propose is not in GENERIC). > > Bye, > Alexander. > > -- > > http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 > Just an idea : Ship FreeBSD with all the kernel object files (even compile different versions of them, let's say networking with IPFORWARD and networking without), and then let the user relink the kernel with some shell script. This way freebsd-update can binary update the object files, and then relink the users's kernel. This of course will probably need some infrastructure work to make it possible. P.S.: As I said, just an idea off the top of my head :) ___ 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"
Can't boot with geom_part_(gpt|mbr|bsd|ebr)
Hi! Just add to loader.conf these options geom_part_gpt_load="YES" geom_part_bsd_load="YES" geom_part_ebr_load="YES" geom_part_mbr_load="YES" and your kernel can't boot I have posted PR http://www.freebsd.org/cgi/query-pr.cgi?pr=165573 ___ 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: No working IDE in FreeBSD!
On 03/01/12 09:49, Pietro Cerutti wrote: > On 2012-Feb-28, 15:44, Pietro Cerutti wrote: >> On 2012-Feb-26, 11:48, O. Hartmann wrote: >>> On 02/23/12 14:38, Eduardo Morras wrote: At 12:22 23/02/2012, O. Hartmann wrote: Codelite, i use it and works fine (Freebsd 8.2) with Clang. Version on ports is 3.0 not 3.5. On the webpage you have information about how to configure for use with clang/llvm. >>> >>> Codelite looks nice. But why is codelite setup in editors/codelite and >>> not in devel/codelite as other IDEs? >>> >>> By the way, do all IDEs supported by FreeBSD suffer from being outdated >>> and aged eons? CodeLite 3.5 is at this very moment the most recent >>> version and claims to provide a much better LLVM/CLANG support. >>> >>> Hope I can convince the maintainer by sending a PR ;-) >> >> I am working on an update to codelite to 3.5.5375. However, it contains >> a lot of Linux specific things that I'll need to track down before I can >> commit the update. In particular, clang/llvm support and the database >> designer components are causing me problems. >> >> Anyway, the updated version will hit the ports tree within several days. > > I have just updated codelite to 3.5.5375. This update includes optional > support for MySQL and PostgreSQL in Database Explorer, and clang-based > code completion. > > Enjoy, > > > Great! It works fine for me. Thanks a lot. Oliver signature.asc Description: OpenPGP digital signature
Re: No working IDE in FreeBSD!
I think this is just right post to intrude :) I'm developing software, and making it in pretty good IDE - Intellij Idea. There's community and pro version. What good in this company - it gives access to Pro version for not-small open source projects. I tried to take some time of Philip Paeps, but he is always busy with something. Maybe someone of you guys could be interested in filling request for open source license. IDE is very strong and smart, support java/c++/php and a lot of languages via plugins. Thanks. -- Regards, Alexander Yerenkow ___ 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: No working IDE in FreeBSD!
Thu, Mar 01, 2012 at 02:31:06PM +0200, Alexander Yerenkow wrote: > I tried to take some time of Philip Paeps, but he is always busy with > something. Maybe someone of you guys could be interested in filling request > for open source license. Are you requesting someone to create FreeBSD port for this IDE or you meant something else? -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpuP6wNZwsie.pgp Description: PGP signature
Re: No working IDE in FreeBSD!
2012/3/1 Eygene Ryabinkin > Thu, Mar 01, 2012 at 02:31:06PM +0200, Alexander Yerenkow wrote: > > I tried to take some time of Philip Paeps, but he is always busy with > > something. Maybe someone of you guys could be interested in filling > request > > for open source license. > > Are you requesting someone to create FreeBSD port for this IDE > or you meant something else? > I'm sorry to be not clear in hasteness of day! I think port is not required, they have good enough run.sh which gracefully understand what is FreeBSD and could start IDE just fine. What I meant, was that FreeBSD as a project could benefit from applying for their OpenSource Licensing program, so any commiter/developer could try and probably work efficiently in this IDE. Because I'm not committer nor some kind of mentor of project, I can only point someone to there. If you go on their site (google intellij), part of "IntelliJ IDEA" > "Buy & Upgrade" > "Open Source Project License" > Apply Now, you could learn more on conditions for applying. So, to summarize this all again: If there are some commiter/responsible person who can apply - then FreeBSD devs could gain one more IDE to develop some parts of FreeBSD. > -- > Eygene Ryabinkin,,,^..^,,, > [ Life's unfair - but root password helps! | codelabs.ru ] > [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] > -- Regards, Alexander Yerenkow ___ 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"
skype-2.1.0.81,1 && problem in child proc
Hello, I'm using skype-2.1.0.81,1 in 10-CURRENT r226986, which works fine for chat and video calls; I encounter the following small problem: when a chat contains a URL one can open that URL with a browser; it seems that skype is launching a shell script /usr/local/bin/xdg-open which in turn tries to figure out if the desktop is Gnome or KDE and which browser to use; it simple does not start any browser for me; while digging into this (inserting printf's to a log file) I see, that the script wants to launch kfmclient exec http://www.hallo-verlag.de/... with the correct URL from the chat dialog in skype but this gives an error to stderr: Cannot open "/usr/lib/libv4l/v4l2convert.so" the shared lib exists in /compat/linux/usr/lib/libv4l/v4l2convert.so and in /usr/local/lib/libv4l/v4l2convert.so $ ls -l /usr/local/lib/libv4l/v4l2convert.so /compat/linux/usr/lib/libv4l/v4l2convert.so -rwxr-xr-x 1 root wheel 4788 14 nov 12:52 /compat/linux/usr/lib/libv4l/v4l2convert.so -rwxr-xr-x 1 root wheel 5341 14 nov 07:49 /usr/local/lib/libv4l/v4l2convert.so What is the matter with this and was has 'kfmclient' todo with v4l2convert.so shared objects? Thanks matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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] modular kernel config
On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: > You can download from >http://www.Leidinger.net/FreeBSD/current-patches/ > The files are >- i386_SMALL >- i386_SMALL_loader.conf >- amd64_SMALL >- amd64_SMALL_loader.conf Where SCSI disk/etc? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't boot with geom_part_(gpt|mbr|bsd|ebr)
on 01/03/2012 09:27 Pavel Timofeev said the following: > Hi! > Just add to loader.conf these options > geom_part_gpt_load="YES" > geom_part_bsd_load="YES" > geom_part_ebr_load="YES" > geom_part_mbr_load="YES" > and your kernel can't boot Thank you for the report. Could you please provide some technical information? "kernel can't boot" is a little bit too unspecific. Any particular error messages, etc? > I have posted PR http://www.freebsd.org/cgi/query-pr.cgi?pr=165573 -- Andriy Gapon ___ 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: revisiting tunables under Safe Mode menu option
> -Original Message- > From: Andriy Gapon [mailto:a...@freebsd.org] > Sent: Thursday, March 01, 2012 12:39 AM > To: Devin Teske > Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske > Subject: Re: revisiting tunables under Safe Mode menu option > > on 01/03/2012 03:34 Devin Teske said the following: > > > > +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe > > Mode knows about ACPI but only acts on it when being enabled). > > Can you explain why? > +1 for having both menu items and each doing its own thing without any > entanglement :-) > First, I realize that this may sound entirely *dumb*, but here-goes: In transitioning from an old release (sans-menu; 4.11 for example) to a newer release (with menu; 6.x for example), one of the first thing that is noticed is "Safe Mode". I know that when I first saw this, I scratched my head and wondered what it did and what it might be useful for. To this day, I still have never used it. When I created the new menu for 9.x/higher, I had to rewrite that portion of the code and eventually learned what Safe Mode does when used. Still can't say that I've ever used it, however, at the point that I saw that it disabled ACPI among other things, that it is more of a blanket option for anything and everything that might be useful if/when you're having problems (*cough* still can't say that I've ever used it, as when I have problems I'm usually slogging through the kernel code, not relying on safe mode to fix some problem). That being said, I felt that it was a huge improvement to the UI to have the Safe Mode option divulge a little bit of its secret by visibly diddling the ACPI menu item (giving a clue to people that *haven't* read the code that this option is indeed not independent but instead conglomerate in-nature). Indeed, I've watched field engineers when exploring the menu options and their eyes light-up when they see that "Safe Mode" toggles ACPI off when enabled. Extrapolating on their surprise, they appear to have an "Aha!"-moment as previously... this field engineer had no idea what on God's green Earth what "Safe Mode" did (or didn't) as he didn't know about "kenv" and certainly couldn't read "Forth". At that point, he may not have had a full understanding of all the options that Safe Mode diddled, but at that point he at least knew that Safe Mode is a multi-option that does many things -- which is more than 6.x, 7.x, or 8.x ever offered which simply boots immediately the Safe Mode option is selected and does nothing to explain what it is that Safe Mode is doing (which would in-turn properly calibrate the user's expectations). Making the menu items completely independent would be take away the (however slight) above value-add that was brought in by entwining these two menu-items. I'm not saying that this would be a grave travesty, but would in-fact be a value-loss. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: revisiting tunables under Safe Mode menu option
On Thursday, March 01, 2012 3:39:21 am Andriy Gapon wrote: > on 01/03/2012 03:34 Devin Teske said the following: > > > > +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe > > Mode knows about ACPI but only acts on it when being enabled). > > Can you explain why? > +1 for having both menu items and each doing its own thing without any > entanglement :-) Yeah, I think at this point we could make safe mode not disable ACPI, but leave those as independent knobs. That's simpler to implement and arguably more intuitive (though having the boot menu now have 'YES/NO' state that gets updated helps a lot with the UI being easier to understand). -- John Baldwin ___ 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: revisiting tunables under Safe Mode menu option
on 01/03/2012 18:52 Devin Teske said the following: > > >> -Original Message- >> From: Andriy Gapon [mailto:a...@freebsd.org] >> Sent: Thursday, March 01, 2012 12:39 AM >> To: Devin Teske >> Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske >> Subject: Re: revisiting tunables under Safe Mode menu option >> >> on 01/03/2012 03:34 Devin Teske said the following: >>> >>> +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe >>> Mode knows about ACPI but only acts on it when being enabled). >> >> Can you explain why? >> +1 for having both menu items and each doing its own thing without any >> entanglement :-) >> > > First, I realize that this may sound entirely *dumb*, but here-goes: > > In transitioning from an old release (sans-menu; 4.11 for example) to a newer > release (with menu; 6.x for example), one of the first thing that is noticed > is > "Safe Mode". > > I know that when I first saw this, I scratched my head and wondered what it > did > and what it might be useful for. To this day, I still have never used it. > > When I created the new menu for 9.x/higher, I had to rewrite that portion of > the > code and eventually learned what Safe Mode does when used. Still can't say > that > I've ever used it, however, at the point that I saw that it disabled ACPI > among > other things, that it is more of a blanket option for anything and everything > that might be useful if/when you're having problems (*cough* still can't say > that I've ever used it, as when I have problems I'm usually slogging through > the > kernel code, not relying on safe mode to fix some problem). > > That being said, I felt that it was a huge improvement to the UI to have the > Safe Mode option divulge a little bit of its secret by visibly diddling the > ACPI > menu item (giving a clue to people that *haven't* read the code that this > option > is indeed not independent but instead conglomerate in-nature). > > Indeed, I've watched field engineers when exploring the menu options and their > eyes light-up when they see that "Safe Mode" toggles ACPI off when enabled. > Extrapolating on their surprise, they appear to have an "Aha!"-moment as > previously... this field engineer had no idea what on God's green Earth what > "Safe Mode" did (or didn't) as he didn't know about "kenv" and certainly > couldn't read "Forth". At that point, he may not have had a full understanding > of all the options that Safe Mode diddled, but at that point he at least knew > that Safe Mode is a multi-option that does many things -- which is more than > 6.x, 7.x, or 8.x ever offered which simply boots immediately the Safe Mode > option is selected and does nothing to explain what it is that Safe Mode is > doing (which would in-turn properly calibrate the user's expectations). > > Making the menu items completely independent would be take away the (however > slight) above value-add that was brought in by entwining these two menu-items. > I'm not saying that this would be a grave travesty, but would in-fact be a > value-loss. Devin, you did a great job with boot menu enhancement in general and in this area in particular. You greatly improved usability while preserving the historic behavior and put a lot of work and creativity into that. Thank you! But the argument is that the historic behavior is no longer useful. I see that removing the historic behavior also kills a little bit of your code (and a little bit of magic). That's true, that's a loss in the code. But I still believe that it would be an improvement from the point of view of usability end-users. Having a whole sub-menu where multiple parameters could be tweaked individually would be even greater improvement. But that's not as easy to do. -- Andriy Gapon ___ 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: revisiting tunables under Safe Mode menu option
On Mar 1, 2012, at 9:52 AM, Devin Teske wrote: > > >> -Original Message- >> From: Andriy Gapon [mailto:a...@freebsd.org] >> Sent: Thursday, March 01, 2012 12:39 AM >> To: Devin Teske >> Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske >> Subject: Re: revisiting tunables under Safe Mode menu option >> >> on 01/03/2012 03:34 Devin Teske said the following: >>> >>> +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe >>> Mode knows about ACPI but only acts on it when being enabled). >> >> Can you explain why? >> +1 for having both menu items and each doing its own thing without any >> entanglement :-) >> > > First, I realize that this may sound entirely *dumb*, but here-goes: > > In transitioning from an old release (sans-menu; 4.11 for example) to a newer > release (with menu; 6.x for example), one of the first thing that is noticed > is > "Safe Mode". > > I know that when I first saw this, I scratched my head and wondered what it > did > and what it might be useful for. To this day, I still have never used it. > To be fair, I'm pretty sure that 'Safe Mode' was documented in one of the docbook manuals, though the FreeBSD project never, to my knowledge, had a "quick install/troubleshooting guide' that documented the loader menu. The name was inspired by Windows, but if you aren't familiar with that side of the world, then I can see how the name would have diminished meaning. So I understand where you're coming from. I'd like to turn the discussion away from ACPI specifically. What I'd like to see improved is two things: 1. There are a number of knobs that can be manipulated to help enable a non-booting system boot, which in turn gives a system administrator a fighting chance to figure out what's wrong. ACPI is (or was) one of these options, but there are several others, and up until your re-write of the menu system, they were opaque to the user. I'd like to explore the idea of having a sub-menu that exposes these knobs and allows them to be individually controlled, but still have an upper-level option that turns them all-on or all-off for ease of use. 2. There are a ton of kenv/TUNABLE knobs in any given kernel, and many of them are useful for sysadmins, even beyond just the 'safe mode' subset. I'd like to see a post-processor run on the kernel build that collects all of the kenv knobs in that kernel and puts them into a file that can be read by the boot menu system. The system then dynamically turns these into another sub-menu of knobs that can be manipulated. So, how hard would it be to have nested sub-menus? Would (1) be something feasible to do in the near term? Would (2) be feasible to do in the long term? Thanks, Scott ___ 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"
how to cross-build a single application ?
What is the way to properly cross-build a single program (after having gone throught the 'toolchain' and possibly even a full 'buildworld') from the top-level directory of a FreeBSD source tree ? right now i do something like cd $SOURCE_ROOT make MAKEOBJDIRPREFIX=/my_obj_tree TARGET=amd64 buildworld but i seem to remember that there is a more efficient way when you want to rebuild only one program or one subtree. I think i have seen this question being answered from time to time but i can't find how now. any hints ? cheers luigi ___ 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: how to cross-build a single application ?
On Thu, Mar 01, 2012 at 12:24:13PM -0500, Alexander Kabaev wrote: > On Thu, 1 Mar 2012 18:38:19 +0100 > Luigi Rizzo wrote: > > > What is the way to properly cross-build a single program > > (after having gone throught the 'toolchain' and possibly > > even a full 'buildworld') > > from the top-level directory of a FreeBSD source tree ? > > > > right now i do something like > > > > cd $SOURCE_ROOT > > make MAKEOBJDIRPREFIX=/my_obj_tree TARGET=amd64 buildworld > > > > but i seem to remember that there is a more efficient way > > when you want to rebuild only one program or one subtree. > > I think i have seen this question being answered from time to time > > but i can't find how now. > > > > any hints ? > > > > cheers > > luigi > > > > Something like this should work: > > cd src/ > make buildenv TARGET=... > cd usr.bin/blah > make close: eval `make buildenvvars TARGET=... ` && cd usr.bin/blah && make thanks! luigi ___ 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: revisiting tunables under Safe Mode menu option
> -Original Message- > From: Scott Long [mailto:sco...@samsco.org] > Sent: Thursday, March 01, 2012 9:13 AM > To: Devin Teske > Cc: 'Andriy Gapon'; 'John Baldwin'; freebsd-current@FreeBSD.org; 'Devin Teske' > Subject: Re: revisiting tunables under Safe Mode menu option > > > On Mar 1, 2012, at 9:52 AM, Devin Teske wrote: > > > > > > >> -Original Message- > >> From: Andriy Gapon [mailto:a...@freebsd.org] > >> Sent: Thursday, March 01, 2012 12:39 AM > >> To: Devin Teske > >> Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske > >> Subject: Re: revisiting tunables under Safe Mode menu option > >> > >> on 01/03/2012 03:34 Devin Teske said the following: > >>> > >>> +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe > >>> Mode knows about ACPI but only acts on it when being enabled). > >> > >> Can you explain why? > >> +1 for having both menu items and each doing its own thing without any > >> entanglement :-) > >> > > > > First, I realize that this may sound entirely *dumb*, but here-goes: > > > > In transitioning from an old release (sans-menu; 4.11 for example) to a newer > > release (with menu; 6.x for example), one of the first thing that is noticed is > > "Safe Mode". > > > > I know that when I first saw this, I scratched my head and wondered what it did > > and what it might be useful for. To this day, I still have never used it. > > > > To be fair, I'm pretty sure that 'Safe Mode' was documented in one of the > docbook manuals, though the FreeBSD project never, to my knowledge, had a > "quick install/troubleshooting guide' that documented the loader menu. The > name was inspired by Windows, but if you aren't familiar with that side of the > world, then I can see how the name would have diminished meaning. So I > understand where you're coming from. > > I'd like to turn the discussion away from ACPI specifically. What I'd like to see > improved is two things: > > 1. There are a number of knobs that can be manipulated to help enable a non- > booting system boot, which in turn gives a system administrator a fighting chance > to figure out what's wrong. ACPI is (or was) one of these options, but there are > several others, and up until your re-write of the menu system, they were opaque > to the user. I'd like to explore the idea of having a sub-menu that exposes these > knobs and allows them to be individually controlled, but still have an upper-level > option that turns them all-on or all-off for ease of use. > > 2. There are a ton of kenv/TUNABLE knobs in any given kernel, and many of > them are useful for sysadmins, even beyond just the 'safe mode' subset. I'd like > to see a post-processor run on the kernel build that collects all of the kenv knobs > in that kernel and puts them into a file that can be read by the boot menu > system. The system then dynamically turns these into another sub-menu of > knobs that can be manipulated. > > So, how hard would it be to have nested sub-menus? Would (1) be something > feasible to do in the near term? Would (2) be feasible to do in the long term? > Sub-menus are not hard at all. The menu.4th module released under 9.0-RELEASE already supports sub-menus and hierarchical menus. You don't have to change the Forth code in even the slightest, this can all be done through "rc" files like "menu.rc". The magic of-course is achieved through the utilization of the "menu-clear" FICL word (linked-to below): http://svnweb.freebsd.org/base/release/9.0.0/sys/boot/forth/menu.4th?revision=22 9286&view=markup NOTE: menu-clear is the last function in the file at the very bottom. The comment for which is thus: "This function unsets all the possible environment variables associated with creating the interactive menu. Call this when you want to clear the menu area in preparation for another menu." Further-more, I have full examples on how to implement (working) sub-menus, hierarchical menus, and such. However... Design discussions would have to follow as we do have serious limitations. First, each menu can have only 9 items (we are in-fact limited by screen real-estate as we do indeed want to retain support for serial consoles during boot). Also, don't forget that we actually have three different types of menu items that can be used for each item in each menu: 1. Normal action-items (like "Boot") 2. Toggle items (like "On/Off" or "Yes/No" features) 3. Cyclic items (allowing selection of one kernel out of 5 different ones, for example) So creativity can probably find a graceful solution to however many items we need to support. (thinking out loud here: maybe such a discussion would be best shunted off to hackers if/when we get to the point of discussing actual changes, patches, and code) -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not discl
Re: how to cross-build a single application ?
On Thu, 1 Mar 2012 18:38:19 +0100 Luigi Rizzo wrote: > What is the way to properly cross-build a single program > (after having gone throught the 'toolchain' and possibly > even a full 'buildworld') > from the top-level directory of a FreeBSD source tree ? > > right now i do something like > > cd $SOURCE_ROOT > make MAKEOBJDIRPREFIX=/my_obj_tree TARGET=amd64 buildworld > > but i seem to remember that there is a more efficient way > when you want to rebuild only one program or one subtree. > I think i have seen this question being answered from time to time > but i can't find how now. > > any hints ? > > cheers > luigi > Something like this should work: cd src/ make buildenv TARGET=... cd usr.bin/blah make -- Alexander Kabaev signature.asc Description: PGP signature
RE: revisiting tunables under Safe Mode menu option
> -Original Message- > From: Andriy Gapon [mailto:a...@freebsd.org] > Sent: Thursday, March 01, 2012 9:07 AM > To: Devin Teske > Cc: 'John Baldwin'; freebsd-current@FreeBSD.org; 'Scott Long'; 'Devin Teske' > Subject: Re: revisiting tunables under Safe Mode menu option > > on 01/03/2012 18:52 Devin Teske said the following: > > > > > >> -Original Message- > >> From: Andriy Gapon [mailto:a...@freebsd.org] > >> Sent: Thursday, March 01, 2012 12:39 AM > >> To: Devin Teske > >> Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske > >> Subject: Re: revisiting tunables under Safe Mode menu option > >> > >> on 01/03/2012 03:34 Devin Teske said the following: > >>> > >>> +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe > >>> Mode knows about ACPI but only acts on it when being enabled). > >> > >> Can you explain why? > >> +1 for having both menu items and each doing its own thing without any > >> entanglement :-) > >> > > > > First, I realize that this may sound entirely *dumb*, but here-goes: > > > > In transitioning from an old release (sans-menu; 4.11 for example) to a newer > > release (with menu; 6.x for example), one of the first thing that is noticed is > > "Safe Mode". > > > > I know that when I first saw this, I scratched my head and wondered what it did > > and what it might be useful for. To this day, I still have never used it. > > > > When I created the new menu for 9.x/higher, I had to rewrite that portion of > the > > code and eventually learned what Safe Mode does when used. Still can't say > that > > I've ever used it, however, at the point that I saw that it disabled ACPI among > > other things, that it is more of a blanket option for anything and everything > > that might be useful if/when you're having problems (*cough* still can't say > > that I've ever used it, as when I have problems I'm usually slogging through the > > kernel code, not relying on safe mode to fix some problem). > > > > That being said, I felt that it was a huge improvement to the UI to have the > > Safe Mode option divulge a little bit of its secret by visibly diddling the ACPI > > menu item (giving a clue to people that *haven't* read the code that this > option > > is indeed not independent but instead conglomerate in-nature). > > > > Indeed, I've watched field engineers when exploring the menu options and > their > > eyes light-up when they see that "Safe Mode" toggles ACPI off when enabled. > > Extrapolating on their surprise, they appear to have an "Aha!"-moment as > > previously... this field engineer had no idea what on God's green Earth what > > "Safe Mode" did (or didn't) as he didn't know about "kenv" and certainly > > couldn't read "Forth". At that point, he may not have had a full understanding > > of all the options that Safe Mode diddled, but at that point he at least knew > > that Safe Mode is a multi-option that does many things -- which is more than > > 6.x, 7.x, or 8.x ever offered which simply boots immediately the Safe Mode > > option is selected and does nothing to explain what it is that Safe Mode is > > doing (which would in-turn properly calibrate the user's expectations). > > > > Making the menu items completely independent would be take away the > (however > > slight) above value-add that was brought in by entwining these two menu- > items. > > I'm not saying that this would be a grave travesty, but would in-fact be a > > value-loss. > > Devin, > > you did a great job with boot menu enhancement in general and in this area in > particular. You greatly improved usability while preserving the historic behavior > and put a lot of work and creativity into that. Thank you! > Thank you for your kind words! Really! > But the argument is that the historic behavior is no longer useful. I see that > removing the historic behavior also kills a little bit of your code (and a little > bit of magic). That's true, that's a loss in the code. > (nods) [snip] > Having a whole sub-menu where multiple parameters could be tweaked > individually > would be even greater improvement. But that's not as easy to do. > Actually, it is easy to do. Since day one, menu.4th has supported sub-menus and hierarchical menus. HINT: see "menu-clear" at the bottom of "menu.4th" ASIDE: Before I do some mock-ups illustrating multiple "rc" files providing sub-menus, we'll need to discuss what these menus will look like and how they'll be generated (I heard of a hint of having build(7) generate something). I'm not opposed to say, having a "submenu.rc.in" which is processed into "submenu.rc" (obviously more-appropriately named than "submenu") and hooked into a menu-item visible in "menu.rc". Mind you, "menu.rc" may have to be forked-off itself (for reasons we won't discuss until we get down to the nitty-gritty; possibly on -hackers). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intend
Re: how to cross-build a single application ?
On Thu, Mar 01, 2012 at 06:38:19PM +0100, Luigi Rizzo wrote: > What is the way to properly cross-build a single program > (after having gone throught the 'toolchain' and possibly > even a full 'buildworld') > from the top-level directory of a FreeBSD source tree ? > > right now i do something like > > cd $SOURCE_ROOT > make MAKEOBJDIRPREFIX=/my_obj_tree TARGET=amd64 buildworld > > but i seem to remember that there is a more efficient way > when you want to rebuild only one program or one subtree. > I think i have seen this question being answered from time to time > but i can't find how now. > > any hints ? > There is this link from the wiki, which shows how to build/install/run emulators/wine on amd64: http://wiki.freebsd.org/Wine#Wine_on_FreeBSD.2BAC8-amd64 If there's an even more efficient way to do it, I'd love if it were documented somewhere. Glen ___ 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"
Updating /usr/src/sys to CURRENT
Hello list Freebsd is not my main OS (yet), so I'm trying to update to CURRENT to try this lists.freebsd.org/pipermail/freebsd-x11/2012-February/011445.html So I put this in my ports-supfile and updated *default release=cvs tag=. Here it says www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html "Once you have synchronized your local source tree..." OK, I synchronized the ports with csup, but now how do I synchronize /usr/src/sys with CURRENT? I still have the one that comes with 9-RELEASE. Cheers Ismael -- Do not let me induce you to satisfy my curiosity, from an expectation, that I shall gratify yours. What I may judge proper to conceal, does not concern myself alone. ___ 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: Updating /usr/src/sys to CURRENT
On Thu, Mar 01, 2012 at 12:26:38PM -0600, Ismael Farfán wrote: > Hello list > > Freebsd is not my main OS (yet), so I'm trying to update to CURRENT to try > this > lists.freebsd.org/pipermail/freebsd-x11/2012-February/011445.html > > So I put this in my ports-supfile and updated > *default release=cvs tag=. > > Here it says > www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > "Once you have synchronized your local source tree..." > OK, I synchronized the ports with csup, but now how do I synchronize > /usr/src/sys with CURRENT? > I still have the one that comes with 9-RELEASE. > What does your supfile contain? I suspect it is missing the following line: src-all tag=. Glen ___ 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: Updating /usr/src/sys to CURRENT
2012/3/1 Glen Barber : > On Thu, Mar 01, 2012 at 12:26:38PM -0600, Ismael Farfán wrote: >> Hello list >> >> Freebsd is not my main OS (yet), so I'm trying to update to CURRENT to try >> this >> lists.freebsd.org/pipermail/freebsd-x11/2012-February/011445.html >> >> So I put this in my ports-supfile and updated >> *default release=cvs tag=. >> >> Here it says >> www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html >> "Once you have synchronized your local source tree..." >> OK, I synchronized the ports with csup, but now how do I synchronize >> /usr/src/sys with CURRENT? >> I still have the one that comes with 9-RELEASE. >> > > What does your supfile contain? I suspect it is missing the following > line: > > src-all tag=. > > Glen > I'll add that and run csup again, thanks grep -v "#" /etc/ports-supfile-all *default host=cvsup13.us.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=. *default delete use-rel-suffix *default compress ports-all Also, I just found this, I don't know if there is a better way of updating src/sys http://www.rhyous.com/2009/12/25/how-to-download-freebsd-current-or-freebsd-stable-using-svn/ Regards Ismael -- Do not let me induce you to satisfy my curiosity, from an expectation, that I shall gratify yours. What I may judge proper to conceal, does not concern myself alone. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't boot with geom_part_(gpt|mbr|bsd|ebr)
I will make translation tomorrow. But you can see it by yourself, just edit your loader.conf =) 1 марта 2012 г. 20:08 пользователь Andriy Gapon написал: > on 01/03/2012 09:27 Pavel Timofeev said the following: >> Hi! >> Just add to loader.conf these options >> geom_part_gpt_load="YES" >> geom_part_bsd_load="YES" >> geom_part_ebr_load="YES" >> geom_part_mbr_load="YES" >> and your kernel can't boot > > Thank you for the report. > Could you please provide some technical information? "kernel can't boot" is a > little bit too unspecific. Any particular error messages, etc? > >> I have posted PR http://www.freebsd.org/cgi/query-pr.cgi?pr=165573 > > -- > Andriy Gapon ___ 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: Processes getting stuck in state tmpfs
Could you test the patch attached.
It's also available here as seperate commits:
https://github.com/glk/freebsd-head/commits/tmpfs-rename
Thanks,
Gleb.
On (23/02/2012 21:20), Florian Smeets wrote:
> On 11.02.12 11:20, Gleb Kurtsou wrote:
> > On (10/02/2012 22:41), Florian Smeets wrote:
> >> Hi,
> >>
> >> if you set WRKDIRPREFIX to a tmpfs mountpoint and try to build audio/gsm
> >> from ports one of the mv processes gets stuck in state tmpfs quite
> >> often. Traces from a kernel with WITTNESS and DEBUG_VFS_LOCKS are
> >> available here http://tb.smeets.im/~flo/tmpfs.txt
> >
> > It's because of incorrect vnode locking order in tmpfs_rename. Issue is
> > known and tmpfs is not the only file system suffering from it (e.g. ext2).
> >
> > There two ways of working around it in tree:
> > * UFS: try locking vnode, unlock all vnodes on failure, restart,
> > relookup vnodes needed.
> > * ZFS: introduce directory entry locks to guarantee fvp won't disappear,
> > fdvp can be safely traversed, etc. That won't be easy..
> >
> > UFS-way would be a good temporal solution, but I think we should work on
> > improving VOP_RENAME() in a long run.
> >
> > I'll try to prepare a patch in several days.
> >
>
> Hey Gleb,
>
> did you get anywhere with this?
>
> Thanks,
> Florian
>
diff --git a/sys/fs/tmpfs/tmpfs_subr.c b/sys/fs/tmpfs/tmpfs_subr.c
index d2b2245..fe596aa 100644
--- a/sys/fs/tmpfs/tmpfs_subr.c
+++ b/sys/fs/tmpfs/tmpfs_subr.c
@@ -42,6 +42,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
@@ -56,6 +57,8 @@ __FBSDID("$FreeBSD$");
#include
#include
+SYSCTL_NODE(_vfs, OID_AUTO, tmpfs, CTLFLAG_RW, 0, "tmpfs file system");
+
/* - */
/*
@@ -320,9 +323,11 @@ loop:
MPASS((node->tn_vpstate & TMPFS_VNODE_DOOMED) == 0);
VI_LOCK(vp);
TMPFS_NODE_UNLOCK(node);
- vholdl(vp);
- (void) vget(vp, lkflag | LK_INTERLOCK | LK_RETRY, curthread);
- vdrop(vp);
+ error = vget(vp, lkflag | LK_INTERLOCK, curthread);
+ if (error != 0) {
+ vp = NULL;
+ goto out;
+ }
/*
* Make sure the vnode is still there after
@@ -420,11 +425,13 @@ unlock:
out:
*vpp = vp;
- MPASS(IFF(error == 0, *vpp != NULL && VOP_ISLOCKED(*vpp)));
#ifdef INVARIANTS
- TMPFS_NODE_LOCK(node);
- MPASS(*vpp == node->tn_vnode);
- TMPFS_NODE_UNLOCK(node);
+ if (error == 0) {
+ MPASS(*vpp != NULL && VOP_ISLOCKED(*vpp));
+ TMPFS_NODE_LOCK(node);
+ MPASS(*vpp == node->tn_vnode);
+ TMPFS_NODE_UNLOCK(node);
+ }
#endif
return error;
diff --git a/sys/fs/tmpfs/tmpfs_vnops.c b/sys/fs/tmpfs/tmpfs_vnops.c
index 93fea8b..dd54679 100644
--- a/sys/fs/tmpfs/tmpfs_vnops.c
+++ b/sys/fs/tmpfs/tmpfs_vnops.c
@@ -46,6 +46,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
@@ -58,6 +59,13 @@ __FBSDID("$FreeBSD$");
#include
#include
+SYSCTL_DECL(_vfs_tmpfs);
+
+static volatile int tmpfs_rename_restarts;
+SYSCTL_INT(_vfs_tmpfs, OID_AUTO, rename_restarts, CTLFLAG_RD,
+__DEVOLATILE(int *, &tmpfs_rename_restarts), 0,
+"Times rename had to restart due to lock contention");
+
/* - */
static int
@@ -920,6 +928,118 @@ out:
/* - */
static int
+tmpfs_rename_relock(struct vnode *fdvp, struct vnode **fvpp,
+struct vnode *tdvp, struct vnode **tvpp,
+struct componentname *fcnp, struct componentname *tcnp)
+{
+ struct vnode *nvp;
+ struct mount *mp;
+ struct tmpfs_dirent *de;
+ int error;
+
+ VOP_UNLOCK(tdvp, 0);
+ if (*tvpp != NULL && *tvpp != tdvp)
+ VOP_UNLOCK(*tvpp, 0);
+ mp = fdvp->v_mount;
+
+relock:
+ atomic_add_int(&tmpfs_rename_restarts, 1);
+ error = vn_lock(fdvp, LK_EXCLUSIVE);
+ if (error)
+ goto releout;
+ if (vn_lock(tdvp, LK_EXCLUSIVE | LK_NOWAIT) != 0) {
+ VOP_UNLOCK(fdvp, 0);
+ error = vn_lock(tdvp, LK_EXCLUSIVE);
+ if (error)
+ goto releout;
+ VOP_UNLOCK(tdvp, 0);
+ goto relock;
+ }
+ /*
+* Re-resolve fvp to be certain it still exists and fetch the
+* correct vnode.
+*/
+ de = tmpfs_dir_lookup(VP_TO_TMPFS_DIR(fdvp), NULL, fcnp);
+ if (de == NULL) {
+ VOP_UNLOCK(fdvp, 0);
+ VOP_UNLOCK(tdvp, 0);
+ if ((fcnp->cn_flags & ISDOTDOT) != 0 ||
+ (fcnp->cn_namelen == 1 && fcnp->cn_nameptr[0] == '.'))
+ error = EINVAL;
+ else
+
Re: Updating /usr/src/sys to CURRENT
On Thu, Mar 01, 2012 at 01:25:15PM -0600, Ismael Farfán wrote: > > What does your supfile contain? I suspect it is missing the following > > line: > > > > src-all tag=. > > > > Glen > > > > I'll add that and run csup again, thanks > > grep -v "#" /etc/ports-supfile-all > *default host=cvsup13.us.FreeBSD.org > *default base=/var/db > *default prefix=/usr > *default release=cvs tag=. > *default delete use-rel-suffix > *default compress > ports-all > You'll also want to add 'src-all' after 'ports-all'. > > Also, I just found this, I don't know if there is a better way of > updating src/sys > http://www.rhyous.com/2009/12/25/how-to-download-freebsd-current-or-freebsd-stable-using-svn/ > I personally use svn to keep /usr/src in sync. It depends on what you are used to, I suppose. Glen ___ 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: revisiting tunables under Safe Mode menu option
On 3/1/12 8:52 AM, Devin Teske wrote: . Indeed, I've watched field engineers when exploring the menu options and their eyes light-up when they see that "Safe Mode" toggles ACPI off when enabled. Extrapolating on their surprise, they appear to have an "Aha!"-moment a ... they have all seen 'safe mode' on windows. They know what that does and they are assuming this does the same thing. Basically Windows safe mode disables all the bells and whistles of the installation and reverts to known safe defaults for everything it can reach. i.e. VGA screen, basic keyboard, IDE disk, no desktop extensions, all fancy CPU options turned off. ___ 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: revisiting tunables under Safe Mode menu option
On 3/1/12 9:13 AM, Scott Long wrote: 1. There are a number of knobs that can be manipulated to help enable a non-booting system boot, which in turn gives a system administrator a fighting chance to figure out what's wrong. ACPI is (or was) one of these options, but there are several others, and up until your re-write of the menu system, they were opaque to the user. I'd like to explore the idea of having a sub-menu that exposes these knobs and allows them to be individually controlled, but still have an upper-level option that turns them all-on or all-off for ease of use. 2. There are a ton of kenv/TUNABLE knobs in any given kernel, and many of them are useful for sysadmins, even beyond just the 'safe mode' subset. I'd like to see a post-processor run on the kernel build that collects all of the kenv knobs in that kernel and puts them into a file that can be read by the boot menu system. The system then dynamically turns these into another sub-menu of knobs that can be manipulated. So, how hard would it be to have nested sub-menus? Would (1) be something feasible to do in the near term? Would (2) be feasible to do in the long term? not only collecting stuff from am kernel build but from a running system. it would be nice fro example to be able to influence the /etc/rc.d system by disabling some functions. e.g. come up but don't turn on the window system, or networking.. We can disable a device but how about specifying a different default route than that in /etc/rc.conf? if we extract the setup tha tthe machine eventually comes up to, we can allow that to be tuned as well. Thanks, Scott ___ 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: skype-2.1.0.81,1 && problem in child proc
In article <20120301153409.GA2478@tiny> you write: > >Hello, > >I'm using skype-2.1.0.81,1 in 10-CURRENT r226986, which works fine for >chat and video calls; > >I encounter the following small problem: when a chat contains a URL one >can open that URL with a browser; it seems that skype is launching a >shell script /usr/local/bin/xdg-open which in turn tries to figure out >if the desktop is Gnome or KDE and which browser to use; it simple does >not start any browser for me; while digging into this (inserting >printf's to a log file) I see, that the script wants to launch > >kfmclient exec http://www.hallo-verlag.de/... > >with the correct URL from the chat dialog in skype but this gives an >error to stderr: > >Cannot open "/usr/lib/libv4l/v4l2convert.so" > >the shared lib exists in /compat/linux/usr/lib/libv4l/v4l2convert.so >and in /usr/local/lib/libv4l/v4l2convert.so > >$ ls -l /usr/local/lib/libv4l/v4l2convert.so >/compat/linux/usr/lib/libv4l/v4l2convert.so >-rwxr-xr-x 1 root wheel 4788 14 nov 12:52 >/compat/linux/usr/lib/libv4l/v4l2convert.so >-rwxr-xr-x 1 root wheel 5341 14 nov 07:49 >/usr/local/lib/libv4l/v4l2convert.so > >What is the matter with this and was has 'kfmclient' todo with >v4l2convert.so shared objects? I haven't really looked into this in detail but my guess is this is the Linux v4l2convert.so that is LD_PRELOAD'ed into skype for the benefit of cameras not able to provida yuv video. So I guess we'd need to prepend a wrapper for xdg-open to PATH that resets LD_PRELOAD before executing the real /usr/local/bin/xdg-open . (And btw I had to do something similar for google earth which sets LD_LIBRARY_PATH, see /usr/ports/astro/google-earth/files/browserwrapper and /usr/ports/astro/google-earth/files/patch-bin-googleearth .) Hm or should the xdg-utils port be patched to just unset LD_PRELOAD uncondtionally? I'll Cc gnome@ which is listed as maintainer for that port... Cheers, Juergen ___ 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: revisiting tunables under Safe Mode menu option
> -Original Message- > From: Julian Elischer [mailto:jul...@freebsd.org] > Sent: Thursday, March 01, 2012 1:22 PM > To: Devin Teske > Cc: 'Andriy Gapon'; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin' > Subject: Re: revisiting tunables under Safe Mode menu option > > On 3/1/12 8:52 AM, Devin Teske wrote: > > . > > Indeed, I've watched field engineers when exploring the menu options and > their > > eyes light-up when they see that "Safe Mode" toggles ACPI off when enabled. > > Extrapolating on their surprise, they appear to have an "Aha!"-moment a ... > > they have all seen 'safe mode' on windows. They know what that does and > they are assuming this does the same thing. > Basically Windows safe mode disables all the bells and whistles of the > installation > and reverts to known safe defaults for everything it can reach. > i.e. VGA screen, basic keyboard, IDE disk, no desktop extensions, all > fancy CPU options turned off. > Right, making the assumption that FreeBSD's safe mode will do the same thing as Windows' safe mode is a poor assumption. As you point out, all those things that Windows safe mode does, FreeBSD does not. X11 drivers are not affected by safe mode. Network is not affected by safe mode. Services started at boot, are not affected... So I would welcome discussions involving development of something better (and am willing to help). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: revisiting tunables under Safe Mode menu option
> -Original Message- > From: Julian Elischer [mailto:jul...@freebsd.org] > Sent: Thursday, March 01, 2012 1:28 PM > To: Scott Long > Cc: Devin Teske; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin'; > 'Andriy Gapon' > Subject: Re: revisiting tunables under Safe Mode menu option > > On 3/1/12 9:13 AM, Scott Long wrote: > > > > 1. There are a number of knobs that can be manipulated to help enable a non- > booting system boot, which in turn gives a system administrator a fighting chance > to figure out what's wrong. ACPI is (or was) one of these options, but there are > several others, and up until your re-write of the menu system, they were opaque > to the user. I'd like to explore the idea of having a sub-menu that exposes these > knobs and allows them to be individually controlled, but still have an upper-level > option that turns them all-on or all-off for ease of use. > > > > 2. There are a ton of kenv/TUNABLE knobs in any given kernel, and many of > them are useful for sysadmins, even beyond just the 'safe mode' subset. I'd like > to see a post-processor run on the kernel build that collects all of the kenv knobs > in that kernel and puts them into a file that can be read by the boot menu > system. The system then dynamically turns these into another sub-menu of > knobs that can be manipulated. > > > > So, how hard would it be to have nested sub-menus? Would (1) be something > feasible to do in the near term? Would (2) be feasible to do in the long term? > > not only collecting stuff from am kernel build but from a running system. > it would be nice fro example to be able to influence the /etc/rc.d > system by disabling some functions. > e.g. come up but don't turn on the window system, or networking.. > We can disable a device but how about specifying a different default > route than that in /etc/rc.conf? > > if we extract the setup tha tthe machine eventually comes up to, we > can allow that to be tuned as well. I'm interested in which path you would choose amongst what I've seen mentioned thus far: a. Modifying the boot menu to offer fine-grain control over each aspect of Safe Mode (wherein perhaps the Safe Mode option becomes a hook for a sub-menu rather than its current setup as an "On"/"Off" toggle). b. Keeping Safe Mode as an On/Off toggle, but shifting the fine-grain control to userland (wherein loader(8) simply sets a safemode Boolean and the user is dropped into something like single-user mode but with prompts for each feature) c. Something else. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: revisiting tunables under Safe Mode menu option
On Mar 1, 2012, at 2:39 PM, Devin Teske wrote: > > I'm interested in which path you would choose amongst what I've seen mentioned > thus far: > > a. Modifying the boot menu to offer fine-grain control over each aspect of > Safe > Mode (wherein perhaps the Safe Mode option becomes a hook for a sub-menu > rather > than its current setup as an "On"/"Off" toggle). I would favor this. "Safe Mode" (or whatever it gets renamed to) activates a sub menu with N number of knobs plus an all-on/all-off option. Scott ___ 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: revisiting tunables under Safe Mode menu option
On 3/1/12 1:35 PM, Devin Teske wrote: Right, making the assumption that FreeBSD's safe mode will do the same thing as Windows' safe mode is a poor assumption. As you point out, all those things that Windows safe mode does, FreeBSD does not. X11 drivers are not affected by safe mode. Network is not affected by safe mode. Services started at boot, are not affected... So I would welcome discussions involving development of something better (and am willing to help). but, with help from the rc people. it could.. the kenv framework gives us a much more flexible way to implement the sysV runlevels that linux inherrited. here's what I would envision: a single safe mode switch a way to control what that does (either 'safe mode' drops you to another menu which includes "boot safe mode:" and "configure safe mode" (the second one drops you to yet another menu of check boxes). the result of this is a preconfigured set of kenv entries being dumped into the kenv space. The rc system can look at the kenv space for some key entries and act accordingly. it can also SAVE to /boot/safe_mode.conf the set of kenv entries selected when safe mode is used, and the forth code can load that and use it as a default on next 'safe' mode usage. BTW do we use the forth boot stuff on all architectures? what of NFS boots? ___ 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: revisiting tunables under Safe Mode menu option
> -Original Message- > From: Scott Long [mailto:sco...@samsco.org] > Sent: Thursday, March 01, 2012 1:43 PM > To: Devin Teske > Cc: 'Julian Elischer'; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin'; > 'Andriy Gapon' > Subject: Re: revisiting tunables under Safe Mode menu option > > > On Mar 1, 2012, at 2:39 PM, Devin Teske wrote: > > > > I'm interested in which path you would choose amongst what I've seen > mentioned > > thus far: > > > > a. Modifying the boot menu to offer fine-grain control over each aspect of Safe > > Mode (wherein perhaps the Safe Mode option becomes a hook for a sub- > menu rather > > than its current setup as an "On"/"Off" toggle). > > I would favor this. "Safe Mode" (or whatever it gets renamed to) activates a sub > menu with N number of knobs plus an all-on/all-off option. How many knobs are we talking about here? I hope not more than 8, (the 9th menu being reserved for "return to main menu"). If there's going to be more than 8, then we'll have to recode "menu.4th" or envision a sub-sub-menu or start using cyclic menus, or worse... re-design menu.4th completely to allow (say) scrolling menus with infinite items (e.g., there would be an indicator at the bottom of the menu that there is more than can fit within the menu area; and pressing the down-arrow would "slide" the menu view down to the next set of items). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: gptzfsboot error using HP Smart Array P410i Controller
Hi!
This is still happening with FreeBSD 9.0-RELEASE, as I have just
discovered. The hack works like a charm, but seems kind of odd... :)
Any progress in getting a "real" fix into the repository? Any risks with
the hack - is it likely to believe that it will suddenly or sporadically
fail?
Cheers,
Palle
Christoph Hoffmann skrev:
> Hello Daniel,
>
> Last time I checked up on the issue was on the 23rd of September,
> it was not fixed then.
> I was able to to boot from drive 0x80 after adding:
>
> *** zfsboot.c.origFri Sep 23 18:03:26 2011
> --- zfsboot.c Fri Sep 23 18:47:44 2011
> ***
> *** 459,464
> --- 459,465
> heap_end = (char *) PTOV(bios_basemem);
> }
>
> + printf("Hello! I am a hack.\n");
> dsk = malloc(sizeof(struct dsk));
> dsk->drive = *(uint8_t *)PTOV(ARGS);
> dsk->type = dsk->drive & DRV_HARD ? TYPE_AD : TYPE_FD;
>
> I am inclined to think that this is related to the way how we compile this
> code,
> especially when run on the following particular processor:
>
> 1 Processor(s) detected, 4 total cores enabled, Hyperthreading is enabled
> Proc 1: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz
> QPI Speed: 5.8 GT/s.
>
>
> Regards,
>
> Christoph
>
>
> On Oct 11, 2011, at 3:16 PM, Daniel Kalchev wrote:
>
>> Has this issue been resolved somehow? Sane method to build gptzfsboot that
>> will run on HP's P410i?
>>
>> Daniel
>> ___
>> 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"
___
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"
DTrace/MIPS port
Hello, Last few weeks I've been working on DTrace port for MIPS architecture. I believe that project reached the stage when it's ready for public review/testing before going into the tree. Patch and some information could be found here: http://people.freebsd.org/~gonzo/mips/dtrace/ I'd appreciate review/testing from interested parties and if there are no major roadblocks the plan is to commit this patch sometime next week. DTrace/MIPS passes substantial part of DTrace suite on my Octeon-based board. TEST RESULTS mode: /usr/sbin/dtrace passed: 853 failed: 74 total: 927 There are some caveats/limitations though: - fbt, pid, lockstat, profile providers are not implemented - MIPS passes function arguments in registers and unless they're saved on stack the value of some might be unavailable in backtrace. So values of argN variables might be bogus sometimes. - dtrace uses kldstat(2) to get path to kernel binary and for "embedded" systems (e.g. without loader(8)) it's just "kernel" So kernel binary should be in current directory so dtrace could get CTF data from it. We need either command-line switch or env variable to let dtrace know where to look for binary. I haven't yet decided which way to go. - Not really dtrace issue, but somewhat related. FreeBSD/MIPS default kernel stacks size seems to be insufficient to load kernel modules with dependency chain longer then three modules (dtrace_test -> dtrace_all -> dtrace -> cyclic -> opensolaris) Sometimes I get kernel stack exhaustion as a combination of FS-related calls that goes down to NFS functions + WITNESS code. No proper solution for it yet. Workaround - load module one by one. - Tested only on mips64be platform. mips32be, mips32le, mips64le were not tested. Patches: dtrace-all.diff - is a cumulative patch that contains diff between HEAD branch and project branch in p4. In order to make code review easier I split it into several sub-patches based on functionality area. dtrace-ctf.diff Current version of ctfmerge assumes that target byte order is the same as host one. This patch checks byte order of ELF files being used to decide whether byte order in CTF structures' fields should be reversed. dtrace-toolchain.diff - Disable SGI compatibility for generated DWARF data. It confuses ctfconvert. - Set as(1) default ABI and target size the same as target platform dtrace-sys.diff - Kernel part of DTrace code - More intelligent kernel stack overflow handler dtrace-userland.diff - Userland part of DTrace code - Build DTrace tols as a part of toolchain build if we're cross-compiling - Various libraries' plugs for MIPS ___ 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: revisiting tunables under Safe Mode menu option
> -Original Message- > From: Julian Elischer [mailto:jul...@freebsd.org] > Sent: Thursday, March 01, 2012 1:52 PM > To: Devin Teske > Cc: 'Andriy Gapon'; freebsd-current@freebsd.org; 'Devin Teske'; 'John Baldwin' > Subject: Re: revisiting tunables under Safe Mode menu option > > On 3/1/12 1:35 PM, Devin Teske wrote: > > Right, making the assumption that FreeBSD's safe mode will do the same thing > as > > Windows' safe mode is a poor assumption. > > > > As you point out, all those things that Windows safe mode does, FreeBSD does > > not. > > > > X11 drivers are not affected by safe mode. > > > > Network is not affected by safe mode. > > > > Services started at boot, are not affected... > > > > So I would welcome discussions involving development of something better > (and am > > willing to help). > > but, with help from the rc people. it could.. > the kenv framework gives us a much more flexible way to implement the > sysV runlevels that linux inherrited. > > here's what I would envision: > > a single safe mode switch > a way to control what that does (either 'safe mode' drops you to > another menu which includes > "boot safe mode:" and "configure safe mode" (the second one drops you > to yet another menu of check boxes). > > the result of this is a preconfigured set of kenv entries being dumped > into the kenv space. > > The rc system can look at the kenv space for some key entries and act > accordingly. > it can also SAVE to /boot/safe_mode.conf the set of kenv entries > selected when safe mode is used, > and the forth code can load that and use it as a default on next > 'safe' mode usage. > > > BTW do we use the forth boot stuff on all architectures? > what of NFS boots? Glad you asked. There are architectures that don't use beastie.4th at all and thus simply fall to the autoboot sequence after handling loader.conf. These architectures lack a menu, so it would be nice if we accommodated them with (at least) allowing manual configuration through environment variables (later grabbed with kenv by the rc folks). I don't think it's beyond scope to think we couldn't cleanly implement this with (say) a well-crafted /etc/rc.d/safemode Not exactly sure what "service safemode start" should do (BSD doesn't have the same concept of runlevels as Linux does; so it's not exactly intuitive to think we could go from multi-user mode *into* safe mode). But "service safemode status" would be interesting. Interestingly, it would perhaps be nice if "service safemode stop" brought the system back to fully usable without need for reboot (something Windows doesn't offer). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: Processes getting stuck in state tmpfs
On 01.03.12 20:31, Gleb Kurtsou wrote: > Could you test the patch attached. > > It's also available here as seperate commits: > https://github.com/glk/freebsd-head/commits/tmpfs-rename > The test that used to hang within a minute has now been running successfully for almost 2 hours. Looks good to me. Florian signature.asc Description: OpenPGP digital signature
Re: how to cross-build a single application ?
On (01/03/2012 18:52), Luigi Rizzo wrote: > On Thu, Mar 01, 2012 at 12:24:13PM -0500, Alexander Kabaev wrote: > > On Thu, 1 Mar 2012 18:38:19 +0100 > > Luigi Rizzo wrote: > > > > > What is the way to properly cross-build a single program > > > (after having gone throught the 'toolchain' and possibly > > > even a full 'buildworld') > > > from the top-level directory of a FreeBSD source tree ? > > > > > > right now i do something like > > > > > > cd $SOURCE_ROOT > > > make MAKEOBJDIRPREFIX=/my_obj_tree TARGET=amd64 buildworld > > > > > > but i seem to remember that there is a more efficient way > > > when you want to rebuild only one program or one subtree. > > > I think i have seen this question being answered from time to time > > > but i can't find how now. > > > > > > any hints ? > > > > > > cheers > > > luigi > > > > > > > Something like this should work: > > > > cd src/ > > make buildenv TARGET=... > > cd usr.bin/blah > > make > > close: > > eval `make buildenvvars TARGET=... ` && cd usr.bin/blah && make There is tools/tinder.sh in src tree. > > thanks! > luigi > > > ___ > 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: flowtable usable or not
On 2/29/2012 6:01 PM, Steve Wills wrote: > On 02/29/12 13:17, K. Macy wrote: >> . >>> >>> I tried it, on both FreeBSD routers, web systems, and database >>> servers; all on 8.2+. It still causes massive instability. >>> Disabling the sysctl, and/or removing it from the kernel solved >>> the problems. > >> Routing I can believe, but I'm wondering how close attention you >> paid to the workload. There are CDN networks with high uptimes and >> shipping firewall products that use flowtable, so your mention of >> web systems forces makes me ask for specifics. > > > The failure I experienced was with web servers running 8.0 behind a F5 > load balancer in an HA setup. Whenever the failover happened, the web > servers would continue sending to the wrong MAC address, despite the > arp table updating. Disabling flowtable via the sysctl solved the > problem. Maybe Doug's failure was similar, maybe not, but I thought > I'd throw my $0.02 in. Yes, that was part of it. On the web and db systems we had what I can only describe as "general wackiness" with systems suddenly becoming unreachable, etc. This was with a moderately complex network setup with a combination of different VLANs, multiple interfaces, etc. The FreeBSD routers would just plain panic on a semi-regular interval. Removing flowtable made all this go away, and we've been quite stable since then. hth, Doug -- This .signature sanitized for your protection ___ 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: flowtable usable or not
> Yes, that was part of it. On the web and db systems we had what I can > only describe as "general wackiness" with systems suddenly becoming > unreachable, etc. This was with a moderately complex network setup with > a combination of different VLANs, multiple interfaces, etc. The FreeBSD > routers would just plain panic on a semi-regular interval. Removing > flowtable made all this go away, and we've been quite stable since then. > I understand the switch. Uptime is important in any production network. However, it seems like it may have been too easy to turn it off because no one has made any effort to help me debug the issues. By analogy your guidance for ports usability problems would be to install Ubuntu. Cheers ___ 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: SeaMonkey eats the CPU as of r232144
This is totally reproducable? Can you switch back/forth? Adrian On 29 February 2012 04:24, deeptec...@gmail.com wrote: > As of r232144, SeaMonkey (a web browser) runs rather slowly and is > constantly eating 100% CPU time. Before r232144, SeaMonkey would start > up and run faster, and when it is not in use (is idling), its CPU > usage would slowly converge to 0. > > I have a P4 processor [with HT], an r232012 world, and similarly recent ports. > ___ > 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] modular kernel config
SunOS 4.x users will love you. :-) Adrian On 1 March 2012 02:27, Nikolay Denev wrote: > On Feb 21, 2012, at 3:35 PM, Alexander Leidinger wrote: > >> Hi, >> >> I created a kernel config for i386/amd64 (should work on -current and 9.x) >> and a suitable loader.conf which: >> - tries to provide as much features as GENERIC (I lost one or two disk >> controllers, they are not available as a module... or I didn't find >> them) >> - incorporates some more features based upon a poll on stable@ >> (see below) >> - loads as much as possible as a module >> >> I've compile-tested them on i386 and amd64, but I didn't had time yet to >> give it a try on a spare machine. I may get some time next week to test >> (i386 only). It would be nice if someone could help testing: >> - compile the kernel >> - make _sure_ you have a way to recover the system in case >> the new kernel+loader.conf fails >> - verify that the example loader.conf contains all devices >> which are important for you >> - copy the example loader.conf to /boot/loader.conf >> - give it a try >> >> You can download from >> http://www.Leidinger.net/FreeBSD/current-patches/ >> The files are >> - i386_SMALL >> - i386_SMALL_loader.conf >> - amd64_SMALL >> - amd64_SMALL_loader.conf >> I didn't provide direct links for eqch one on purpose. If you do not know >> how to recover a system with an unsuitable loader.conf, don't give this a >> try (you could check a diff between GENERIC and SMALL, and make sure all >> removed devices which are imporant for you are in the loader.conf). They >> should work on -current and on 9.x, for 8.x I'm not sure if it woll work >> without removing some stuff (GENERIC on 8.x comes without some more >> debugging options, make sure you don't get surprised by them, but those may >> not be the only differences). >> >> I didn't use the name MODULAR on purpose, I've chosen a name where the first >> letter does not yet exist in the kernel config directory, to make >> tab-completion more easy. If you are not happy with the name, keep your >> opinion for yourself please, until after you tested this on a (maybe >> virtual) system. >> >> The loader.conf was generated with a script from a diff between GENERIC and >> SMALL, if there's a name mismatch between the config-name and the >> module-name, the script may have missed the module (I added some missing >> sound modules, but I may have overlooked something). You better double-check >> before giving it a try. The loader.conf is also supposed to disable some >> features (at the end of the file) which are new compared to what is in >> GENERIC, if the particular feature could cause a change in behavior. >> >> The new stuff in the kernel config compared to GENERIC is (in order of >> number of requests from users): >> - IPSEC (+ device enc + IPSEC_NAT_T) >> - ALTQ >> - SW_WATCHDOG >> - QUOTA >> - IPSTEALTH (disabled in loader.conf) >> - IPFIREWALL_FORWARD (touches every packet, power users which need >> a bigger PPS but not this feature can recompile the kernel, >> discussed with julian@) >> - FLOWTABLE (disabled in loader.conf) >> - BPF_JITTER >> >> In the poll there where some more options requested, but most of them can be >> handled via the loader or sysctl (e.g. the firewalls can be loaded as >> modules). For some of them I added some comments at the end of the SMALL >> config to make it more easy to find the correct way of configuring them. >> Doc-committers may want to have a look, maybe there's an opportunity to >> improve existing documentation. >> >> I'm interested in success reports, failure reports, and reports about >> missing stuff in loader.conf (mainly compared to the devices available in >> GENERIC, but missing stuff which could help getting a system installed and >> booted is welcome even if what you propose is not in GENERIC). >> >> Bye, >> Alexander. >> >> -- >> >> http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 >> http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 >> > > > Just an idea : Ship FreeBSD with all the kernel object files > (even compile different versions of them, let's say networking with IPFORWARD > and networking without), > and then let the user relink the kernel with some shell script. > This way freebsd-update can binary update the object files, > and then relink the users's kernel. > This of course will probably need some infrastructure work to make it > possible. > > P.S.: As I said, just an idea off the top of my head :) > > ___ > 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
if_igb crashes system
bringing up igb0 is currently causing my 10-CURRENT box to become very non-responsive (as though downclocked to some 100 KHZ...very, very, very slow). cmdwatch 'vmstat -i' shows the interrupts get assigned for igb0, and about 1 second later the machine is essentially non-responsive. anyone else seeing if_igb issues suddenly? the machine is running off a cvsup from about 75 minutes ago. I was only able to access the system after removing interface configs from rc.conf, which made me suspect polling initially, however even issuing "ifconfig igb0 up" with no media causes the issue to appear. Let me know what additional diagnostic data may help? Matt ___ 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: skype-2.1.0.81,1 && problem in child proc
El día Thursday, March 01, 2012 a las 10:13:14PM +0100, Juergen Lock escribió: > I haven't really looked into this in detail but my guess is this is > the Linux v4l2convert.so that is LD_PRELOAD'ed into skype for the > benefit of cameras not able to provida yuv video. So I guess we'd > need to prepend a wrapper for xdg-open to PATH that resets LD_PRELOAD > before executing the real /usr/local/bin/xdg-open . (And btw I had > to do something similar for google earth which sets LD_LIBRARY_PATH, > see > > /usr/ports/astro/google-earth/files/browserwrapper > > and > > /usr/ports/astro/google-earth/files/patch-bin-googleearth > > .) > > Hm or should the xdg-utils port be patched to just unset LD_PRELOAD > uncondtionally? I'll Cc gnome@ which is listed as maintainer for > that port... I've set now a hardcoded 'unset LD_PRELOAD' in /usr/local/bin/xdg-open and on click on the URL konqueror comes up fine with the URL; thanks for the hint; matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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"
