Re: ZFS MFC heads down
>> Please, fix 4 times repetition of all its content in >> stable/7/cddl/compat/opensolaris/include/libshare.h. >> > > The same: > stable/7/sys/cddl/compat/opensolaris/sys/pathname.h > stable/7/sys/cddl/compat/opensolaris/sys/kidmap.h > stable/7/sys/cddl/compat/opensolaris/sys/file.h > fixed by r192523 ___ 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: ZFS MFC heads down
2009/5/21 pluknet : > 2009/5/21 Kip Macy : >> On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: >>> I will be MFC'ing the newer ZFS support some time this afternoon. Both >>> world and kernel will need to be re-built. Existing pools will >>> continue to work without upgrade. >>> >>> >>> If you choose to upgrade a pool to take advantage of new features you >>> will no longer be able to use it with sources prior to today. 'zfs >>> send/recv' is not expected to inter-operate between different pool >>> versions. >> >> >> The MFC went in r192498. Please let me know if you have any problems. > > Please, fix 4 times repetition of all its content in > stable/7/cddl/compat/opensolaris/include/libshare.h. > The same: stable/7/sys/cddl/compat/opensolaris/sys/pathname.h stable/7/sys/cddl/compat/opensolaris/sys/kidmap.h stable/7/sys/cddl/compat/opensolaris/sys/file.h -- wbr, pluknet ___ 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: ZFS MFC heads down
2009/5/21 Kip Macy : > On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: >> I will be MFC'ing the newer ZFS support some time this afternoon. Both >> world and kernel will need to be re-built. Existing pools will >> continue to work without upgrade. >> >> >> If you choose to upgrade a pool to take advantage of new features you >> will no longer be able to use it with sources prior to today. 'zfs >> send/recv' is not expected to inter-operate between different pool >> versions. > > > The MFC went in r192498. Please let me know if you have any problems. Please, fix 4 times repetition of all its content in stable/7/cddl/compat/opensolaris/include/libshare.h. Thanks! -- wbr, pluknet ___ 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: net.inet.tcp.tso=1 still neceesary with fxp was Re: TCP differences in 7.2 vs 7.1
On Wed, May 20, 2009 at 05:55:29PM -0400, Michael L. Squires wrote: > I started having speed problems after shifting from 7.1-STABLE to > 7.1-PRERELEASE. They have continued with 7.2-STABLLE. > > Reverting to the 7.1-STABLE kernel eliminated the problem. > > After downloading 7.2-STABLE from cvsup.freebsd.org at about 10:40 AM EST > on 5/20/2009, doing a buildworld/buildkernel/installkernel/installworld > cycle I still need to execute "net.inet.tcp.tso=1" to elminate throughput > problems between my home system (on Comcast) and my office PC (connected > via a Time-Warner connection). This also affects connections to other > systems; downloading Web pages (ebay.com) speeds up after I change the TSO > entry. > > The box in question runs NAT and has an fxp (Intel Pro100) interface > connected to a Comcast cable modem and an em (Intel Pro1000) interface > connected to the internal network. > > There are no network errors in "netstat -i" on either interface. > > The "if_fxp.c" code appears to be the May 7 version. > You should have cvs rev. 1.266.2.15 of if_fxp.c. > This is the dmesg entry for the card in question. The system is a dual Xeon > Supermicro 1U box, 1GB RAM, single 300GB IDE hard drive. > > fxp0: port 0xe400-0xe43f mem > 0xfebfd000-0xfebfdfff,0xfeb8-0xfeb9 irq 27 at device 7.0 on pci0 > miibus0: on fxp0 > Since you use both em(4) and fxp(4) I'd like to know which driver has the issue. Instead of disabling TSO of network stack try disabling TSO for each interface. For instance, 1. Diable TSO of em(4) and check you see the same issue (ifconfig em0 -tso). 2. Diable TSO of fxp(4) and check you see the same issue (ifconfig fxp0 -tso). ___ 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"
[releng_7 tinderbox] failure on amd64/amd64
TB --- 2009-05-20 23:21:28 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-05-20 23:21:28 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2009-05-20 23:21:28 - cleaning the object tree TB --- 2009-05-20 23:22:02 - cvsupping the source tree TB --- 2009-05-20 23:22:02 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2009-05-20 23:22:13 - building world TB --- 2009-05-20 23:22:13 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-20 23:22:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-20 23:22:13 - TARGET=amd64 TB --- 2009-05-20 23:22:13 - TARGET_ARCH=amd64 TB --- 2009-05-20 23:22:13 - TZ=UTC TB --- 2009-05-20 23:22:13 - __MAKE_CONF=/dev/null TB --- 2009-05-20 23:22:13 - cd /src TB --- 2009-05-20 23:22:13 - /usr/bin/make -B buildworld >>> World build started on Wed May 20 23:22:14 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu May 21 00:54:51 UTC 2009 TB --- 2009-05-21 00:54:51 - generating LINT kernel config TB --- 2009-05-21 00:54:51 - cd /src/sys/amd64/conf TB --- 2009-05-21 00:54:51 - /usr/bin/make -B LINT TB --- 2009-05-21 00:54:51 - building LINT kernel TB --- 2009-05-21 00:54:51 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-21 00:54:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-21 00:54:51 - TARGET=amd64 TB --- 2009-05-21 00:54:51 - TARGET_ARCH=amd64 TB --- 2009-05-21 00:54:51 - TZ=UTC TB --- 2009-05-21 00:54:51 - __MAKE_CONF=/dev/null TB --- 2009-05-21 00:54:51 - cd /src TB --- 2009-05-21 00:54:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu May 21 00:54:51 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnes ted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_kobj.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnes ted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls
Re: ZFS MFC heads down
On Wed, May 20, 2009 at 5:00 PM, Kip Macy wrote: >> Not really a problem but a question: Is the v13 on-disk format >> exactly the same as that used by Solaris/Opensolaris? > > It is supposed to be. The sources are the same. However, I have not > tested interoperability. > > >> Does this make >> it possible to have a ZFS-only dual boot system running FreeBSD-stable >> and Solaris, with a shared home directory between the two >> environments? > > It should be. > >>Has anyone tried anything like this? >> > > Google anyone? :-) My google-fu is weak today, and considering that this went into -stable a few minutes back, I didn't look that hard for v13/fbsd-stable/opensolaris adventures. :-) I'm feeling brave. I think I'll try it myself. Thanks for getting this into -stable! Navdeep > > -Kip > ___ 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: RFT: ZFS MFC
> > Unfortunately not a lot but we can do the following: > > - Donate some hardware (Fibre Channel HBAs) to the FreeBSD project (paid > from my pocket, not my employer's one); > - Donate some money (paid from my employer's pocket, if I can demonstrate > that this can help us to save big bucks on high-end storage systems); > - Detail in a very precise way all the tests that we are doing on ZFS, using > the following storage: Apple Xraid, Nexsan Sas/SATAbeast, EMC (waiting for > the final configuration) as a contribution to the FreeBSD community. > > In a few words, please let the community know what we can do in order to > make this dream come true. Contributing hardware to the cluster increases the range of platforms that FreeBSD committers can test on. I can't speak to whom or to what to contribute money - that really depends on your perceived needs. 4GB / 8GB qlogic fibre channel support is actually on its way, although I don't know the date. Cheers, Kip ___ 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: ZFS MFC heads down
> Not really a problem but a question: Is the v13 on-disk format > exactly the same as that used by Solaris/Opensolaris? It is supposed to be. The sources are the same. However, I have not tested interoperability. > Does this make > it possible to have a ZFS-only dual boot system running FreeBSD-stable > and Solaris, with a shared home directory between the two > environments? It should be. >Has anyone tried anything like this? > Google anyone? :-) -Kip ___ 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: ZFS MFC heads down
On Wed, May 20, 2009 at 4:43 PM, Kip Macy wrote: > On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: >> I will be MFC'ing the newer ZFS support some time this afternoon. Both >> world and kernel will need to be re-built. Existing pools will >> continue to work without upgrade. >> >> >> If you choose to upgrade a pool to take advantage of new features you >> will no longer be able to use it with sources prior to today. 'zfs >> send/recv' is not expected to inter-operate between different pool >> versions. > > > The MFC went in r192498. Please let me know if you have any problems. Not really a problem but a question: Is the v13 on-disk format exactly the same as that used by Solaris/Opensolaris? Does this make it possible to have a ZFS-only dual boot system running FreeBSD-stable and Solaris, with a shared home directory between the two environments? Has anyone tried anything like this? Regards, Navdeep > > Thanks, > Kip > ___ > 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" > ___ 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"
ZFS MFC heads down
On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: > I will be MFC'ing the newer ZFS support some time this afternoon. Both > world and kernel will need to be re-built. Existing pools will > continue to work without upgrade. > > > If you choose to upgrade a pool to take advantage of new features you > will no longer be able to use it with sources prior to today. 'zfs > send/recv' is not expected to inter-operate between different pool > versions. The MFC went in r192498. Please let me know if you have any problems. Thanks, Kip ___ 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: ZFS MFC heads up
On Wed, May 20, 2009 at 3:11 PM, Mike Tancsa wrote: > At 05:59 PM 5/20/2009, Kip Macy wrote: >> >> If you choose to upgrade a pool to take advantage of new features you >> will no longer be able to use it with sources prior to today. 'zfs >> send/recv' is not expected to inter-operate between different pool >> versions. > > Hi, > Thanks for working on ZFS! Is there a summary of the new features > somewhere ? > > ---Mike > Primarily what was in Pawel's commit to HEAD (see below). The following changes have also been brought in: - the recurring deadlock was fixed by deferring vinactive to a dedicated thread - zfs boot for all types now works - kmem now goes up to 512GB so arc is now limited by physmem - the arc now experiences backpressure from the vm (which can be too much - but allows ZFS to work without any tunables on amd64) Revision 185029 - (view) (annotate) - [select for diffs] Modified Mon Nov 17 20:49:29 2008 UTC (6 months ago) by pjd File length: 38244 byte(s) Diff to previous 177698 Update ZFS from version 6 to 13 and bring some FreeBSD-specific changes. This bring huge amount of changes, I'll enumerate only user-visible changes: - Delegated Administration Allows regular users to perform ZFS operations, like file system creation, snapshot creation, etc. - L2ARC Level 2 cache for ZFS - allows to use additional disks for cache. Huge performance improvements mostly for random read of mostly static content. - slog Allow to use additional disks for ZFS Intent Log to speed up operations like fsync(2). - vfs.zfs.super_owner Allows regular users to perform privileged operations on files stored on ZFS file systems owned by him. Very careful with this one. - chflags(2) Not all the flags are supported. This still needs work. - ZFSBoot Support to boot off of ZFS pool. Not finished, AFAIK. Submitted by: dfr - Snapshot properties - New failure modes Before if write requested failed, system paniced. Now one can select from one of three failure modes: - panic - panic on write error - wait - wait for disk to reappear - continue - serve read requests if possible, block write requests - Refquota, refreservation properties Just quota and reservation properties, but don't count space consumed by children file systems, clones and snapshots. - Sparse volumes ZVOLs that don't reserve space in the pool. - External attributes Compatible with extattr(2). - NFSv4-ACLs Not sure about the status, might not be complete yet. Submitted by: trasz - Creation-time properties - Regression tests for zpool(8) command. Obtained from: OpenSolaris ___ 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: So where are we at with bce and lagg then ?
> To Pete: Did you overwritten the if_bce.c/if_bcereg.h with previous > - -STABLE code or was it from 7.1-RELEASE? I am using code from a csup with the date set to 2009.03.30.23.59.59, which is immediately before the changes (the one which doesnt work is a csup with a date of 2009.03.31.23.59.59). -pete. ___ 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: ZFS MFC heads up
At 05:59 PM 5/20/2009, Kip Macy wrote: If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. Hi, Thanks for working on ZFS! Is there a summary of the new features somewhere ? ---Mike ___ 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"
ZFS MFC heads up
I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. Cheers, Kip -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ 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"
net.inet.tcp.tso=1 still neceesary with fxp was Re: TCP differences in 7.2 vs 7.1
I started having speed problems after shifting from 7.1-STABLE to 7.1-PRERELEASE. They have continued with 7.2-STABLLE. Reverting to the 7.1-STABLE kernel eliminated the problem. After downloading 7.2-STABLE from cvsup.freebsd.org at about 10:40 AM EST on 5/20/2009, doing a buildworld/buildkernel/installkernel/installworld cycle I still need to execute "net.inet.tcp.tso=1" to elminate throughput problems between my home system (on Comcast) and my office PC (connected via a Time-Warner connection). This also affects connections to other systems; downloading Web pages (ebay.com) speeds up after I change the TSO entry. The box in question runs NAT and has an fxp (Intel Pro100) interface connected to a Comcast cable modem and an em (Intel Pro1000) interface connected to the internal network. There are no network errors in "netstat -i" on either interface. The "if_fxp.c" code appears to be the May 7 version. This is the dmesg entry for the card in question. The system is a dual Xeon Supermicro 1U box, 1GB RAM, single 300GB IDE hard drive. fxp0: port 0xe400-0xe43f mem 0xfebfd000-0xfebfdfff,0xfeb8-0xfeb9 irq 27 at device 7.0 on pci0 miibus0: on fxp0 Mike Squires ___ 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: So where are we at with bce and lagg then ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 pluknet wrote: > 2009/5/19 Pete French : >> Just wondering if there was any update to this ? I seem to >> be the only one who actually has the problem, but I have >> gone as far as I can trying to diagnose it unless someone >> can send me patches to test. >> > > I guess it was fixed in -current in r191923. No it was a different problem, I just MFC'ed 191923 anyway since it do reduce the problems we have. Let's examine the code difference further, petefrench@ has narrowed the problem down into the driver code. To Pete: Did you overwritten the if_bce.c/if_bcereg.h with previous - -STABLE code or was it from 7.1-RELEASE? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoUdeQACgkQi+vbBBjt66CRjQCdF/4oHqG60BYvhW0Z2VRs3Q5K +RIAoLnz0qdovOH5z2jBn3iO529RzoEN =zi/L -END PGP SIGNATURE- ___ 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: run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config
David La Croix wrote: I experienced the same problem (same motherboard) ...both amd64 and i386 versions did the exact same thing ... I got the installer to work by going into the BIOS and disabling the onboard firewire. Well, I can confirm that disabling on-board FireWire helps (though it is workaround only which may be an issue for users of FireWire devices). Thank you, David, for the hint! M. ___ 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[2]: mountd doean`t start when ZFS is enabled.
> Perhaps there's no /etc/exports file? While exporting shared zfs file > systems doesn't require this, it looks like /etc/rc.d/mountd requires > the file to be present. > > > On May 19, 2009, at 2:33 PM, Zaphod Beeblebrox wrote: > > > 2009/5/18 Михаил Кипа > > > >> I have two servers with Identical FreeBSD7.2 system. On both I have > >> such > >> config in /etc/rc.conf: > >> rpcbind_enable="YES" > >> rpc_lockd_enable="YES" > >> rpc_statd_enable="YES" > >> nfs_client_enable="YES" > >> nfs_server_enable="YES" > >> nfs_server_flags="-u -t -n 5 -h 192.168.x.y" > >> mountd_flags="-r" > > > > > > You might also want to post the result of zfs get all | grep sharenfs > > > > Mountd can be refusing to start if there are syntax errors in those > > declarations. > > ___ > > 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 > > " > > > OK, one more time, if I have only: mountd_flags="-r" there is probled tha I described. Mountd doesn`t start with error in logs: mountd[855]: bindresvport_sa: Address already in use What does it mean?! In other word how is it posible??? But if I have: mountd_flags="-r -p 1000" anything works well. All files (/etc/export, /etc/zfs/export) are present, there is no errors in them and config files. ___ 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: failed to set mtrr: invalid argument
On Wed, 2009-05-20 at 17:26 +0200, Paul B. Mahol wrote: > On 5/20/09, Robert Noland wrote: > > On Wed, 2009-05-20 at 16:16 +0200, Paul B. Mahol wrote: > >> On 5/20/09, Robert Noland wrote: > >> > On Tue, 2009-05-19 at 16:10 -0700, Chris H wrote: > >> >> > So, zapping is off by default now in 1.6.x. If you want it, add > >> >> Option > >> >> > "DontZap" "off". The cross hatch is also gone, that is what the > >> >> -retro > >> >> > option is supposed to do. The session leader in a failsafe twm > >> >> session > >> >> > is the left hand xterm. Typing exit in that window should exit the > >> >> > session. > >> >> > >> >> DOH! Sorry. My bad. I have since determined that turning off hald && > >> >> dbus > >> >> improve performance. I built the X server with the hald option picked. > >> >> But, when I bounced the box, and started an X session (with a WM), > >> >> performance was improved. BUT. Performance pretty much sucks. I have 4 > >> >> of these boards running with the onbord (mach64) video, and the mere > >> >> 2Mb > >> >> built in RAM. They run with better performance than does this one with > >> >> (200Mhz less CPU) comparable RAM && this one has 64Mb onboard && a > >> >> faster > >> >> Gpu. But they also run 6.4-STABLE && xorg-6.9. > >> >> So, I'm going to experiment by rebuilding the X server w/o the HAL > >> >> driver - make option && untick HAL. Then portupgrade -fi xorg-server. > >> >> > >> >> I'll report back should there be any improvement. > >> > > >> > So, the use of hal or not shouldn't produce any performance difference. > >> > It is only used to detect input devices kbd/mouse. > >> > > >> > One thing that I have discovered and I'm hoping for someone to send me a > >> > patch, is that if you build xorg-server without hal support it doesn't > >> > get linked to pthread libraries. This causes issues with libdrm on > >> > Intel at least. Not sure what else may be impacted. > >> > >> I ignored this info first time, but I will ask now. Does this implies > >> that libthr is listed in Xorg ldd(1) output? > >> > >> I use server build without hal support on 945GM(irq not MSI) and I do > >> not experience problems with drm/dri/OpenGL/xv or whatever other > >> protocol you name it. > > > > Yes, if xserver is built with HAL support, I see it linked with libthr. > > If HAL is disabled, it doesn't appear to be. I'm trying to remember > > exactly what the reported issue was, but I think it was X crashing on > > exit. > > Looking at xorg-server source I did not see anything that points it > must link to libthr, perhaps HAL support makes libthr linking > mandatory. The issue crops up with libdrm-intel. libdrm is linked with pthread. I know I talked about this with kib@ a while back and we determined that the existing behavior was correct, but I think at that time we were looking at xserver linked with libthr. > X doesnt crash on exit for me, well it did before (maybe because drm > outputs ressurected *pipe disabled* message on console all the time). > Should this finnaly be replaced with DRM_DEBUG ? I changed it to a DEBUG before, it crept back in... I think I have it changed again in my current intel code. robert. -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: failed to set mtrr: invalid argument
On 5/20/09, Robert Noland wrote: > On Wed, 2009-05-20 at 16:16 +0200, Paul B. Mahol wrote: >> On 5/20/09, Robert Noland wrote: >> > On Tue, 2009-05-19 at 16:10 -0700, Chris H wrote: >> >> > So, zapping is off by default now in 1.6.x. If you want it, add >> >> Option >> >> > "DontZap" "off". The cross hatch is also gone, that is what the >> >> -retro >> >> > option is supposed to do. The session leader in a failsafe twm >> >> session >> >> > is the left hand xterm. Typing exit in that window should exit the >> >> > session. >> >> >> >> DOH! Sorry. My bad. I have since determined that turning off hald && >> >> dbus >> >> improve performance. I built the X server with the hald option picked. >> >> But, when I bounced the box, and started an X session (with a WM), >> >> performance was improved. BUT. Performance pretty much sucks. I have 4 >> >> of these boards running with the onbord (mach64) video, and the mere >> >> 2Mb >> >> built in RAM. They run with better performance than does this one with >> >> (200Mhz less CPU) comparable RAM && this one has 64Mb onboard && a >> >> faster >> >> Gpu. But they also run 6.4-STABLE && xorg-6.9. >> >> So, I'm going to experiment by rebuilding the X server w/o the HAL >> >> driver - make option && untick HAL. Then portupgrade -fi xorg-server. >> >> >> >> I'll report back should there be any improvement. >> > >> > So, the use of hal or not shouldn't produce any performance difference. >> > It is only used to detect input devices kbd/mouse. >> > >> > One thing that I have discovered and I'm hoping for someone to send me a >> > patch, is that if you build xorg-server without hal support it doesn't >> > get linked to pthread libraries. This causes issues with libdrm on >> > Intel at least. Not sure what else may be impacted. >> >> I ignored this info first time, but I will ask now. Does this implies >> that libthr is listed in Xorg ldd(1) output? >> >> I use server build without hal support on 945GM(irq not MSI) and I do >> not experience problems with drm/dri/OpenGL/xv or whatever other >> protocol you name it. > > Yes, if xserver is built with HAL support, I see it linked with libthr. > If HAL is disabled, it doesn't appear to be. I'm trying to remember > exactly what the reported issue was, but I think it was X crashing on > exit. Looking at xorg-server source I did not see anything that points it must link to libthr, perhaps HAL support makes libthr linking mandatory. X doesnt crash on exit for me, well it did before (maybe because drm outputs ressurected *pipe disabled* message on console all the time). Should this finnaly be replaced with DRM_DEBUG ? -- Paul ___ 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: failed to set mtrr: invalid argument
Quoting Robert Noland : On Wed, 2009-05-20 at 16:16 +0200, Paul B. Mahol wrote: On 5/20/09, Robert Noland wrote: > On Tue, 2009-05-19 at 16:10 -0700, Chris H wrote: >> > So, zapping is off by default now in 1.6.x. If you want it, add >> Option >> > "DontZap" "off". The cross hatch is also gone, that is what the >> -retro >> > option is supposed to do. The session leader in a failsafe twm >> session >> > is the left hand xterm. Typing exit in that window should exit the >> > session. >> >> DOH! Sorry. My bad. I have since determined that turning off hald && >> dbus >> improve performance. I built the X server with the hald option picked. >> But, when I bounced the box, and started an X session (with a WM), >> performance was improved. BUT. Performance pretty much sucks. I have 4 >> of these boards running with the onbord (mach64) video, and the mere >> 2Mb >> built in RAM. They run with better performance than does this one with >> (200Mhz less CPU) comparable RAM && this one has 64Mb onboard && a >> faster >> Gpu. But they also run 6.4-STABLE && xorg-6.9. >> So, I'm going to experiment by rebuilding the X server w/o the HAL >> driver - make option && untick HAL. Then portupgrade -fi xorg-server. >> >> I'll report back should there be any improvement. > > So, the use of hal or not shouldn't produce any performance difference. > It is only used to detect input devices kbd/mouse. > > One thing that I have discovered and I'm hoping for someone to send me a > patch, is that if you build xorg-server without hal support it doesn't > get linked to pthread libraries. This causes issues with libdrm on > Intel at least. Not sure what else may be impacted. I ignored this info first time, but I will ask now. Does this implies that libthr is listed in Xorg ldd(1) output? I use server build without hal support on 945GM(irq not MSI) and I do not experience problems with drm/dri/OpenGL/xv or whatever other protocol you name it. Yes, if xserver is built with HAL support, I see it linked with libthr. If HAL is disabled, it doesn't appear to be. I'm trying to remember exactly what the reported issue was, but I think it was X crashing on exit. I can verify that that /is/ an issue. My first experience/experiment with an nVidia card bit me this way. I built xorg w/o hal, and sure enough, every time I left X, the drives started rumbling - then I got console to see the message: xorg dumped core signal #. So I always build it with hal - whether I use it or not. :) --Chris H robert. > There is also my nouveau patch that you could try. That should get you > EXA and Xv acceleration with the nouveau driver. Overall the reports > that I've been getting have been good. > > robert. > >> Thank you very much Robert, for all your time and efforts. > -- > Robert Noland > FreeBSD > -- Robert Noland FreeBSD ___ 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: failed to set mtrr: invalid argument
Quoting Robert Noland : On Tue, 2009-05-19 at 16:10 -0700, Chris H wrote: > So, zapping is off by default now in 1.6.x. If you want it, add Option > "DontZap" "off". The cross hatch is also gone, that is what the -retro > option is supposed to do. The session leader in a failsafe twm session > is the left hand xterm. Typing exit in that window should exit the > session. DOH! Sorry. My bad. I have since determined that turning off hald && dbus improve performance. I built the X server with the hald option picked. But, when I bounced the box, and started an X session (with a WM), performance was improved. BUT. Performance pretty much sucks. I have 4 of these boards running with the onbord (mach64) video, and the mere 2Mb built in RAM. They run with better performance than does this one with (200Mhz less CPU) comparable RAM && this one has 64Mb onboard && a faster Gpu. But they also run 6.4-STABLE && xorg-6.9. So, I'm going to experiment by rebuilding the X server w/o the HAL driver - make option && untick HAL. Then portupgrade -fi xorg-server. I'll report back should there be any improvement. So, the use of hal or not shouldn't produce any performance difference. It is only used to detect input devices kbd/mouse. One thing that I have discovered and I'm hoping for someone to send me a patch, is that if you build xorg-server without hal support it doesn't get linked to pthread libraries. This causes issues with libdrm on Intel at least. Not sure what else may be impacted. Indeed, I believe my performance issues were a combination of hal, and dbus polling, and my still tweaking X. Probably not /just/ hal/dbus - tho hal /did/ add a keyboard and mouse on top of those already declared in xorg.conf :/ There is also my nouveau patch that you could try. That should get you EXA and Xv acceleration with the nouveau driver. Overall the reports that I've been getting have been good. HAH! I've already been trolling the nVidia site, and the ports page on FreeBSD - found that driver - looks interesting. But I think I'd like to start with the nVidia driver, and utilities from their site first. Thanks again for all your time and dedication. --Chris H robert. Thank you very much Robert, for all your time and efforts. -- Robert Noland FreeBSD ___ 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: failed to set mtrr: invalid argument
On Wed, 2009-05-20 at 16:16 +0200, Paul B. Mahol wrote: > On 5/20/09, Robert Noland wrote: > > On Tue, 2009-05-19 at 16:10 -0700, Chris H wrote: > >> > So, zapping is off by default now in 1.6.x. If you want it, add > >> Option > >> > "DontZap" "off". The cross hatch is also gone, that is what the > >> -retro > >> > option is supposed to do. The session leader in a failsafe twm > >> session > >> > is the left hand xterm. Typing exit in that window should exit the > >> > session. > >> > >> DOH! Sorry. My bad. I have since determined that turning off hald && > >> dbus > >> improve performance. I built the X server with the hald option picked. > >> But, when I bounced the box, and started an X session (with a WM), > >> performance was improved. BUT. Performance pretty much sucks. I have 4 > >> of these boards running with the onbord (mach64) video, and the mere > >> 2Mb > >> built in RAM. They run with better performance than does this one with > >> (200Mhz less CPU) comparable RAM && this one has 64Mb onboard && a > >> faster > >> Gpu. But they also run 6.4-STABLE && xorg-6.9. > >> So, I'm going to experiment by rebuilding the X server w/o the HAL > >> driver - make option && untick HAL. Then portupgrade -fi xorg-server. > >> > >> I'll report back should there be any improvement. > > > > So, the use of hal or not shouldn't produce any performance difference. > > It is only used to detect input devices kbd/mouse. > > > > One thing that I have discovered and I'm hoping for someone to send me a > > patch, is that if you build xorg-server without hal support it doesn't > > get linked to pthread libraries. This causes issues with libdrm on > > Intel at least. Not sure what else may be impacted. > > I ignored this info first time, but I will ask now. Does this implies > that libthr is listed in Xorg ldd(1) output? > > I use server build without hal support on 945GM(irq not MSI) and I do > not experience problems with drm/dri/OpenGL/xv or whatever other > protocol you name it. Yes, if xserver is built with HAL support, I see it linked with libthr. If HAL is disabled, it doesn't appear to be. I'm trying to remember exactly what the reported issue was, but I think it was X crashing on exit. robert. > > There is also my nouveau patch that you could try. That should get you > > EXA and Xv acceleration with the nouveau driver. Overall the reports > > that I've been getting have been good. > > > > robert. > > > >> Thank you very much Robert, for all your time and efforts. > > -- > > Robert Noland > > FreeBSD > > > > -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
On Tuesday 12 May 2009 12:10:25 pm Riccardo Torrini wrote:
> On Tue, May 12, 2009 at 11:44:20AM -0400, John Baldwin wrote:
>
> > If you can get a stack trace, that would be most helpful.
> > My guess is that the recovery thread is holding the mpt lock
> > and calling some CAM routine which attempts to relock it via
> > cam_periph_lock(). A stack trace would be most telling in
> > that case.
>
> Rebooted, inserted 2nd disk (copied by hand, sorry for delay)
Try this. It reverts the single-CCB part of the previous commit while keeping
the other fixes. I missed that the CCB might still be in flight when we
schedule another rescan.
Index: mpt_raid.c
===
--- mpt_raid.c (revision 192376)
+++ mpt_raid.c (working copy)
@@ -658,19 +658,19 @@
static void
mpt_cam_rescan_callback(struct cam_periph *periph, union ccb *ccb)
{
+
xpt_free_path(ccb->ccb_h.path);
+ xpt_free_ccb(ccb);
}
static void
mpt_raid_thread(void *arg)
{
struct mpt_softc *mpt;
- union ccb *ccb;
int firstrun;
mpt = (struct mpt_softc *)arg;
firstrun = 1;
- ccb = xpt_alloc_ccb();
MPT_LOCK(mpt);
while (mpt->shutdwn_raid == 0) {
@@ -698,15 +698,21 @@
}
if (mpt->raid_rescan != 0) {
+ union ccb *ccb;
struct cam_path *path;
int error;
mpt->raid_rescan = 0;
+ MPT_UNLOCK(mpt);
+ ccb = xpt_alloc_ccb();
+
+ MPT_LOCK(mpt);
error = xpt_create_path(&path, xpt_periph,
cam_sim_path(mpt->phydisk_sim),
CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD);
if (error != CAM_REQ_CMP) {
+ xpt_free_ccb(ccb);
mpt_prt(mpt, "Unable to rescan RAID Bus!\n");
} else {
xpt_setup_ccb(&ccb->ccb_h, path, 5);
@@ -719,7 +725,6 @@
}
}
}
- xpt_free_ccb(ccb);
mpt->raid_thread = NULL;
wakeup(&mpt->raid_thread);
MPT_UNLOCK(mpt);
--
John Baldwin
___
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: stack abuse by linux_ioctl_cdrom
on 20/05/2009 15:32 John Baldwin said the following: > On Wednesday 20 May 2009 8:09:46 am Andriy Gapon wrote: >> This is a patch that I currently use to fix the problem for myself - both 2KB >> structs are allocated on the heap. >> I am not sure what is the proper style for chained calls using chained >> if-else, >> but I think that the chaining is the best way to organize that piece of >> code, so >> that there is only one exit point from case-block to make sure that FREE is >> always >> called. > > I usually use goto for that. Error handling does seem to be one of the few > appropriate uses of goto. In this case you would basically be replacing all > the 'break's with 'goto out' or some such. Also, please do not use the > MALLOC() > or FREE() macros in new code as they are deprecated (I think they are > completely > removed in 8). I used MALLOC/FREE only because I saw that this is what was used in that file before. I will fix this. I was reluctant to use goto and label within a case block. In my personal taste that looks uglier and less safe (e.g. accidental goto from another case or from outside of switch). I would preferred goto if label was outside of switch/case. But maybe it's my personal prejudice. I will follow the style that you will recommend. -- 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: failed to set mtrr: invalid argument
On 5/20/09, Robert Noland wrote: > On Tue, 2009-05-19 at 16:10 -0700, Chris H wrote: >> > So, zapping is off by default now in 1.6.x. If you want it, add >> Option >> > "DontZap" "off". The cross hatch is also gone, that is what the >> -retro >> > option is supposed to do. The session leader in a failsafe twm >> session >> > is the left hand xterm. Typing exit in that window should exit the >> > session. >> >> DOH! Sorry. My bad. I have since determined that turning off hald && >> dbus >> improve performance. I built the X server with the hald option picked. >> But, when I bounced the box, and started an X session (with a WM), >> performance was improved. BUT. Performance pretty much sucks. I have 4 >> of these boards running with the onbord (mach64) video, and the mere >> 2Mb >> built in RAM. They run with better performance than does this one with >> (200Mhz less CPU) comparable RAM && this one has 64Mb onboard && a >> faster >> Gpu. But they also run 6.4-STABLE && xorg-6.9. >> So, I'm going to experiment by rebuilding the X server w/o the HAL >> driver - make option && untick HAL. Then portupgrade -fi xorg-server. >> >> I'll report back should there be any improvement. > > So, the use of hal or not shouldn't produce any performance difference. > It is only used to detect input devices kbd/mouse. > > One thing that I have discovered and I'm hoping for someone to send me a > patch, is that if you build xorg-server without hal support it doesn't > get linked to pthread libraries. This causes issues with libdrm on > Intel at least. Not sure what else may be impacted. I ignored this info first time, but I will ask now. Does this implies that libthr is listed in Xorg ldd(1) output? I use server build without hal support on 945GM(irq not MSI) and I do not experience problems with drm/dri/OpenGL/xv or whatever other protocol you name it. > There is also my nouveau patch that you could try. That should get you > EXA and Xv acceleration with the nouveau driver. Overall the reports > that I've been getting have been good. > > robert. > >> Thank you very much Robert, for all your time and efforts. > -- > Robert Noland > FreeBSD > -- Paul ___ 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: stack abuse by linux_ioctl_cdrom
On Wednesday 20 May 2009 8:09:46 am Andriy Gapon wrote:
>
> This is a patch that I currently use to fix the problem for myself - both 2KB
> structs are allocated on the heap.
> I am not sure what is the proper style for chained calls using chained
> if-else,
> but I think that the chaining is the best way to organize that piece of code,
> so
> that there is only one exit point from case-block to make sure that FREE is
> always
> called.
I usually use goto for that. Error handling does seem to be one of the few
appropriate uses of goto. In this case you would basically be replacing all
the 'break's with 'goto out' or some such. Also, please do not use the MALLOC()
or FREE() macros in new code as they are deprecated (I think they are completely
removed in 8).
> diff --git a/sys/compat/linux/linux_ioctl.c b/sys/compat/linux/linux_ioctl.c
> index 8e42ec1..7e3453c 100644
> --- a/sys/compat/linux/linux_ioctl.c
> +++ b/sys/compat/linux/linux_ioctl.c
> @@ -1538,23 +1538,28 @@ linux_ioctl_cdrom(struct thread *td, struct
> linux_ioctl_args *args)
> /* LINUX_CDROMAUDIOBUFSIZ */
>
> case LINUX_DVD_READ_STRUCT: {
> - l_dvd_struct lds;
> - struct dvd_struct bds;
> + l_dvd_struct *p_lds;
> + struct dvd_struct *p_bds;
>
> - error = copyin((void *)args->arg, &lds, sizeof(lds));
> - if (error)
> - break;
> - error = linux_to_bsd_dvd_struct(&lds, &bds);
> - if (error)
> - break;
> - error = fo_ioctl(fp, DVDIOCREADSTRUCTURE, (caddr_t)&bds,
> - td->td_ucred, td);
> - if (error)
> - break;
> - error = bsd_to_linux_dvd_struct(&bds, &lds);
> - if (error)
> - break;
> - error = copyout(&lds, (void *)args->arg, sizeof(lds));
> + MALLOC(p_lds, l_dvd_struct *, sizeof(*p_lds),
> + M_LINUX, M_WAITOK);
> + MALLOC(p_bds, struct dvd_struct *, sizeof(*p_bds),
> + M_LINUX, M_WAITOK);
> + if ((error = copyin((void *)args->arg, p_lds, sizeof(*p_lds)))
> + != 0)
> + ; /* nothing */
> + else if ((error = linux_to_bsd_dvd_struct(p_lds, p_bds)) != 0)
> + ; /* nothing */
> + else if ((error = fo_ioctl(fp, DVDIOCREADSTRUCTURE,
> + (caddr_t)p_bds, td->td_ucred, td)) != 0)
> + ; /* nothing */
> + else if ((error = bsd_to_linux_dvd_struct(p_bds, p_lds)) != 0)
> + ; /* nothing */
> + else
> + error = copyout(p_lds, (void *)args->arg,
> + sizeof(*p_lds));
> + FREE(p_bds, M_LINUX);
> + FREE(p_lds, M_LINUX);
> break;
> }
>
>
>
>
> --
> Andriy Gapon
>
--
John Baldwin
___
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: nv driver on Dell Latitude 830
On Wed, 2009-05-20 at 14:25 +1200, Jonathan Chen wrote: > Hi all, > > I'm running 7.2-STABLE/amd64 on a Dell 830, and have been attempting to get > XOrg working with the "nv" driver. However, it fails with: > > X.Org X Server 1.6.1 > Release Date: 2009-4-14 > X Protocol Version 11, Revision 0 > Build Operating System: FreeBSD 7.2-PRERELEASE amd64 > Current Operating System: FreeBSD jonathan.chen 7.2-STABLE FreeBSD > 7.2-STABLE #0: Tue May 19 09:24:33 NZST 2009 > r...@jonathan.chen:/usr/obj/usr/src/sys/GENERIC amd64 > Build Date: 11 May 2009 08:36:27AM > > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/var/log/Xorg.0.log", Time: Wed May 20 13:27:55 2009 > (==) Using config file: "/usr/local/etc/X11/xorg.conf" > (EE) Failed to load module "xtrap" (module does not exist, 0) > (EE) Failed to load module "freetype" (module does not exist, 0) > (EE) NV(0): Failed to determine the amount of available video memory > (EE) Screen(s) found, but none have a usable configuration. > > Fatal server error: > no screens found > > Is there any hope of getting this to work? > plain text document attachment (Xorg.0.log) > X.Org X Server 1.6.1 > Release Date: 2009-4-14 > X Protocol Version 11, Revision 0 > Build Operating System: FreeBSD 7.2-PRERELEASE amd64 > Current Operating System: FreeBSD jonathan.chen 7.2-STABLE FreeBSD 7.2-STABLE > #0: Tue May 19 09:24:33 NZST 2009 > r...@jonathan.chen:/usr/obj/usr/src/sys/GENERIC amd64 > Build Date: 11 May 2009 08:36:27AM > > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/var/log/Xorg.0.log", Time: Wed May 20 13:27:55 2009 > (==) Using config file: "/usr/local/etc/X11/xorg.conf" > (==) ServerLayout "X.org Configured" > (**) |-->Screen "Screen0" (0) > (**) | |-->Monitor "LG L1730S" > (**) | |-->Device "Card0" > (**) |-->Input Device "Mouse0" > (**) |-->Input Device "Keyboard0" > (==) Automatically adding devices > (==) Automatically enabling devices > (**) FontPath set to: > /usr/local/lib/X11/fonts/misc/, > /usr/local/lib/X11/fonts/TTF/, > /usr/local/lib/X11/fonts/OTF, > /usr/local/lib/X11/fonts/Type1/, > /usr/local/lib/X11/fonts/100dpi/, > /usr/local/lib/X11/fonts/75dpi/, > /usr/local/lib/X11/fonts/misc/, > /usr/local/lib/X11/fonts/TTF/, > /usr/local/lib/X11/fonts/OTF, > /usr/local/lib/X11/fonts/Type1/, > /usr/local/lib/X11/fonts/100dpi/, > /usr/local/lib/X11/fonts/75dpi/, > built-ins > (**) ModulePath set to "/usr/local/lib/xorg/modules" > (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' > will be disabled. > (WW) Disabling Mouse0 > (WW) Disabling Keyboard0 > (II) Loader magic: 0x3560 > (II) Module ABI versions: > X.Org ANSI C Emulation: 0.4 > X.Org Video Driver: 5.0 > X.Org XInput driver : 4.0 > X.Org Server Extension : 2.0 > (II) Loader running on freebsd > (--) Using syscons driver with X support (version 2.0) > (--) using VT number 9 > > (--) PCI:*(0...@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ > 0xfd00/16777216, 0xfa00/33554432, I/O @ 0xdf00/128, BIOS @ > 0x/65536 > (II) System resource ranges: > [0] -1 0 0x000f - 0x000f (0x1) MX[B] > [1] -1 0 0x000c - 0x000e (0x3) MX[B] > [2] -1 0 0x - 0x0009 (0xa) MX[B] > [3] -1 0 0x - 0x (0x1) IX[B] > [4] -1 0 0x - 0x00ff (0x100) IX[B] > (II) "extmod" will be loaded. This was enabled by default and also specified > in the config file. > (II) "dbe" will be loaded. This was enabled by default and also specified in > the config file. > (II) "glx" will be loaded. This was enabled by default and also specified in > the config file. > (II) "record" will be loaded. This was enabled by default and also specified > in the config file. > (II) "dri" will be loaded. This was enabled by default and also specified in > the config file. > (II) "dri2" will be loaded by default. > (II) LoadModule: "extmod" > (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so > (II) Module extmod: vendor="X.Org Foundation" > compiled for 1.6.1, module version = 1.0.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension MIT-SCREEN-SAVER > (II) Loading extension XFree86-VidModeExtension
Re: failed to set mtrr: invalid argument
On Tue, 2009-05-19 at 16:10 -0700, Chris H wrote: > > So, zapping is off by default now in 1.6.x. If you want it, add > Option > > "DontZap" "off". The cross hatch is also gone, that is what the > -retro > > option is supposed to do. The session leader in a failsafe twm > session > > is the left hand xterm. Typing exit in that window should exit the > > session. > > DOH! Sorry. My bad. I have since determined that turning off hald && > dbus > improve performance. I built the X server with the hald option picked. > But, when I bounced the box, and started an X session (with a WM), > performance was improved. BUT. Performance pretty much sucks. I have 4 > of these boards running with the onbord (mach64) video, and the mere > 2Mb > built in RAM. They run with better performance than does this one with > (200Mhz less CPU) comparable RAM && this one has 64Mb onboard && a > faster > Gpu. But they also run 6.4-STABLE && xorg-6.9. > So, I'm going to experiment by rebuilding the X server w/o the HAL > driver - make option && untick HAL. Then portupgrade -fi xorg-server. > > I'll report back should there be any improvement. So, the use of hal or not shouldn't produce any performance difference. It is only used to detect input devices kbd/mouse. One thing that I have discovered and I'm hoping for someone to send me a patch, is that if you build xorg-server without hal support it doesn't get linked to pthread libraries. This causes issues with libdrm on Intel at least. Not sure what else may be impacted. There is also my nouveau patch that you could try. That should get you EXA and Xv acceleration with the nouveau driver. Overall the reports that I've been getting have been good. robert. > Thank you very much Robert, for all your time and efforts. -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: nv driver on Dell Latitude 830
Quoting Chris H : Greetings... Quoting Jonathan Chen : Hi all, I'm running 7.2-STABLE/amd64 on a Dell 830, and have been attempting to get XOrg working with the "nv" driver. However, it fails with: X.Org X Server 1.6.1 Release Date: 2009-4-14 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.2-PRERELEASE amd64 Current Operating System: FreeBSD jonathan.chen 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue May 19 09:24:33 NZST 2009 r...@jonathan.chen:/usr/obj/usr/src/sys/GENERIC amd64 Build Date: 11 May 2009 08:36:27AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed May 20 13:27:55 2009 (==) Using config file: "/usr/local/etc/X11/xorg.conf" (EE) Failed to load module "xtrap" (module does not exist, 0) (EE) Failed to load module "freetype" (module does not exist, 0) (EE) NV(0): Failed to determine the amount of available video memory (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found Is there any hope of getting this to work? Yes there is, and you'll be happy to know I just got done smooting my X install out - just in time to try using the latest driver from the nVidia site (but that's a story for another time). To the point; to best serve you, one will need to see the output from /var/log/Xorg.0.log, and a copy of your xorg.conf file. Without this EDIT That /should/ have read /var/run/dmesg.boot information /nobody/ can posibly know where you/it went wrong. You would do well to search the posts I made yesterday in a thread. Search for mtrr: invalid argument. I posted all the info you already should have. ;) But you'll see a good example to get some ideas for your own. Have fun. --Chris out... -- Jonathan Chen Solnet Solutions LimitedT: +64 9 9775800 Level 7, Brookfields House, F: +64 9 9775801 19 Victoria Street, DDI: +64 9 9775871 PO Box 6619,M: +64 21 635618 Auckland 1141, New Zealand http://www.solnetsolutions.co.nz/ Attention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or postmas...@solnetsolutions.co.nz as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd. ___ 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" ___ 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: nv driver on Dell Latitude 830
Greetings... Quoting Jonathan Chen : Hi all, I'm running 7.2-STABLE/amd64 on a Dell 830, and have been attempting to get XOrg working with the "nv" driver. However, it fails with: X.Org X Server 1.6.1 Release Date: 2009-4-14 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.2-PRERELEASE amd64 Current Operating System: FreeBSD jonathan.chen 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue May 19 09:24:33 NZST 2009 r...@jonathan.chen:/usr/obj/usr/src/sys/GENERIC amd64 Build Date: 11 May 2009 08:36:27AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed May 20 13:27:55 2009 (==) Using config file: "/usr/local/etc/X11/xorg.conf" (EE) Failed to load module "xtrap" (module does not exist, 0) (EE) Failed to load module "freetype" (module does not exist, 0) (EE) NV(0): Failed to determine the amount of available video memory (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found Is there any hope of getting this to work? Yes there is, and you'll be happy to know I just got done smooting my X install out - just in time to try using the latest driver from the nVidia site (but that's a story for another time). To the point; to best serve you, one will need to see the output from /var/log/Xorg.0.log, and a copy of your xorg.conf file. Without this information /nobody/ can posibly know where you/it went wrong. You would do well to search the posts I made yesterday in a thread. Search for mtrr: invalid argument. I posted all the info you already should have. ;) But you'll see a good example to get some ideas for your own. Have fun. --Chris out... -- Jonathan Chen Solnet Solutions LimitedT: +64 9 9775800 Level 7, Brookfields House, F: +64 9 9775801 19 Victoria Street, DDI: +64 9 9775871 PO Box 6619,M: +64 21 635618 Auckland 1141, New Zealand http://www.solnetsolutions.co.nz/ Attention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or postmas...@solnetsolutions.co.nz as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd. ___ 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: stack abuse by linux_ioctl_cdrom
This is a patch that I currently use to fix the problem for myself - both 2KB
structs are allocated on the heap.
I am not sure what is the proper style for chained calls using chained if-else,
but I think that the chaining is the best way to organize that piece of code, so
that there is only one exit point from case-block to make sure that FREE is
always
called.
diff --git a/sys/compat/linux/linux_ioctl.c b/sys/compat/linux/linux_ioctl.c
index 8e42ec1..7e3453c 100644
--- a/sys/compat/linux/linux_ioctl.c
+++ b/sys/compat/linux/linux_ioctl.c
@@ -1538,23 +1538,28 @@ linux_ioctl_cdrom(struct thread *td, struct
linux_ioctl_args *args)
/* LINUX_CDROMAUDIOBUFSIZ */
case LINUX_DVD_READ_STRUCT: {
- l_dvd_struct lds;
- struct dvd_struct bds;
+ l_dvd_struct *p_lds;
+ struct dvd_struct *p_bds;
- error = copyin((void *)args->arg, &lds, sizeof(lds));
- if (error)
- break;
- error = linux_to_bsd_dvd_struct(&lds, &bds);
- if (error)
- break;
- error = fo_ioctl(fp, DVDIOCREADSTRUCTURE, (caddr_t)&bds,
- td->td_ucred, td);
- if (error)
- break;
- error = bsd_to_linux_dvd_struct(&bds, &lds);
- if (error)
- break;
- error = copyout(&lds, (void *)args->arg, sizeof(lds));
+ MALLOC(p_lds, l_dvd_struct *, sizeof(*p_lds),
+ M_LINUX, M_WAITOK);
+ MALLOC(p_bds, struct dvd_struct *, sizeof(*p_bds),
+ M_LINUX, M_WAITOK);
+ if ((error = copyin((void *)args->arg, p_lds, sizeof(*p_lds)))
+ != 0)
+ ; /* nothing */
+ else if ((error = linux_to_bsd_dvd_struct(p_lds, p_bds)) != 0)
+ ; /* nothing */
+ else if ((error = fo_ioctl(fp, DVDIOCREADSTRUCTURE,
+ (caddr_t)p_bds, td->td_ucred, td)) != 0)
+ ; /* nothing */
+ else if ((error = bsd_to_linux_dvd_struct(p_bds, p_lds)) != 0)
+ ; /* nothing */
+ else
+ error = copyout(p_lds, (void *)args->arg,
+ sizeof(*p_lds));
+ FREE(p_bds, M_LINUX);
+ FREE(p_lds, M_LINUX);
break;
}
--
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: RFT: ZFS MFC
On 20 May 2009, at 1:01, Kip Macy wrote: I would recommend that you use the ZFS_MFC branch - it is the same as what will be in RELENG_7 tomorrow afternoon. This is great news, and given the testing it should be no problem I feel... After setting vm.kmem_size to the recommended minimum I ran buildworld (which resides on a compressed zfs volume) while doing some ufs -> zfs and v.v. rsyncs. This was on FreeBSD/amd64 inside VMWare fusion using both v6 and v13 on the zpool (single device, no mirroring/raid) Thanks for all the hard work! Regards, Ruben ___ 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: run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config
I experienced the same problem (same motherboard) ...both amd64 and i386 versions did the exact same thing ... I got the installer to work by going into the BIOS and disabling the onboard firewire. On Tue, May 12, 2009 at 4:32 PM, martinko wrote: > Dan Nelson wrote: >> >> In the last episode (May 12), martinko said: >>> >>> I've just tried 7.2-RELEASE (amd64) on Asus M3A78-EM motherboard and >>> booting got stuck with the following: >>> >>> run_interrupt_driven_hooks: still waiting after 300 seconds for >>> xpt_config >>> >>> From what I've found via Google it should be fixed already but apparently >>> it is not. :-( >>> >>> Is there a way to work around this issue and successfully boot and >>> install >>> FreeBSD, please ? >> >> Do you have a connected firewire device? Try unplugging it during bootup, >> or kldload the sbp module after bootup instead of via loader.conf. >> > > This is booting on fresh new computer from DVD installation media. > And nothing is attached (except USB keyboard and VGA monitor;)). > > Btw, I've just tried booting recent PC-BSD (7.1) from USB drive but it > failed the same way, unfortunately. > > Any other ideas how to install FreeBSD on this system, please ? > > Cheers, > > Martin > > ___ > 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" > ___ 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: Unable to read from CCID USB reader
On Tuesday 19 May 2009, Mario Pavlov wrote: > Hi, > I tired CURRENT and it's working for me :) > I only have one small issue... > when I unplug the reader pcscd goes to some sort of infinite loop > it would print this forever: > > 48111939 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb//dev/ugen4.2): > Device busy 0020 ifdwrapper.c:469:IFDStatusICC() Card not transacted: > 612 > 0010 eventhandler.c:333:EHStatusHandlerThread() Error communicating to: > ACS ACR 38U-CCID 00 00 00402930 ccid_usb.c:491:WriteUSB() > usb_bulk_write(/dev/usb//dev/ugen4.2): Device not configured 0021 > ifdwrapper.c:469:IFDStatusICC() Card not transacted: 612 > 0010 eventhandler.c:333:EHStatusHandlerThread() Error communicating to: > ACS ACR 38U-CCID 00 00 00402953 ccid_usb.c:491:WriteUSB() > usb_bulk_write(/dev/usb//dev/ugen4.2): Device not configured 0016 > ifdwrapper.c:469:IFDStatusICC() Card not transacted: 612 > 0010 eventhandler.c:333:EHStatusHandlerThread() Error communicating to: > ACS ACR 38U-CCID 00 00 ... Maybe a bug in the pcsc driver. > ... > ... > > firefox does almost the same thing: > > [opensc-pkcs11] reader-pcsc.c:1015:pcsc_detect_readers: returning with: No > readers found [opensc-pkcs11] reader-pcsc.c:906:pcsc_detect_readers: > SCardEstablishContext failed: 0x8010001d [opensc-pkcs11] > reader-pcsc.c:1015:pcsc_detect_readers: returning with: No readers found > [opensc-pkcs11] reader-pcsc.c:906:pcsc_detect_readers: > SCardEstablishContext failed: 0x8010001d [opensc-pkcs11] > reader-pcsc.c:1015:pcsc_detect_readers: returning with: No readers found > ... > ... > ... > > I guess this is not FreeBSD's fault, is it ? If the usb device /dev/usb/xxx for your device is not accessible to firefox then firefox can't open it. --HPS ___ 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"
