Re: freebsd-update and sources of 9.1-RC3
04.11.2012 17:55, Bas Smeelen wrote: To get the sources you can always use csup and set default release=cvs tag=RELENG_9_1 or use subversion csup will gone in 3 or 4 month, not a long-term solution I need. subversion still misses lightweight binary package like cvsup-nox11 was some time ago. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd-update and sources of 9.1-RC3
On 11/06/2012 09:21 AM, Eugene Grosbein wrote: 04.11.2012 17:55, Bas Smeelen wrote: To get the sources you can always use csup and set default release=cvs tag=RELENG_9_1 or use subversion csup will gone in 3 or 4 month, not a long-term solution I need. You're right. For now you can still use it to get the source and then keep it updated with freebsd-update subversion still misses lightweight binary package like cvsup-nox11 was some time ago. Me too. With subversion you get about 14 extra dependencies and it is not really lightweight like csup. csup will be available for the STABLE branches in the future but for how long? This e-mail message, including any attachment(s), is intended solely for the addressee or addressees. Any views or opinions presented herein are solely those of the author and do not necessarily represent those of OSE. If you are not the intended recipient of this communication please return this e-mail message and the attachment(s) to the sender and delete and destroy all copies. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: 9-Stable panic: resource_list_unreserve: can't find resource
-Original Message- From: Andriy Gapon [mailto:a...@freebsd.org] Sent: 5. november 2012 18:08 To: Tom Lislegaard Cc: freebsd-stable@FreeBSD.org; freebsd-a...@freebsd.org Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource on 05/11/2012 16:52 Tom Lislegaard said the following: -Original Message- From: Andriy Gapon [mailto:a...@freebsd.org] Sent: 5. november 2012 15:21 To: Tom Lislegaard Cc: freebsd-stable@FreeBSD.org; freebsd-a...@freebsd.org Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource on 05/11/2012 15:54 Tom Lislegaard said the following: Here's the distribution from running devd over 40 minutes 589 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU0 notify=0x81' 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU1 notify=0x81' 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU2 notify=0x81' 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU3 notify=0x81' 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU4 notify=0x81' 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU5 notify=0x81' 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU6 notify=0x81' 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU7 notify=0x81' 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=dsp4.1' 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=pts/2' 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=vboxdrv0' 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=dsp4.1' 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=vboxdrv0' Any use in running it over a longer period of time? Very interesting. So the processors get _CST change notifications rather frequently, but there is no obvious source/cause for them... Could you please send to me acpidump -dt output or upload it somewhere and post a link? Here you go https://dl.dropbox.com/u/13263820/acpidump.txt So, ACPI platform on your machine sends 0x81 notification for processors objects each time _PSR method of AC Adapter / Power Source device is queried. There could be a number of reason to invoke the method - either AC line status queries from userland (some battery / line monitoring program/applet) or internal ACPI notifications. Are you willing to go as far as recompiling your kernel with 'options ACPI_DEBUG' to get to the bottom of this issue? If yes, then please do that and also add the following lines to loader.conf: debug.acpi.layer=ACPI_EVENTS ACPI_AC_ADAPTER debug.acpi.level=ACPI_LV_INFO I would be interested in all periodically occurring ACPI debug messages (after boot is finished). No problem, I'm happy to assist in debugging this. Enabling the acpi debugging quickly fills the kernel message buffer, but it seems to be the same set of messages repeating again and again so I think this is representative https://dl.dropbox.com/u/13263820/debug_dmesg.txt And, btw, thanks for your efforts. -tom I suspect that the ACPI platform and/or embedded controller send too many notifications when they are not strictly necessary. Maybe there is a BIOS update for your machine? In any case, I am starting to work on a patch that should fix this problem without resorting to any special configuration. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd-update and sources of 9.1-RC3
Bas Smeelen b.smeelen at ose.nl writes: ... Since freebsd-update is meant to update the system I don't really see a point to make it install sources (or others things) if they are not present on the system being updated. ... But, you brought up that StrictComponents yes option and we have to figure out what it means ... From looking at the freebsd-update script (it's in /usr/sbin) I understand when StrictComponents is set to yes it skips the step, inspecting system and uses the list provided in freebsd-update.conf, so this option might save some time and disk activity. But then, after I removed /usr/src dir, it re-created it for itself just to create in there that ../release sub-dir with some documents, which looked useless to me, not to mention the fact that it attempted to install there some 20 or so other docs, but could not and failed with errors (see my test run output in earlier post). So, to me that is already a reason to ask the maintainer to look at it as it is an important utility. I don't fully understand what the impact might be when running a custom kernel. When I had src present (by my download) prior to freebsd-update upgrade, without custom kernel, without that override option (StrictComponents no), I got src updated in various places, in particular the file /usr/src/sys/conf/newvers.sh, which is OK. If you had a custom kernel and src present, then src would get updated as above, and your custom kernel would be gone, but you would be asked to rebuild your kernel manually. So, it would be convinient for you to have src ready, by manual download or override option (StrictComponents yes). ... # When upgrading between releases, should the list of Components be # read strictly (StrictComponents yes) or merely as a list of components # which *might* be installed of which FreeBSD Update should figure out # which actually are installed and upgrade those (StrictComponents no)? # StrictComponents no The components are: Components src world kernel Then what gives ? Does it not apply to src component ? When I looked at this override option, which is per default disabled, which is perfectly OK for most users, I understood it as not only saving some time on verification of current system state, but a real option to request full update of my system for components specified. This would make e.g. src download needed first time, but if that is what I wanted, it would be configurable and make sense for me and other people like the OP who actually expected it. It would make this utility fully functional, not half-baked like it is right now. jb ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.1 stability/robustness?
Someone asked about getting The DL360 G8 to boot to their intel branded pci NIC, but I cannot find that email :( At any rate, we removed the Broadcom daughterboard from the system and insured that the intel PCI NIC (i350) was bootable in the BIOS. On Sat, Nov 3, 2012 at 9:56 PM, Rick Miller vmil...@hostileadmin.com wrote: I have a blog post at http://blog.hostileadmin.com/2012/06/14/freebsd-on-hp-proliant-dl360p-g8-servers/ which touches on this. I heard as recently as today that the fixes for the BCM5719 and 5720 were recently committed to -CURRENT. It's too late for them to be rolled into 9.1. Not sure if they'll be committed to to stable/8 or not, but if so they could make it into 8.4-R. -- Take care Rick Miller ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd-update and sources of 9.1-RC3
On Tuesday, November 06, 2012 09:27:17 AM Bas Smeelen wrote: Me too. With subversion you get about 14 extra dependencies and it is not really lightweight like csup. csup will be available for the STABLE branches in the future but for how long? I'd wager that it won't be long before someone codes an extremely lightweight anon-only svnup binary that can read from an SVN server, similar to how CVSup and then csup was spawned from CVS. -- Chuck Burns brea...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Questions about amd automounter
Hi, I am running FreeBSD 9.0-RELEASE-p4 on an AMD64 box. I am playing with the amd automounter and am looking for a solution of the following problem: I would like to have a /home map similar to autofs that has both local and NIS entries. With autofs (Solaris, Linux etc.) I can say in /etc/auto.home: testuserserver:/export/home/testuser +auto_home How can I accomplish somethink similar with amd? Note that I can't put the testuser in the NIS map. Next, while testing different configurations I created a map with SUN syntax (described in the am-utils manual), but apparently the FreeBSD version of amd doesn't support it (there's clearly a lack of documentation and examples of _real-world_ scenarios): Here's the section of amd.conf: [ /xx ] sun_map_syntax = yes map_type = file map_name = /etc/amd.xx But that doesn't work: # /usr/sbin/amd -p -F /etc/amd.conf conf: unknown regular key sun_map_syntax for section /xx AMDCONF: syntax error on line 30 (section /xx) Am I doing something wrong? This is from the am-utils doc: To enable Sun-style maps in Amd, set sun_map_syntax = yes in your amd.conf file. When this flag is set in [global], all maps read by Amd are assumed to be Sun style maps. You can set this on a per map basis, thus mixing Sun-style and Amd-style maps. For more information about amd.conf please see the Amd documentation. Christian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: agp in kernel
I am using latest nvidia-driver, and GENERIC 9.1-RC3, which has agp in the kernel, and have no issues.. After a bit more posts reading , I found that people used one driver even for intel graphics: xf86-video-intel. Is it nece- ssary in case of 9.1 for hd3000? Do I have to change make.conf as a way to run kms? On 8 it was intel in xorg.conf. Should I change to i915kms now? Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mfi panic on recused on non-recusive mutex MFI I/O lock
On Tue, Nov 06, 2012 at 12:09:42AM -, Steven Hartland wrote: | Thanks Doug, actually just finished another test run with some more | debugging in and I believe I've found the reason for the non-recusive | lock and at least some of the queuing issues. | | The non-recursive lock is due to the mfi_tbolt_reset calling | mfi_process_fw_state_chg_isr with mfi_io_lock held which in turn calls | mfi_tbolt_init_MFI_queue which tries to acquire mfi_io_lock hence | the problem. | | mfi-lock.txt attached I believe fixes this as well as what appears | to be an invalid call to mtx_unlock(sc-mfi_io_lock) in mfi_attach | which never acquires the lock as far as can see, possibly a cut and | paste error. I don't seem to see the attachment. | The invalid queue problems seem to stem from the error cases of | the calls to mfi_mapcmd, some of which call mfi_release_command which | blindly sets cm_flags = 0 and then enqueues it on the free queue. Now | depending on the flow of mfi_mapcmd and where the error occurs the | command may or may not have been put on the busy queue which is going | to cause problems. | | Going to investigate this further but that's what my current theory is. | | Your patch seems quite extensive, so if could you give me brief run | down on the changes that would be most appreciated. I'll being doing that in the commit message which should happen today. | FYI, I'm aware that the cause of my underlying issues are some | hardware issues (likely cable or backplane related) but it does mean | I'm in the position to test these usually rare error cases, so wanting | the make the most of it before we get the hardware swapped out. That would be good. It makes it easier to debug things when it shows the problem. Thanks, Doug A. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mfi panic on recused on non-recusive mutex MFI I/O lock
- Original Message - From: Doug Ambrisko ambri...@ambrisko.com On Tue, Nov 06, 2012 at 12:09:42AM -, Steven Hartland wrote: | Thanks Doug, actually just finished another test run with some more | debugging in and I believe I've found the reason for the non-recusive | lock and at least some of the queuing issues. | | The non-recursive lock is due to the mfi_tbolt_reset calling | mfi_process_fw_state_chg_isr with mfi_io_lock held which in turn calls | mfi_tbolt_init_MFI_queue which tries to acquire mfi_io_lock hence | the problem. | | mfi-lock.txt attached I believe fixes this as well as what appears | to be an invalid call to mtx_unlock(sc-mfi_io_lock) in mfi_attach | which never acquires the lock as far as can see, possibly a cut and | paste error. I don't seem to see the attachment. Yer seems like some mail fail by me there, but I've had some more locking panics during todays tests anyway, requiring additional fixes. Will update and post when I'm happy with it. | The invalid queue problems seem to stem from the error cases of | the calls to mfi_mapcmd, some of which call mfi_release_command which | blindly sets cm_flags = 0 and then enqueues it on the free queue. Now | depending on the flow of mfi_mapcmd and where the error occurs the | command may or may not have been put on the busy queue which is going | to cause problems. | | Going to investigate this further but that's what my current theory is. I think I've pretty much nailed the queuing issues, there's quite a few it seems caused by inconsitent handling of calls to mfi_mapcmd as suspected. My current outstanding issue is that after adapter reset, commands are left in the queue causing constant timeouts. Hopefully this should be relatively easy to track down and fix too. | Your patch seems quite extensive, so if could you give me brief run | down on the changes that would be most appreciated. I'll being doing that in the commit message which should happen today. Cool look forward to it :) Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9-Stable panic: resource_list_unreserve: can't find resource
on 06/11/2012 10:50 Tom Lislegaard said the following: No problem, I'm happy to assist in debugging this. Enabling the acpi debugging quickly fills the kernel message buffer, but it seems to be the same set of messages repeating again and again so I think this is representative https://dl.dropbox.com/u/13263820/debug_dmesg.txt This didn't clarify things as much as I hoped, but I am inclined to think that it is polling from userland that triggers all the processor notifications. In any case, here is a patch to try: http://people.freebsd.org/~avg/acpi_cpu-stable.diff Please disable all the tunings added to loader.conf during debugging when testing this patch. The patch is a combination of two changes: 1. Do not needlessly use ever-increasing resource IDs. Rather use the IDs that are tied to Cx level IDs. Also, release previous resources upon _CST change. 2. Bind a thread that processes a processor _CST change notification to the target processor and perform _CST processing in a critical section. These should ensure the following: - the CPU doesn't enter an idle state and doesn't try to use Cx level parameters while they are being changed - Cx level parameters are never concurrently modified when multiple notifications fire in a rapid succession and multiple ACPI task threads are configured sched_bind is a heavy-weight operation, but it is OK in this context because processor notifications should not occur too often And, btw, thanks for your efforts. Thank you for all the excellent debugging and testing! P.S. I still believe that BIOS/ACPI on the machine behaves sub-optimally. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: agp in kernel
No, it's still intel in xorg.conf, you just need WITH_KMS= WITH_NEW_XORG= set in ports. -- View this message in context: http://freebsd.1045724.n5.nabble.com/agp-in-kernel-tp5758326p5758722.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang
Hello, I've ran in to this issue on two different machines, both have recent stable code. The problem appears to be with /usr/src/gnu/usr.bin/texinfo, i am using Clang to compile. Thanks. --- === gnu/usr.bin/texinfo/install-info (all) clang -O2 -pipe -mtune=native -march=native -DHAVE_CONFIG_H -DLOCALEDIR= \/usr/share/locale\ -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c gzip -cn /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/doc/install-info.1 install-info.1.gz /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c:1179:3: warning: expression result unused [-Wunused-value] bindtextdomain (PACKAGE, LOCALEDIR); ^~~ /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib/gettext.h:54:47: note: expanded from macro 'bindtextdomain' # define bindtextdomain(Domainname, Dirname) ((const char *) (Dirname)) ^ ~ /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/util/install-info.c:1180:3: warning: expression result unused [-Wunused-value] textdomain (PACKAGE); ^~~~ /usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib/gettext.h:53:34: note: expanded from macro 'textdomain' # define textdomain(Domainname) ((const char *) (Domainname)) ^ 2 warnings generated. clang -O2 -pipe -mtune=native -march=native -DHAVE_CONFIG_H -DLOCALEDIR= \/usr/share/locale\ -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/install-info/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -o install-info install-info.o /usr/obj/usr/src/gnu/usr.bin/texinfo/install-info/../libtxi/libtxi.a === gnu/usr.bin/texinfo/texindex (all) clang -O2 -pipe -mtune=native -march=native -DHAVE_CONFIG_H -DLOCALEDIR= \/usr/share/locale\ -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -c /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c gzip -cn /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/doc/texindex.1 texindex.1.gz /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c:166:3: warning: expression result unused [-Wunused-value] bindtextdomain (PACKAGE, LOCALEDIR); ^~~ /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib/gettext.h:54:47: note: expanded from macro 'bindtextdomain' # define bindtextdomain(Domainname, Dirname) ((const char *) (Dirname)) ^ ~ /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/util/texindex.c:167:3: warning: expression result unused [-Wunused-value] textdomain (PACKAGE); ^~~~ /usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib/gettext.h:53:34: note: expanded from macro 'textdomain' # define textdomain(Domainname) ((const char *) (Domainname)) ^ 2 warnings generated. clang -O2 -pipe -mtune=native -march=native -DHAVE_CONFIG_H -DLOCALEDIR= \/usr/share/locale\ -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo -I/usr/src/gnu/usr.bin/texinfo/texindex/../../../../contrib/texinfo/lib -std=gnu99 -Qunused-arguments -fstack-protector -o texindex texindex.o /usr/obj/usr/src/gnu/usr.bin/texinfo/texindex/../libtxi/libtxi.a === gnu/usr.bin/texinfo/doc (all) makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info.texi -o info.info makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info-stnd.texi -o info-stnd.info ln -fs /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texinfo.txi texinfo.texi gzip -cn info.info info.info.gz makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc texinfo.texi -o texinfo.info gzip -cn info-stnd.info info-stnd.info.gz gzip -cn texinfo.info texinfo.info.gz 1 error *** Error code 2 1 error *** Error code 2 1 error ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable
Re: agp in kernel
On Mon, Nov 5, 2012 at 5:00 PM, Zoran Kolic zko...@sbb.rs wrote: After several years I replaced desktop and laptop and wait for release to start fresh. On desktop I put nvidia gt520. Forums say nvidia prop driver dislikes agp op- tion in kernel and recommend removing it. Laptop is sandy bridge with hd3000 integrated. Would I trigger something if I delete agp from conf file in both cases? Another issue bothers me also. RC version of amdtemp failed to read temperatures on 8120. What version will be included in release? Some months ago there was a post of people taking source from current and compiling mo- dule. It worked on 8 core bulldozer. Best regards all Zoran I don't see how the AGP driver could interfere in a system that does not have any AGP hardware. The driver does not have any matching hardware to attach to so it's just unused code in memory. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: agp in kernel
I think it's historical cruft, nvidia driver had it's own agp module or something to this effect. -- View this message in context: http://freebsd.1045724.n5.nabble.com/agp-in-kernel-tp5758326p5758733.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: agp in kernel
I don't see how the AGP driver could interfere in a system that does not have any AGP hardware. The driver does not have any matching hardware to attach to so it's just unused code in memory. Sounds logical, but take a look at this post: http://www.mail-archive.com/freebsd-stable@freebsd.org/msg121942.html It is Kostik Belousov's reply. What next I have on my mind is: if I install vanilla 9.1, install intel driver, if I make xorg.conf, would it work out of the box? Is it necessary to compile from the source with KMS and NEW_XORG? Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
