Re: 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 " ___ 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"
nv driver on Dell Latitude 830
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? -- 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. 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 s
Re: failed to set mtrr: invalid argument
Quoting Robert Noland : On Tue, 2009-05-19 at 13:52 -0700, Chris H wrote: Quoting Robert Noland : > On Tue, 2009-05-19 at 11:47 -0700, Chris H wrote: >> Quoting Chris H : >> >> > Quoting Laurent Grangeau : >> > >> >> I think I can handle this answer. >> >> >> >> This is the default behavior of Xorg 7.4. If you want to see the old >> >> screen, launch Xorg with the -retro option. >> >> The command should be like this : >> >> X -config xorg.conf.new -retro >> >> >> >> If your mouse or your keyboard doesn't seem to work, look if you >> >> have enable dbus and hald. In your /etc/rc.conf, you should have >> >> dbus_enable="YES" and hald_enable="YES" (I'm not sure about this). >> >> >> >> All this is explain in the handbook : Configuring X11. >> > >> > Hello Laurent, and thank you for your reply. >> > >> > For the record, this is the way I /first/ attempted to do it - >> > >> > echo 'enable_hald="YES"' >> /etc/rc.conf >> > echo 'enable_dbus="YES"' >> /etc/rc.conf >> > >> > Bounce the box >> > attempt to test Xorg: >> > >> > Xorg -config /root/xorg.conf.new >> > >> > no joy. >> > >> > So I tweaked the file (removing the card I wasn't going to use). >> > Save the remaining as /etc/X11/xorg.conf.nvidia && >> > >> > Xorg -config /etc/X11/xorg.conf.nvidia >> > >> > But again, "no joy". >> > >> > I'll try it again, and report back with my findings. >> > >> > Thanks again for your response. >> > >> > --Chris H >> >> OK here's the results: >> >> echo 'hald_enable="YES"' >> /etc/rc.conf >> echo 'enable_dbus="YES"' >> /etc/rc.conf >> >> bounce the box >> >> Xorg -config /etc/X11/xorg.conf.nvidia >> >> returns the following: >> >> X.Org X Server 1.6.0 >> Release Date: 2009-2-25 >> X Protocol Version 11, Revision 0 >> Build Operating System: FreeBSD 7.1-RELEASE i386 Current Operating ---8<--[BIG SNIP]--8<--- >> (**) Option "DataBits" "8" >> (**) Option "Parity" "None" >> (**) Option "Vmin" "1" >> (**) Option "Vtime" "0" >> (**) Option "FlowControl" "None" >> >> An attempt to bail out of X on tty8 (ctl-alt-backspace) >> returns: >> Failed to switch consoles (Invalid argument) >> on tty0 >> >> Attempting again returns: >> Failed to switch consoles (Invalid argument) >> on tty0 >> >> move to tty0 (ctl-alt-f1) && ctl-C >> >> OK let's try the -retro switch on the Xorg created conf... >> >> --- >> >> Xorg -config xorg.conf.new -retro >> provides: >> >> X.Org X Server 1.6.0 >> Release Date: 2009-2-25 >> X Protocol Version 11, Revision 0 >> Build Operating System: FreeBSD 7.1-RELEASE i386 Current Operating >> System: FreeBSD udns.ultimatedns.NET 7.1-RELEASE FreeBSD 7.1-RELEASE >> #0: Thu Jan 1 14:37:25 UTC 2009 >> r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >> Build Date: 16 May 2009 07:15:01AM >> >>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: Tue May 19 11:33:40 2009 >> (++) Using config file: "/etc/X11/xorg.conf.new" >> (==) ServerLayout "X.org Configured" >> (**) |-->Screen "Screen0" (0) >> (**) | |-->Monitor "Monitor0" >> (**) | |-->Device "Card0" >> (**) |-->Screen "Screen1" (1) >> (**) | |-->Monitor "Monitor1" >> (**) | |-->Device "Card1" >> (**) |-->Input Device "Mouse0" >> (**) |-->Input Device "Keyboard0" >> (==) Automatically adding devices ---8<--[BIG SNIP]--8<--- >> (II) Module int10: vendor="X.Org Foundation" >>compiled for 1.6.0, module version = 1.0.0 >>ABI class: X.Org Video Driver, version 5.0 >> (==) MACH64(0): Write-combining range (0xa,0x2) was already clear >> (==) MACH64(0): Write-combining range (0xc,0x4) was already clear >> >> >> Which only leaves me with a blinking block cursor in the upper >> LEFT-hand corner while hooked up to the NV card. There is no >> output to the MACH64. >> >> I don't think this is the answer. > > Hrm, ok... It might still be getting confused by the ati card... The > issue comes down to which card (hopefully not both) is handling legacy > vga calls to 0xc. I did just notice someone else post an issue with > the openchrome driver and int10 though, so you might try disabling > int10. > > robert. Hello Robert, and thank you for your reply. I apologize, but am not exactly sure how to do this. The following: SubSection "int10" Option"omit int10" # don't initialise openchrome extension EndSubSection didn't do it. :( man xorg.conf Option "NoInt10" "boolean" Disables the Int10 module, a module that uses the int10 call to the BIOS of the graphics card to initialize it. Default: false. In my humble defence, I have had the xorg man page open the entire time. But wasn't able to discover it. Thanks for the pointer. :) --Chris H robert. --C
Re: RFT: ZFS MFC
On Tue, 19 May 2009, Kip Macy wrote: KM> > Ah well, Kip, thank you for all of your support. KM> > KM> > Then, what would you offer for releng_7 users to test your changes? I'm more KM> > than happy to test, and I'm ready to be unvolved in some clashes resolved, KM> > but... KM> > KM> > Anyway, thank you for all your efforts you put there! KM> > KM> KM> I would recommend that you use the ZFS_MFC branch - it is the same as KM> what will be in RELENG_7 tomorrow afternoon. Well, then I'll keep my energy for a day or two, escaping from painful SVN->CVS mass merges ;-) Thanks again. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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 Tue, 2009-05-19 at 13:52 -0700, Chris H wrote: > Quoting Robert Noland : > > > On Tue, 2009-05-19 at 11:47 -0700, Chris H wrote: > >> Quoting Chris H : > >> > >> > Quoting Laurent Grangeau : > >> > > >> >> I think I can handle this answer. > >> >> > >> >> This is the default behavior of Xorg 7.4. If you want to see the old > >> >> screen, launch Xorg with the -retro option. > >> >> The command should be like this : > >> >> X -config xorg.conf.new -retro > >> >> > >> >> If your mouse or your keyboard doesn't seem to work, look if you > >> >> have enable dbus and hald. In your /etc/rc.conf, you should have > >> >> dbus_enable="YES" and hald_enable="YES" (I'm not sure about this). > >> >> > >> >> All this is explain in the handbook : Configuring X11. > >> > > >> > Hello Laurent, and thank you for your reply. > >> > > >> > For the record, this is the way I /first/ attempted to do it - > >> > > >> > echo 'enable_hald="YES"' >> /etc/rc.conf > >> > echo 'enable_dbus="YES"' >> /etc/rc.conf > >> > > >> > Bounce the box > >> > attempt to test Xorg: > >> > > >> > Xorg -config /root/xorg.conf.new > >> > > >> > no joy. > >> > > >> > So I tweaked the file (removing the card I wasn't going to use). > >> > Save the remaining as /etc/X11/xorg.conf.nvidia && > >> > > >> > Xorg -config /etc/X11/xorg.conf.nvidia > >> > > >> > But again, "no joy". > >> > > >> > I'll try it again, and report back with my findings. > >> > > >> > Thanks again for your response. > >> > > >> > --Chris H > >> > >> OK here's the results: > >> > >> echo 'hald_enable="YES"' >> /etc/rc.conf > >> echo 'enable_dbus="YES"' >> /etc/rc.conf > >> > >> bounce the box > >> > >> Xorg -config /etc/X11/xorg.conf.nvidia > >> > >> returns the following: > >> > >> X.Org X Server 1.6.0 > >> Release Date: 2009-2-25 > >> X Protocol Version 11, Revision 0 > >> Build Operating System: FreeBSD 7.1-RELEASE i386 Current Operating > > ---8<--[BIG SNIP]--8<--- > > >> (**) Option "DataBits" "8" > >> (**) Option "Parity" "None" > >> (**) Option "Vmin" "1" > >> (**) Option "Vtime" "0" > >> (**) Option "FlowControl" "None" > >> > >> An attempt to bail out of X on tty8 (ctl-alt-backspace) > >> returns: > >> Failed to switch consoles (Invalid argument) > >> on tty0 > >> > >> Attempting again returns: > >> Failed to switch consoles (Invalid argument) > >> on tty0 > >> > >> move to tty0 (ctl-alt-f1) && ctl-C > >> > >> OK let's try the -retro switch on the Xorg created conf... > >> > >> --- > >> > >> Xorg -config xorg.conf.new -retro > >> provides: > >> > >> X.Org X Server 1.6.0 > >> Release Date: 2009-2-25 > >> X Protocol Version 11, Revision 0 > >> Build Operating System: FreeBSD 7.1-RELEASE i386 Current Operating > >> System: FreeBSD udns.ultimatedns.NET 7.1-RELEASE FreeBSD 7.1-RELEASE > >> #0: Thu Jan 1 14:37:25 UTC 2009 > >> r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > >> Build Date: 16 May 2009 07:15:01AM > >> > >>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: Tue May 19 11:33:40 2009 > >> (++) Using config file: "/etc/X11/xorg.conf.new" > >> (==) ServerLayout "X.org Configured" > >> (**) |-->Screen "Screen0" (0) > >> (**) | |-->Monitor "Monitor0" > >> (**) | |-->Device "Card0" > >> (**) |-->Screen "Screen1" (1) > >> (**) | |-->Monitor "Monitor1" > >> (**) | |-->Device "Card1" > >> (**) |-->Input Device "Mouse0" > >> (**) |-->Input Device "Keyboard0" > >> (==) Automatically adding devices > > ---8<--[BIG SNIP]--8<--- > > >> (II) Module int10: vendor="X.Org Foundation" > >>compiled for 1.6.0, module version = 1.0.0 > >>ABI class: X.Org Video Driver, version 5.0 > >> (==) MACH64(0): Write-combining range (0xa,0x2) was already clear > >> (==) MACH64(0): Write-combining range (0xc,0x4) was already clear > >> > >> > >> Which only leaves me with a blinking block cursor in the upper > >> LEFT-hand corner while hooked up to the NV card. There is no > >> output to the MACH64. > >> > >> I don't think this is the answer. > > > > Hrm, ok... It might still be getting confused by the ati card... The > > issue comes down to which card (hopefully not both) is handling legacy > > vga calls to 0xc. I did just notice someone else post an issue with > > the openchrome driver and int10 though, so you might try disabling > > int10. > > > > robert. > > Hello Robert, and thank you for your reply. > > I apologize, but am not exactly sure how to do this. The following: > > SubSection "int10" > Option"omit int10" # don't initialise openchrome extension > EndSubSection > > didn't do it. :( man xorg.conf Option "NoInt10" "boolean" Disables the Int10 module, a module that uses the int10 cal
Re: RFT: ZFS MFC
On Tue, May 19, 2009 at 4:00 PM, Dmitry Morozovsky wrote: > On Tue, 19 May 2009, Kip Macy wrote: > > KM> I created a branch for a reason. With all the renames applying a patch > KM> is a nightmare. Either use the branch or wait until I do the MFC. > > Ah well, Kip, thank you for all of your support. > > Then, what would you offer for releng_7 users to test your changes? I'm more > than happy to test, and I'm ready to be unvolved in some clashes resolved, > but... > > Anyway, thank you for all your efforts you put there! > I would recommend that you use the ZFS_MFC branch - it is the same as what will be in RELENG_7 tomorrow afternoon. 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: failed to set mtrr: invalid argument
On Tue, 2009-05-19 at 13:14 -0700, Chris H wrote: > Hello Robert, and thank you for taking the time to respond. > > Quoting Robert Noland : > > > On Tue, 2009-05-19 at 09:57 -0700, Chris H wrote: > >> Quoting Dimitry Andric : > >> > >> > On 2009-05-19 08:40, Chris H wrote: > >> >> I see. Well I'm specifically using the nv driver. Here's another > >> >> attempt to provide the relevant info: > >> > > >> > I could not find the error message from $subject in these logs. Where > >> > is it? :) > >> > >> If I had found it, I would have better known what direction to travel > >> to overcome it. :) > >> Aparently Xorg wants to keep it a secret - I saw no "argument". > > > > This isn't actually Xorg per se... It is when we attempt to set an MTRR > > range via ioctl on /dev/mem. The ultimate return value is EINVAL which > > just gets displayed as invalid argument. > > > >> The closest possible answer I can come up with, involves "write combining" > >> and provinding some information in /proc/mtrr > >> But I only have /proc and nothing in it. Thought about echo(1)ing > >> the information to mtrr. But don't understand the whole thing well > >> enough to /dare/ do it. I only know it involves something in this > >> area: > >> > >> 0xfd00/16777216, 0xf000/134217728, 0xfa58/524288 > >> > >> out of the Xorg log. I'm also not sure if GENERIC knows how to handle > >> mtrr (Memory Type Range Registers) ideally. I hadn't built world/kernel > >> yet because there are also some issues on the ATA ports that need to be > >> resolved. I started a theread on this earlier. > >> > >> Thank you for taking the time to respond. > > > > You can do a "memcontrol list" which will display the memory regions and > > their caching method. Likely what you will find is a "global" MTRR > > which is set to write-back. > I always set "write-back" in the BIOS, as it then gets marked "dirty", > and the CPU cache will get processed accordingly. > > We don't have the ability to split regions > > and we aren't allowed to overlap write-combine on top of write-back, so > > any attempt to set MTRR will fail. The specific failure is most likely > > when X tries to set write-combine on the framebuffer, which in your case > > looks like 0xf000/134217728. > > > > Again, this shouldn't prevent X from working... It is just a > > performance issue. > > My investigations on this have led me to believe that Linux can address > (allow) write-combining via their version of sysctl (so to speak). > The article I found this reference was here: > http://www.mplayerhq.hu/DOCS/HTML/en/mtrr.html > > Do we (does FreeBSD) have this ability? Or will we? > > I also found some good information on write combining here: > http://www.meduna.org/txt_mtrr_en.html > > This box can be used as a "guinea pig" if you would like. > > Thanks again Robert, for all your time and efforts. Linux may have the ability to split regions, I'm really not sure. We can manipulate memory ranges using memcontrol, but if you have a global set to write-back like both of my newer bios's do, then you would have to remove that and then manually split the regions to allow a non-overlapping write-combined region. I generally lock up the machine when I have tried that though. robert. > --Chris H > > > > > robert. > > > >> --Chris H > >> > >> > > >> > >> > >> > >> ___ > >> 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" > > -- > > 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" -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: RFT: ZFS MFC
On Tue, 19 May 2009, Kip Macy wrote: KM> I created a branch for a reason. With all the renames applying a patch KM> is a nightmare. Either use the branch or wait until I do the MFC. Ah well, Kip, thank you for all of your support. Then, what would you offer for releng_7 users to test your changes? I'm more than happy to test, and I'm ready to be unvolved in some clashes resolved, but... Anyway, thank you for all your efforts you put there! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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
I created a branch for a reason. With all the renames applying a patch is a nightmare. Either use the branch or wait until I do the MFC. Cheers, Kip On Tue, May 19, 2009 at 3:49 PM, Dimitry Andric wrote: > On 2009-05-19 23:57, Dmitry Morozovsky wrote: >> ... but then again, on `build all'' phase, I got >> >> ===> cddl/sbin/zpool (all) >> cc -O2 -fno-strict-aliasing -pipe -march=athlon-mp >> -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzpool/common >> -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/include >> -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/lib/libumem >> -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/compat/opensolaris >> -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/head >> -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libuutil/common >> -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libumem/common >> -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzfs/common >> -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libnvpair >> -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/common/zfs >> -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common >> -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs >> -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys >> -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -o zpool zpool_main.o >> zpool_vdev.o zpool_iter.o zpool_util.o -lavl -lzfs -lgeom -lbsdxml -lsbuf >> -lm >> -lnvpair -luutil -lutil >> zpool_main.o(.text+0x61ff): In function `zpool_do_create': >> : undefined reference to `zfs_allocatable_devs' >> *** Error code 1 > > FWIW, I just did a full buildworld, kernel, reboot, installworld dance, > there were no errors. You may possibly have some cruft left in obj, or > you could zap your src tree and start fresh? :) > ___ > 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" > -- 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"
Re: RFT: ZFS MFC
On 2009-05-19 23:57, Dmitry Morozovsky wrote: > ... but then again, on `build all'' phase, I got > > ===> cddl/sbin/zpool (all) > cc -O2 -fno-strict-aliasing -pipe -march=athlon-mp > -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzpool/common > > -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/include > -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/lib/libumem > -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/compat/opensolaris > -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/head > -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libuutil/common > > -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libumem/common > > -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzfs/common > > -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libnvpair > -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/common/zfs > -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common > -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs > > -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys > > -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -o zpool zpool_main.o > zpool_vdev.o zpool_iter.o zpool_util.o -lavl -lzfs -lgeom -lbsdxml -lsbuf > -lm > -lnvpair -luutil -lutil > zpool_main.o(.text+0x61ff): In function `zpool_do_create': > : undefined reference to `zfs_allocatable_devs' > *** Error code 1 FWIW, I just did a full buildworld, kernel, reboot, installworld dance, there were no errors. You may possibly have some cruft left in obj, or you could zap your src tree and start fresh? :) ___ 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 Tue, 19 May 2009, Dimitry Andric wrote: DA> On 2009-05-19 23:08, Dmitry Morozovsky wrote: DA> > After cleaning /usr/obj and buildworld in single thread I got DA> > DA> > /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:35: DA> > error: conflicting types for 'aclent_t' DA> > /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys/acl.h:43: DA> > error: previous declaration of 'aclent_t' was here DA> DA> You probably didn't use -E with patch, the following files can be DA> removed manually afterwards: DA> DA> sys/cddl/compat/opensolaris/sys/acl.h DA> sys/cddl/contrib/opensolaris/common/atomic/amd64/atomic.S DA> sys/cddl/contrib/opensolaris/common/atomic/i386/atomic.S DA> sys/cddl/contrib/opensolaris/common/atomic/ia64/atomic.S DA> sys/cddl/contrib/opensolaris/common/atomic/sparc64/atomic.S DA> sys/cddl/contrib/opensolaris/uts/common/rpc/xdr.c DA> sys/cddl/contrib/opensolaris/uts/common/rpc/xdr_array.c DA> sys/cddl/contrib/opensolaris/uts/common/rpc/xdr_mem.c DA> sys/cddl/contrib/opensolaris/uts/common/sys/vfs.h DA> sys/cddl/contrib/opensolaris/uts/common/zmod/crc32.c DA> DA> My copy is currently still buildworlding, and hasn't failed yet... DA> Well, I'm pretty sure I did use -E, but whatever, I removed them by hand, clean up /usr/obj again, and restart buildworld/buildkernel... ... okie, build went into depend phase, while before it breaks on lib phase. maybe I didn't clean someleftovers, or something other go wrong, we'll see... maybe I left some unusual leftovers in /usr/obj; but again, most of files I had to remove by hand (your list) survived ``patch -E''; I'll try to reproduce this tomorrow... ... but then again, on `build all'' phase, I got ===> cddl/sbin/zpool (all) cc -O2 -fno-strict-aliasing -pipe -march=athlon-mp -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/lib/libumem -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libumem/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzfs/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libnvpair -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -o zpool zpool_main.o zpool_vdev.o zpool_iter.o zpool_util.o -lavl -lzfs -lgeom -lbsdxml -lsbuf -lm -lnvpair -luutil -lutil zpool_main.o(.text+0x61ff): In function `zpool_do_create': : undefined reference to `zfs_allocatable_devs' *** Error code 1 well, time to have abit of sleep to have energy to attack it further ;-) Thanks again! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: Re: Unable to read from CCID USB reader
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 ... ... ... 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 ? thanks regards, mgp >On Monday 18 May 2009, Mario Pavlov wrote: >> Hi, >> no I haven't tried it on CURRENT >> should I do that ? >> is there something new in the USB stuff there ? > >There is a new USB stack in 8-current and a new libusb which is installed as >a >part of the base system. > >--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"
Re: RFT: ZFS MFC
On 2009-05-19 23:08, Dmitry Morozovsky wrote: > After cleaning /usr/obj and buildworld in single thread I got > > /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:35: > error: conflicting types for 'aclent_t' > /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys/acl.h:43: > > error: previous declaration of 'aclent_t' was here You probably didn't use -E with patch, the following files can be removed manually afterwards: sys/cddl/compat/opensolaris/sys/acl.h sys/cddl/contrib/opensolaris/common/atomic/amd64/atomic.S sys/cddl/contrib/opensolaris/common/atomic/i386/atomic.S sys/cddl/contrib/opensolaris/common/atomic/ia64/atomic.S sys/cddl/contrib/opensolaris/common/atomic/sparc64/atomic.S sys/cddl/contrib/opensolaris/uts/common/rpc/xdr.c sys/cddl/contrib/opensolaris/uts/common/rpc/xdr_array.c sys/cddl/contrib/opensolaris/uts/common/rpc/xdr_mem.c sys/cddl/contrib/opensolaris/uts/common/sys/vfs.h sys/cddl/contrib/opensolaris/uts/common/zmod/crc32.c My copy is currently still buildworlding, and hasn't failed yet... ___ 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 Wed, 20 May 2009, Dmitry Morozovsky wrote: DM> DA> > Just to be sure: is the patch based on sys/ hierarchy, and does not touch DM> DA> > others (like sbin/)? DM> DA> DM> DA> No, it touches stuff in cddl/ too, so you need to build the world. Be DM> DA> sure to use -E with patch, to cleanup emptied files. E.g.: DM> DA> DM> DA> patch -d /usr/src -p1 -f -F0 -E -i /path/to/zfs-mfc.patch After cleaning /usr/obj and buildworld in single thread I got ===> cddl/lib/libzfs (all) cc -O2 -fno-strict-aliasing -pipe -march=athlon-mp -DZFS_NO_ACL -I/usr/src/cddl/lib/libzfs/../../../sbin/mount -I/usr/src/cddl/lib/libzfs/../../../cddl/lib/libumem -I/usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/lib/libumem -I/usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs -I/usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libnvpair -I/usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -c /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c In file included from /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_acl.h:34, from /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c:29: /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:35: error: conflicting types for 'aclent_t' /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys/acl.h:43: error: previous declaration of 'aclent_t' was here /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:40: error: redefinition of 'struct ace' /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:45: error: redefinition of typedef 'ace_t' /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys/acl.h:50: error: previous declaration of 'ace_t' was here In file included from /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_acl.h:34, from /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c:29: /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:124:1: warning: "ACE_TYPE_FLAGS" redefined In file included from /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:31, from /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_acl.h:34, from /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c:29: /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys/acl.h:178:1: warning: this is the location of the previous definition Any hints? Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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 11:47 -0700, Chris H wrote: Quoting Chris H : > Quoting Laurent Grangeau : > >> I think I can handle this answer. >> >> This is the default behavior of Xorg 7.4. If you want to see the old >> screen, launch Xorg with the -retro option. >> The command should be like this : >> X -config xorg.conf.new -retro >> >> If your mouse or your keyboard doesn't seem to work, look if you >> have enable dbus and hald. In your /etc/rc.conf, you should have >> dbus_enable="YES" and hald_enable="YES" (I'm not sure about this). >> >> All this is explain in the handbook : Configuring X11. > > Hello Laurent, and thank you for your reply. > > For the record, this is the way I /first/ attempted to do it - > > echo 'enable_hald="YES"' >> /etc/rc.conf > echo 'enable_dbus="YES"' >> /etc/rc.conf > > Bounce the box > attempt to test Xorg: > > Xorg -config /root/xorg.conf.new > > no joy. > > So I tweaked the file (removing the card I wasn't going to use). > Save the remaining as /etc/X11/xorg.conf.nvidia && > > Xorg -config /etc/X11/xorg.conf.nvidia > > But again, "no joy". > > I'll try it again, and report back with my findings. > > Thanks again for your response. > > --Chris H OK here's the results: echo 'hald_enable="YES"' >> /etc/rc.conf echo 'enable_dbus="YES"' >> /etc/rc.conf bounce the box Xorg -config /etc/X11/xorg.conf.nvidia returns the following: X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.1-RELEASE i386 Current Operating ---8<--[BIG SNIP]--8<--- (**) Option "DataBits" "8" (**) Option "Parity" "None" (**) Option "Vmin" "1" (**) Option "Vtime" "0" (**) Option "FlowControl" "None" An attempt to bail out of X on tty8 (ctl-alt-backspace) returns: Failed to switch consoles (Invalid argument) on tty0 Attempting again returns: Failed to switch consoles (Invalid argument) on tty0 move to tty0 (ctl-alt-f1) && ctl-C OK let's try the -retro switch on the Xorg created conf... --- Xorg -config xorg.conf.new -retro provides: X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.1-RELEASE i386 Current Operating System: FreeBSD udns.ultimatedns.NET 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Build Date: 16 May 2009 07:15:01AM 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: Tue May 19 11:33:40 2009 (++) Using config file: "/etc/X11/xorg.conf.new" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Screen "Screen1" (1) (**) | |-->Monitor "Monitor1" (**) | |-->Device "Card1" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (==) Automatically adding devices ---8<--[BIG SNIP]--8<--- (II) Module int10: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (==) MACH64(0): Write-combining range (0xa,0x2) was already clear (==) MACH64(0): Write-combining range (0xc,0x4) was already clear Which only leaves me with a blinking block cursor in the upper LEFT-hand corner while hooked up to the NV card. There is no output to the MACH64. I don't think this is the answer. Hrm, ok... It might still be getting confused by the ati card... The issue comes down to which card (hopefully not both) is handling legacy vga calls to 0xc. I did just notice someone else post an issue with the openchrome driver and int10 though, so you might try disabling int10. robert. Hello Robert, and thank you for your reply. I apologize, but am not exactly sure how to do this. The following: SubSection "int10" Option"omit int10" # don't initialise openchrome extension EndSubSection didn't do it. :( --Chris H. --Chris H > >> >> Le 19 mai 09 à 19:15, Chris H a écrit : >> >>> Quoting Robert Noland : >>> On Mon, 2009-05-18 at 23:40 -0700, Chris H wrote: > Quoting "Paul B. Mahol" : > > > On 5/19/09, Chris H wrote: > >> Quoting Chris H : > >> > >>> Quoting Chris H : > >>> > Greetings, > I'm unable to get xorg-7.4 to accomodate my Gforce4 MX 440. > On 7.1-7.2 releases. I'm currently working (struggling) with > it on a 7.1 install/GENERIC with cvsup over the weekend (Sunday), > I've seen only a few discussions regarding this, but no joy. > > I'm not sure what to post for additional information. So I'll > provide the output of dmesg(8), and Xorg.0.log via links. > >>
Re: RFT: ZFS MFC
On Tue, 19 May 2009, Dimitry Andric wrote: DA> On 2009-05-19 22:10, Dmitry Morozovsky wrote: DA> > Just to be sure: is the patch based on sys/ hierarchy, and does not touch DA> > others (like sbin/)? DA> DA> No, it touches stuff in cddl/ too, so you need to build the world. Be DA> sure to use -E with patch, to cleanup emptied files. E.g.: DA> DA> patch -d /usr/src -p1 -f -F0 -E -i /path/to/zfs-mfc.patch Hmm, not too much success there: (in the process of building kernel) ===> zfs (all) cc -O2 -fno-strict-aliasing -pipe -march=athlon-mp -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/usr/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/usr/src/sys/modules/zfs/../.. -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/usr/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MOOSE/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/MOOSE -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-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 /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/acl/acl_common.c In file included from /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/acl/acl_common.h:33, from /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/acl/acl_common.c:36: /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/acl.h:35: error: conflicting types for 'aclent_t' /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/sys/acl.h:43: error: previous declaration of 'aclent_t' was here /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/acl.h:40: error: redefinition of 'struct ace' /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/acl.h:45: error: redefinition of typedef 'ace_t' /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/sys/acl.h:50: error: previous declaration of 'ace_t' was here In file included from /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/acl/acl_common.h:33, from /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/acl/acl_common.c:36: /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/acl.h:124:1: warning: "ACE_TYPE_FLAGS" redefined [much more after these...] Or, should I rebuild world previously? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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 2009-05-19 22:10, Dmitry Morozovsky wrote: > Just to be sure: is the patch based on sys/ hierarchy, and does not touch > others (like sbin/)? No, it touches stuff in cddl/ too, so you need to build the world. Be sure to use -E with patch, to cleanup emptied files. E.g.: patch -d /usr/src -p1 -f -F0 -E -i /path/to/zfs-mfc.patch ___ 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
> Many people are happily running an old pool with the new code. I have > done that in a VM and run load over it just to be certain. The tuning > still applies to i386. On amd64 vm backpressure works, but may > actually be too aggressive - shrinking the ARC in favor of the > inactive pages queue. I haven't had any i386 code around for a long while, so I will just try it "as-is". Just need to fin ish moving tghe machine up to todays -STABLE before applying the patchset (which involved hand fixing bce). Then, all being well I shall "(the_winds)caution" to coin an old C joke, and run this up on one of our production DNS servers to see how it goes. cheers, -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: RFT: ZFS MFC
On Wed, 20 May 2009, Dmitry Morozovsky wrote: DM> DM> DA> http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 DM> DM> DA> DM> DM> DA> This diff should apply with no fuzz and no rejects to RELENG_7 as of DM> DM> DA> r192386 (2009-05-19 15:33:41 UTC). For earlier or later revisions, no DM> DM> DA> warranty. ;) DM> DM> DM> DM> Just to be sure: is the patch based on sys/ hierarchy, and does not touch DM> DM> others (like sbin/)? DM> DM> DM> DM> so, basically, DM> DM> DM> DM> cd /usr/src/sys && patch < /path/to/zfs-mfc.patch DM> DM> DM> DM> should be ok? DM> DM> Argh. Answering to myself: no. Even after ``patch -p1'' under /usr/src I got DM> DM> ma...@moose:/usr/src> find . -iname '*rej' DM> ./sys/cddl/compat/opensolaris/sys/acl.h.rej DM> ./sys/cddl/contrib/opensolaris/uts/common/sys/dtrace_impl.h.rej DM> ./sys/cddl/contrib/opensolaris/common/atomic/ia64/atomic.S.rej DM> DM> Will investigate further... Aha, it seems first and third files are absent in your tree, and second is just $FreeBSD tag differ... Well, let's try to start compile phase ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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
Hello Robert, and thank you for taking the time to respond. Quoting Robert Noland : On Tue, 2009-05-19 at 09:57 -0700, Chris H wrote: Quoting Dimitry Andric : > On 2009-05-19 08:40, Chris H wrote: >> I see. Well I'm specifically using the nv driver. Here's another >> attempt to provide the relevant info: > > I could not find the error message from $subject in these logs. Where > is it? :) If I had found it, I would have better known what direction to travel to overcome it. :) Aparently Xorg wants to keep it a secret - I saw no "argument". This isn't actually Xorg per se... It is when we attempt to set an MTRR range via ioctl on /dev/mem. The ultimate return value is EINVAL which just gets displayed as invalid argument. The closest possible answer I can come up with, involves "write combining" and provinding some information in /proc/mtrr But I only have /proc and nothing in it. Thought about echo(1)ing the information to mtrr. But don't understand the whole thing well enough to /dare/ do it. I only know it involves something in this area: 0xfd00/16777216, 0xf000/134217728, 0xfa58/524288 out of the Xorg log. I'm also not sure if GENERIC knows how to handle mtrr (Memory Type Range Registers) ideally. I hadn't built world/kernel yet because there are also some issues on the ATA ports that need to be resolved. I started a theread on this earlier. Thank you for taking the time to respond. You can do a "memcontrol list" which will display the memory regions and their caching method. Likely what you will find is a "global" MTRR which is set to write-back. I always set "write-back" in the BIOS, as it then gets marked "dirty", and the CPU cache will get processed accordingly. We don't have the ability to split regions and we aren't allowed to overlap write-combine on top of write-back, so any attempt to set MTRR will fail. The specific failure is most likely when X tries to set write-combine on the framebuffer, which in your case looks like 0xf000/134217728. Again, this shouldn't prevent X from working... It is just a performance issue. My investigations on this have led me to believe that Linux can address (allow) write-combining via their version of sysctl (so to speak). The article I found this reference was here: http://www.mplayerhq.hu/DOCS/HTML/en/mtrr.html Do we (does FreeBSD) have this ability? Or will we? I also found some good information on write combining here: http://www.meduna.org/txt_mtrr_en.html This box can be used as a "guinea pig" if you would like. Thanks again Robert, for all your time and efforts. --Chris H robert. --Chris H > ___ 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" -- 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: RFT: ZFS MFC
On Wed, 20 May 2009, Dmitry Morozovsky wrote: DM> DA> http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 DM> DA> DM> DA> This diff should apply with no fuzz and no rejects to RELENG_7 as of DM> DA> r192386 (2009-05-19 15:33:41 UTC). For earlier or later revisions, no DM> DA> warranty. ;) DM> DM> Just to be sure: is the patch based on sys/ hierarchy, and does not touch DM> others (like sbin/)? DM> DM> so, basically, DM> DM> cd /usr/src/sys && patch < /path/to/zfs-mfc.patch DM> DM> should be ok? Argh. Answering to myself: no. Even after ``patch -p1'' under /usr/src I got ma...@moose:/usr/src> find . -iname '*rej' ./sys/cddl/compat/opensolaris/sys/acl.h.rej ./sys/cddl/contrib/opensolaris/uts/common/sys/dtrace_impl.h.rej ./sys/cddl/contrib/opensolaris/common/atomic/ia64/atomic.S.rej Will investigate further... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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
Dimitry, On Tue, 19 May 2009, Dimitry Andric wrote: DA> > Would you please also post diff to RELENG_7 there? DA> DA> http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 DA> DA> This diff should apply with no fuzz and no rejects to RELENG_7 as of DA> r192386 (2009-05-19 15:33:41 UTC). For earlier or later revisions, no DA> warranty. ;) Just to be sure: is the patch based on sys/ hierarchy, and does not touch others (like sbin/)? so, basically, cd /usr/src/sys && patch < /path/to/zfs-mfc.patch should be ok? Thanks again! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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 Tue, 19 May 2009, Dimitry Andric wrote: DA> >> http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 DA> > DA> > Thanks - am going to gve this a try later. Preseumably if I leave the DA> > pool at the revision it is currently on then I can revert back easily ? DA> DA> I'll just repeat what Kip told us, "The standard disclaimers apply. DA> This has only been lightly tested in a VM. Please do not use it with DA> data you care about at this time." DA> DA> That said, zpool(1M) tells: DA> DA>zpool upgrade [-V version] -a | pool ... DA> DA>Upgrades the given pool to the latest on-disk version. Once this is DA>done, the pool will no longer be accessible on systems running DA>older versions of the software. DA> DA> and later on: DA> DA>-V versionUpgrade to the specified version. If the -V flag is DA> not specified, the pool is upgraded to the most DA> recent version. This option can only be used to DA> increase the version number, and only up to the most DA> recent version supported by this software. DA> DA> E.g. you can upgrade pools to ZFS v13, but there's no way back. If you DA> don't upgrade your pool, it should not destroy anything (but don't count DA> on it!), but you won't be able to test any new features either... Well, I know this well, but for my particular case I should at least test one case where previous ZFS implementation panics on *read* access to one particular inode; then I hope to convince Kip to dig into the case deep enough to fix it ;-) FWIW, I use ZFS on FreeBSD from the moment it hits RELENG_7, though not too high load patterns, and have no major isues so far, modulo this one and obvious kmem exhastion. Even more is my intention to fix this ;-) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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
Many people are happily running an old pool with the new code. I have done that in a VM and run load over it just to be certain. The tuning still applies to i386. On amd64 vm backpressure works, but may actually be too aggressive - shrinking the ARC in favor of the inactive pages queue. Cheers, Kip On Tue, May 19, 2009 at 12:54 PM, Dimitry Andric wrote: > On 2009-05-19 19:41, Pete French wrote: >>> http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 >> >> Thanks - am going to gve this a try later. Preseumably if I leave the >> pool at the revision it is currently on then I can revert back easily ? > > I'll just repeat what Kip told us, "The standard disclaimers apply. > This has only been lightly tested in a VM. Please do not use it with > data you care about at this time." > > That said, zpool(1M) tells: > > zpool upgrade [-V version] -a | pool ... > > Upgrades the given pool to the latest on-disk version. Once this is > done, the pool will no longer be accessible on systems running > older versions of the software. > > and later on: > > -V version Upgrade to the specified version. If the -V flag is > not specified, the pool is upgraded to the most > recent version. This option can only be used to > increase the version number, and only up to the most > recent version supported by this software. > > E.g. you can upgrade pools to ZFS v13, but there's no way back. If you > don't upgrade your pool, it should not destroy anything (but don't count > on it!), but you won't be able to test any new features either... > > >> Also, is this the version which no longer requires any tuning parameters >> in loader.conf ? That would be extermely interesting! > > As far as I know, the tuning stuff still applies, especially for i386. > On my i386 test VM with 1GB RAM, vm.kmem_size is about 163 MiB without > any tuning, while vm.kmem_size_max is about 320 MiB, so you get the warning: > > ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. > Consider tuning vm.kmem_size and vm.kmem_size_max > in /boot/loader.conf. > > So please test, and let us know your findings. :) > ___ > 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" > -- 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"
Re: RFT: ZFS MFC
On 2009-05-19 19:41, Pete French wrote: >> http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 > > Thanks - am going to gve this a try later. Preseumably if I leave the > pool at the revision it is currently on then I can revert back easily ? I'll just repeat what Kip told us, "The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time." That said, zpool(1M) tells: zpool upgrade [-V version] -a | pool ... Upgrades the given pool to the latest on-disk version. Once this is done, the pool will no longer be accessible on systems running older versions of the software. and later on: -V versionUpgrade to the specified version. If the -V flag is not specified, the pool is upgraded to the most recent version. This option can only be used to increase the version number, and only up to the most recent version supported by this software. E.g. you can upgrade pools to ZFS v13, but there's no way back. If you don't upgrade your pool, it should not destroy anything (but don't count on it!), but you won't be able to test any new features either... > Also, is this the version which no longer requires any tuning parameters > in loader.conf ? That would be extermely interesting! As far as I know, the tuning stuff still applies, especially for i386. On my i386 test VM with 1GB RAM, vm.kmem_size is about 163 MiB without any tuning, while vm.kmem_size_max is about 320 MiB, so you get the warning: ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. Consider tuning vm.kmem_size and vm.kmem_size_max in /boot/loader.conf. So please test, and let us know your findings. :) ___ 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 Tue, 2009-05-19 at 09:57 -0700, Chris H wrote: > Quoting Dimitry Andric : > > > On 2009-05-19 08:40, Chris H wrote: > >> I see. Well I'm specifically using the nv driver. Here's another > >> attempt to provide the relevant info: > > > > I could not find the error message from $subject in these logs. Where > > is it? :) > > If I had found it, I would have better known what direction to travel > to overcome it. :) > Aparently Xorg wants to keep it a secret - I saw no "argument". This isn't actually Xorg per se... It is when we attempt to set an MTRR range via ioctl on /dev/mem. The ultimate return value is EINVAL which just gets displayed as invalid argument. > The closest possible answer I can come up with, involves "write combining" > and provinding some information in /proc/mtrr > But I only have /proc and nothing in it. Thought about echo(1)ing > the information to mtrr. But don't understand the whole thing well > enough to /dare/ do it. I only know it involves something in this > area: > > 0xfd00/16777216, 0xf000/134217728, 0xfa58/524288 > > out of the Xorg log. I'm also not sure if GENERIC knows how to handle > mtrr (Memory Type Range Registers) ideally. I hadn't built world/kernel > yet because there are also some issues on the ATA ports that need to be > resolved. I started a theread on this earlier. > > Thank you for taking the time to respond. You can do a "memcontrol list" which will display the memory regions and their caching method. Likely what you will find is a "global" MTRR which is set to write-back. We don't have the ability to split regions and we aren't allowed to overlap write-combine on top of write-back, so any attempt to set MTRR will fail. The specific failure is most likely when X tries to set write-combine on the framebuffer, which in your case looks like 0xf000/134217728. Again, this shouldn't prevent X from working... It is just a performance issue. robert. > --Chris H > > > > > > > ___ > 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" -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: mountd doean`t start when ZFS is enabled.
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"
Re: failed to set mtrr: invalid argument
Quoting Laurent Grangeau : I think I can handle this answer. This is the default behavior of Xorg 7.4. If you want to see the old screen, launch Xorg with the -retro option. The command should be like this : X -config xorg.conf.new -retro If your mouse or your keyboard doesn't seem to work, look if you have enable dbus and hald. In your /etc/rc.conf, you should have dbus_enable="YES" and hald_enable="YES" (I'm not sure about this). All this is explain in the handbook : Configuring X11. Hello Laurent, and thank you for your reply. For the record, this is the way I /first/ attempted to do it - echo 'enable_hald="YES"' >> /etc/rc.conf echo 'enable_dbus="YES"' >> /etc/rc.conf Bounce the box attempt to test Xorg: Xorg -config /root/xorg.conf.new no joy. So I tweaked the file (removing the card I wasn't going to use). Save the remaining as /etc/X11/xorg.conf.nvidia && Xorg -config /etc/X11/xorg.conf.nvidia But again, "no joy". I'll try it again, and report back with my findings. Thanks again for your response. --Chris H Le 19 mai 09 à 19:15, Chris H a écrit : Quoting Robert Noland : On Mon, 2009-05-18 at 23:40 -0700, Chris H wrote: Quoting "Paul B. Mahol" : > On 5/19/09, Chris H wrote: >> Quoting Chris H : >> >>> Quoting Chris H : >>> Greetings, I'm unable to get xorg-7.4 to accomodate my Gforce4 MX 440. On 7.1-7.2 releases. I'm currently working (struggling) with it on a 7.1 install/GENERIC with cvsup over the weekend (Sunday), I've seen only a few discussions regarding this, but no joy. I'm not sure what to post for additional information. So I'll provide the output of dmesg(8), and Xorg.0.log via links. Thank you for all your time and consideration in this matter. Sincerely, Chris H Xorg log: http://codewarehouse.NET/output/Xorg.0.log relevent dmesg(8) output: http://codewarehouse.NET/output/dmesg.output >>> >>> OOPS! I guess the xorg config might be useful: >>> http://codewarehouse.NET/output/xorg.conf.nvidia >>> >> SIGH... Seems that the registrar isn't paying attention. >> They happily accepted my money, but forgot to renew the domain. >> >> So here's trying to attach the files... > > That message appears for me only when I use xf86-video-vesa driver. I see. Well I'm specifically using the nv driver. Here's another attempt to provide the relevant info: You have more than one card in the machine, which might be confusing things. The mtrr failure is caused by how your bios sets up memory regions. It should only impact performance. Exactly what issue are you seeing? I'm seeing a black screen on ctl-alt-f9 (tty8) I'm seeing the message listed as this thread topic on tty0 (ctl-alt- f1). The proceedure theat led me here is: Xorc -configure edit /root/xorg.config.new (move all the ati related stuff to xorg.conf.ati). Tweak whats left, and save it as /etc/X11/xorg.conf.nvidia. exec Xorg -config /etc/X11/xorg.conf.nvidia The ctl-alt-backspace won't break me out of Xorg/tty8. I am forced to ctl-alt-f1 (where I read the error message) then use ctl-C - which kills Xorg, and returns me to a working console. Thank you Robert, for taking the time to respond. --Chris H robert. Xorg log: X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.1-RELEASE i386 Current Operating System: FreeBSD udns 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Build Date: 16 May 2009 07:15:01AM 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: Mon May 18 20:34:43 2009 (++) Using config file: "/etc/X11/xorg.conf.nvidia" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor1" (**) | |-->Device "Card1" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "AllowEmptyInput" "false" (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/100dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/100dpi/"). (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/75dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/75dpi/"). (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/100dpi/". Entry deleted from font path. (Run 'mk
Re: failed to set mtrr: invalid argument
I think I can handle this answer. This is the default behavior of Xorg 7.4. If you want to see the old screen, launch Xorg with the -retro option. The command should be like this : X -config xorg.conf.new -retro If your mouse or your keyboard doesn't seem to work, look if you have enable dbus and hald. In your /etc/rc.conf, you should have dbus_enable="YES" and hald_enable="YES" (I'm not sure about this). All this is explain in the handbook : Configuring X11. Le 19 mai 09 à 19:15, Chris H a écrit : Quoting Robert Noland : On Mon, 2009-05-18 at 23:40 -0700, Chris H wrote: Quoting "Paul B. Mahol" : > On 5/19/09, Chris H wrote: >> Quoting Chris H : >> >>> Quoting Chris H : >>> Greetings, I'm unable to get xorg-7.4 to accomodate my Gforce4 MX 440. On 7.1-7.2 releases. I'm currently working (struggling) with it on a 7.1 install/GENERIC with cvsup over the weekend (Sunday), I've seen only a few discussions regarding this, but no joy. I'm not sure what to post for additional information. So I'll provide the output of dmesg(8), and Xorg.0.log via links. Thank you for all your time and consideration in this matter. Sincerely, Chris H Xorg log: http://codewarehouse.NET/output/Xorg.0.log relevent dmesg(8) output: http://codewarehouse.NET/output/dmesg.output >>> >>> OOPS! I guess the xorg config might be useful: >>> http://codewarehouse.NET/output/xorg.conf.nvidia >>> >> SIGH... Seems that the registrar isn't paying attention. >> They happily accepted my money, but forgot to renew the domain. >> >> So here's trying to attach the files... > > That message appears for me only when I use xf86-video-vesa driver. I see. Well I'm specifically using the nv driver. Here's another attempt to provide the relevant info: You have more than one card in the machine, which might be confusing things. The mtrr failure is caused by how your bios sets up memory regions. It should only impact performance. Exactly what issue are you seeing? I'm seeing a black screen on ctl-alt-f9 (tty8) I'm seeing the message listed as this thread topic on tty0 (ctl-alt- f1). The proceedure theat led me here is: Xorc -configure edit /root/xorg.config.new (move all the ati related stuff to xorg.conf.ati). Tweak whats left, and save it as /etc/X11/xorg.conf.nvidia. exec Xorg -config /etc/X11/xorg.conf.nvidia The ctl-alt-backspace won't break me out of Xorg/tty8. I am forced to ctl-alt-f1 (where I read the error message) then use ctl-C - which kills Xorg, and returns me to a working console. Thank you Robert, for taking the time to respond. --Chris H robert. Xorg log: X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.1-RELEASE i386 Current Operating System: FreeBSD udns 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Build Date: 16 May 2009 07:15:01AM 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: Mon May 18 20:34:43 2009 (++) Using config file: "/etc/X11/xorg.conf.nvidia" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor1" (**) | |-->Device "Card1" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "AllowEmptyInput" "false" (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/100dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/100dpi/"). (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/75dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/75dpi/"). (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/100dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/100dpi/"). (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/75dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/75dpi/"). (**) 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/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, built-ins (**) ModulePath set to "/usr/local/lib/xorg/modules" (II) Loader magic: 0x6a0 (II) Module ABI versions:
Re: help with 7.0-p12 crash analysis "panic: lockmgr: upgrade without shared"
Kostik Belousov wrote:
> On Mon, May 18, 2009 at 09:39:10PM -0400, Charles Owens wrote:
>
>> Hello,
>>
>> We had a crash of a 7.0-RELEASE-p12 running on a dual quad-core Xeon
>> system with 6 gig RAM and mfi-based RAID. Pasted below are the output
>> of kgdb crashdump backtrace, custom kernel config, and boot log.
>>
>> We really need to understand what happened and would greatly appreciate
>> assistance. What is the next step?
>>
>
> I believe this is fixed by r185210 on stable/7. The fix was included at
> least into 7.1.
>
>From the PR that does look relevant. We're giving the patch a try.
Thanks, Charles
>> Thanks very much,
>>
>> Charles
>>
>> (kgdb) newcastle# kgdb kernel.debug /crash/vmcore.0
>> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
>> Undefined symbol "ps_pglobal_lookup"]
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for details.
>> This GDB was configured as "i386-marcel-freebsd".
>>
>> Unread portion of the kernel message buffer:
>> panic: lockmgr: upgrade without shared
>> cpuid = 3
>> Uptime: 1d0h5m24s
>> Physical memory: 6126 MB
>> Dumping 495 MB: 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256
>> 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16
>>
>> #0 doadump () at pcpu.h:195
>> 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
>> (kgdb) backtrace
>> #0 doadump () at pcpu.h:195
>> #1 0xc0505537 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
>> #2 0xc05057f9 in panic (fmt=Variable "fmt" is not available.
>> ) at /usr/src/sys/kern/kern_shutdown.c:563
>> #3 0xc04f3cb7 in _lockmgr (lkp=0xcc69ee28, flags=8212, interlkp=0xcc69ee58,
>> td=0xcc11e660, file=0xc088d931 "/usr/src/sys/kern/vfs_subr.c", line=2213)
>> at /usr/src/sys/kern/kern_lock.c:310
>> #4 0xc05710b0 in vop_stdlock (ap=0xec5c6bfc)
>> at /usr/src/sys/kern/vfs_default.c:266
>> #5 0xc07734b6 in VOP_LOCK1_APV (vop=0xc0919180, a=0xec5c6bfc)
>> at vnode_if.c:1618
>> #6 0xc06cc3eb in ffs_lock (ap=0xec5c6bfc)
>> at /usr/src/sys/ufs/ffs/ffs_vnops.c:391
>> #7 0xc07734b6 in VOP_LOCK1_APV (vop=0xc09296c0, a=0xec5c6bfc)
>> at vnode_if.c:1618
>> #8 0xc057f9b1 in vput (vp=0xcc69edd0) at vnode_if.h:851
>> #9 0xc06f9f54 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1025
>> #10 0xc04e43c9 in fork_exit (callout=0xc06f8f30 , arg=0x0,
>> frame=0xec5c6d38) at /usr/src/sys/kern/kern_fork.c:781
>> #11 0xc0746f80 in fork_trampoline () at
>> /usr/src/sys/i386/i386/exception.s:205
>> (kgdb)
>>
>>
>> * KERNEL CONF **
>>
>> # Inherit config (most stuff) -- this is slightly customized version...
>> # inherits from GENERIC-cust (tweaked to disable the default scheduler)
>> include PAE-cust
>>
>> # Name of this kernel
>> ident BEACON
>>
>>
>> # Scheduler -- From /usr/src/sys/conf/NOTES:
>> #
>> # SCHED_ULE provides significant performance advantages over 4BSD on many
>> # workloads on SMP machines. It supports cpu-affinity, per-cpu runqueues
>> # and scheduler locks. It also has a stronger notion of interactivity
>> # which leads to better responsiveness even on uniprocessor machines. This
>> # will eventually become the default scheduler.
>> #
>> optionsSCHED_ULE
>>
>>
>> # Note: we're compiling modules in statically since with PAE we don't want to
>> # load KLDs. See comments in pae(4) and PAE kernel conf file.
>>
>> # Hardware Monitoring / Management
>>
>> device ipmi
>>
>> # Storage
>>
>> options GEOM_JOURNAL
>>
>> # Firewall
>>
>> device pf #PF OpenBSD packet-filter firewall
>> device pflog #logging support interface for PF
>> # device pfsync #synchronization interface for PF
>>
>> options ALTQ
>>
>> options ALTQ_CBQ
>> options ALTQ_RED
>> options ALTQ_RIO
>> options ALTQ_HFSC
>> options ALTQ_CDNR
>> options ALTQ_PRIQ
>>
>> options ALTQ_NOPCC # Required for SMP builds
>>
>> # Linux Emulation
>>
>> options COMPAT_LINUX
>> options LINPROCFS
>> options LINSYSFS
>>
>> # Screen saver
>>
>> device green_saver
>>
>> ### Network perf tuning
>>
>> options ACCEPT_FILTER_HTTP
>>
>> # See polling(4))
>>
>> options DEVICE_POLLING
>> options HZ=1000
>>
>> # End config
>>
>>
>> ** Boot Log **
>>
>> May 16 02:34:18 gbs01-etc kernel: mfi0: 4167 (295774362s/0x0020/0) - Patrol
>> Read complete
>> May 16 02:56:01 gbs01-etc heartbeat: [2685]: WARN: Gmain_timeout_dispatch:
>> Dispatch function for send local status took too long to execute: 789 ms (>
>> 50 ms) (
Re: RFT: ZFS MFC
> http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 Thanks - am going to gve this a try later. Preseumably if I leave the pool at the revision it is currently on then I can revert back easily ? Also, is this the version which no longer requires any tuning parameters in loader.conf ? That would be extermely interesting! -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: RFT: ZFS MFC
On Tue, 19 May 2009, Dimitry Andric wrote: DA> > Would you please also post diff to RELENG_7 there? DA> DA> http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 DA> DA> This diff should apply with no fuzz and no rejects to RELENG_7 as of DA> r192386 (2009-05-19 15:33:41 UTC). For earlier or later revisions, no DA> warranty. ;) Thank you, will try tonight! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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"
7.2-RELEASE kernel panic on Atheros card insert on T61p
Hi all, I'm getting deterministic kernel panics on Lenovo T61p laptop when inserting Athreos-based wifi card. Details are given below. Let me know if you need something more to debug the panic. Thanks, Petr GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: cardbus0: Expecting link target, got 0x0 ath0: mem 0xbfeb-0xbfeb irq 16 at device 0.0 on cardbus0 ath0: [ITHREAD] Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xc6b919fc frame pointer = 0x28:0xc6b91a10 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 40 (cbb0 event thread) trap number = 12 panic: page fault cpuid = 0 Uptime: 40s Physical memory: 3050 MB Dumping 104 MB: 89 73 57 41 25 9 Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/ntfs.ko...Reading symbols from /boot/kernel/ntfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/ntfs.ko #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07e25a7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e2879 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0ae3ebc in trap_fatal (frame=0xc6b919bc, eva=0) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0ae4140 in trap_pfault (frame=0xc6b919bc, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0ae4aec in trap (frame=0xc6b919bc) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0ac91fb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0x in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) info threads 78 Thread 100104 (PID=912: getty) sched_switch (td=0xc73cb690, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 77 Thread 100101 (PID=901: getty) sched_switch (td=0xc73cbd20, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 76 Thread 100100 (PID=900: getty) sched_switch (td=0xc7666000, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 75 Thread 100099 (PID=899: getty) sched_switch (td=0xc7666230, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 74 Thread 100098 (PID=898: getty) sched_switch (td=0xc7666460, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 73 Thread 100097 (PID=897: getty) sched_switch (td=0xc790, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 72 Thread 100096 (PID=896: getty) sched_switch (td=0xc76668c0, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 71 Thread 100095 (PID=895: getty) sched_switch (td=0xc7666af0, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 70 Thread 100092 (PID=892: sleep) sched_switch (td=0xc7667230, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 69 Thread 100091 (PID=891: sh) sched_switch (td=0xc7667460, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 68 Thread 100063 (PID=890: logger) sched_switch (td=0xc7233230, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 67 Thread 100087 (PID=889: sh) sched_switch (td=0xc73c9690, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sch
Re: RFT: ZFS MFC
On 2009-05-19 13:33, Dmitry Morozovsky wrote: > Would you please also post diff to RELENG_7 there? http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 This diff should apply with no fuzz and no rejects to RELENG_7 as of r192386 (2009-05-19 15:33:41 UTC). For earlier or later revisions, no warranty. ;) ___ 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 Dimitry Andric : On 2009-05-19 08:40, Chris H wrote: I see. Well I'm specifically using the nv driver. Here's another attempt to provide the relevant info: I could not find the error message from $subject in these logs. Where is it? :) If I had found it, I would have better known what direction to travel to overcome it. :) Aparently Xorg wants to keep it a secret - I saw no "argument". The closest possible answer I can come up with, involves "write combining" and provinding some information in /proc/mtrr But I only have /proc and nothing in it. Thought about echo(1)ing the information to mtrr. But don't understand the whole thing well enough to /dare/ do it. I only know it involves something in this area: 0xfd00/16777216, 0xf000/134217728, 0xfa58/524288 out of the Xorg log. I'm also not sure if GENERIC knows how to handle mtrr (Memory Type Range Registers) ideally. I hadn't built world/kernel yet because there are also some issues on the ATA ports that need to be resolved. I started a theread on this earlier. Thank you for taking the time to respond. --Chris H ___ 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: maximum mmap()
On Wednesday 13 May 2009 06:10:29 am dikshie wrote: > i found that my rrdtool does not work with mmap() with rra files size > more than 2GB. Umm, one of the goals of rrdtool was to create databases with a finite (and relatively small) maximum size. What on earth are you doing with it? :-) -- Kirk Strauser ___ 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: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
On Saturday 16 May 2009 4:21:47 am Bruce Simpson wrote:
> John Baldwin wrote:
> > ...
> > Sounds like the ATA driver is allocating the same BAR twice. Hmm, yes, it
> > allocates the resources once for each channel it seems in the ata_ali_sata
> > attachment. Looking in ata-chipset.c, all the other chipsets are good
> > about
> > allocating these resources in their chipinit routines rather than the
> > per-channel allocate routine. Well, except ata_pci_allocate() is also
> > busted. *sigh* I can work on a patch for HEAD if you are willing to test.
> >
>
> Yes, ata is gnarly in places...
>
> If a fix can be dropped straight into a 7.2 tree, then that is even
> better... I could try testing a NanoBSD image of HEAD on this machine if
> the change set delta between branches is sufficiently huge to prevent
> backporting the fix; this is my desktop machine and this is the only
> critical bug I've run into so far with 7.2.
Try this fix for HEAD. I can do a 7.x patch as well, but it needs my other
fix for different ATA breakage merged as well (as it adds support for
chipset-specific data in the ATA controller backends). Note that in 7.x
all the chipset code lives in sys/dev/ata/ata-chipset.c. Also, I plan to
merge the other ATA fixes to 7 today.
--- //depot/vendor/freebsd/src/sys/dev/ata/chipsets/ata-acerlabs.c
2009/03/04 18:30:14
+++ //depot/user/jhb/acpipci/dev/ata/chipsets/ata-acerlabs.c2009/05/18
16:08:13
@@ -63,6 +63,9 @@
#define ALI_NEW0x02
#define ALI_SATA 0x04
+struct ali_sata_resources {
+ struct resource *bars[4];
+};
/*
* Acer Labs Inc (ALI) chipset support functions
@@ -98,6 +101,8 @@
ata_ali_chipinit(device_t dev)
{
struct ata_pci_controller *ctlr = device_get_softc(dev);
+struct ali_sata_resources *res;
+int i, rid;
if (ata_setup_interrupt(dev, ata_generic_intr))
return ENXIO;
@@ -113,6 +118,22 @@
if ((ctlr->chip->chipid == ATA_ALI_5288) &&
(ata_ahci_chipinit(dev) != ENXIO))
return 0;
+
+ /* Allocate resources for later use by channel attach routines. */
+ res = malloc(sizeof(struct ali_sata_resources), M_TEMP, M_WAITOK);
+ for (i = 0; i < 4; i++) {
+ rid = PCIR_BAR(i);
+ res->bars[i] = bus_alloc_resource_any(dev, SYS_RES_IOPORT, &rid,
+ RF_ACTIVE);
+ if (res->bars[i] == NULL) {
+ device_printf(dev, "Failed to allocate BAR %d\n", i);
+ for (i--; i >=0; i--)
+ bus_release_resource(dev, SYS_RES_IOPORT,
+ PCIR_BAR(i), res->bars[i]);
+ free(res, M_TEMP);
+ }
+ }
+ ctlr->chipset_data = res;
break;
case ALI_NEW:
@@ -168,20 +189,18 @@
device_t parent = device_get_parent(dev);
struct ata_pci_controller *ctlr = device_get_softc(parent);
struct ata_channel *ch = device_get_softc(dev);
+struct ali_sata_resources *res;
struct resource *io = NULL, *ctlio = NULL;
int unit01 = (ch->unit & 1), unit10 = (ch->unit & 2);
-int i, rid;
-
-rid = PCIR_BAR(0) + (unit01 ? 8 : 0);
-io = bus_alloc_resource_any(parent, SYS_RES_IOPORT, &rid, RF_ACTIVE);
-if (!io)
- return ENXIO;
+int i;
-rid = PCIR_BAR(1) + (unit01 ? 8 : 0);
-ctlio = bus_alloc_resource_any(parent, SYS_RES_IOPORT, &rid, RF_ACTIVE);
-if (!ctlio) {
- bus_release_resource(dev, SYS_RES_IOPORT, ATA_IOADDR_RID, io);
- return ENXIO;
+res = ctlr->chipset_data;
+if (unit01) {
+ io = res->bars[2];
+ ctlio = res->bars[3];
+} else {
+ io = res->bars[0];
+ ctlio = res->bars[1];
}
for (i = ATA_DATA; i <= ATA_COMMAND; i ++) {
--
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: So where are we at with bce and lagg then ?
> I guess it was fixed in -current in r191923. That looks like the same length fix patch as I was sent for RELENG-7. Unfortunately it has no effect on the problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/133756 -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: So where are we at with bce and lagg then ?
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. -- 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: Problem when compiling stable FreeBSD kernel
On Tue, May 19, 2009 at 12:59:46PM +0200, Laurent Grangeau typed: > Hi ! > > I'm new on FreeBSD and I have some troubles with an option in the kernel > config. I was reading > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/consoles.html#CONSOLES-VIDCONTROLto > increase the resolution of my console. > So I put this two options in my kernel config file : > > options VESA > options SC_PIXEL_MODE > > And when I try to compile it, it says that option "VESA" is not recognise. > Is it normal ? > > I'm using the stable kernel on an AMD64 cpu. > (I'm not on my computer now, so I can't send you my conf file, and the > error, but I will do it tonight.) Last time I checked, VESA was i386 (32 bit) only. 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"
top - proc accounting does not work on freebsd 7.2
Greetings, I'm tracking i386 releng_7 on kind of old single CPU machine and I see very annoying problem. top (-S) is not reporting things properly: last pid: 20337; load averages: 0.43, 0.11, 0.04 up 0+13:20:07 14:37:44 123 processes: 3 running, 102 sleeping, 18 waiting CPU: 75.0% user, 0.0% nice, 25.0% system, 0.0% interrupt, 0.0% idle Mem: 108M Active, 702M Inact, 232M Wired, 1212K Cache, 112M Buf, 1958M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZERES STATETIME WCPU COMMAND 10 root 1 171 ki31 0K 8K RUN769:35 56.15% idle: cpu0 19375 root 1 80 3464K 1616K wait 0:00 0.20% sh 13 root 1 -44- 0K 8K WAIT 7:35 0.00% swi1: net 33 root 1 -80- 0K 8K WAIT 1:57 0.00% irq18: vgapci0 11 root 1 -32- 0K 8K WAIT 0:59 0.00% swi4: clock sio 46 root 1 20- 0K 8K syncer 0:46 0.00% syncer 1066 user 1 440 32508K 26368K select 0:27 0.00% kdeinit 977 root 1 440 71956K 50668K select 0:23 0.00% Xorg As you can see the CPU is 0% idle but the idle process is accounted 56.15% It doesn't matter how the load is created - web browser, X, compilation or something else. Top just reports that only idle process is eating CPU. Here is part of dmesg info: FreeBSD 7.2-STABLE #10: Sat May 16 09:05:31 EEST 2009 r...@cheffo.freebsd-bg.org:/usr/obj/usr/src/sys/CORE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3200+ (2200.22-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20ff0 Stepping = 0 Features = 0x78bfbff < FPU ,VME ,DE ,PSE ,TSC ,MSR ,PAE ,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x1 real memory = 3221159936 (3071 MB) avail memory = 3140956160 (2995 MB) I'm using in my kernel: options SCHED_ULE # ULE scheduler options SMP # tried without it - no difference options HWPMC_HOOKS device hwpmc There are other changes from GENERIC, but they are removed/added drivers and I'm sure the problem is not there. Any idea why top does not work properly? -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: RFT: ZFS MFC
On Mon, 18 May 2009, Dimitry Andric wrote: DA> On 2009-05-16 02:02, Kip Macy wrote: DA> > I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. DA> > DA> > http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ DA> > DA> > The standard disclaimers apply. This has only been lightly tested in a DA> > VM. Please do not use it with data you care about at this time. DA> DA> For people that would like to test this without building, e.g. to easily DA> install on a spare box or VM, I have put up some snapshot ISOs of this DA> branch, at r192269 (for i386): DA> DA> http://www.andric.com/freebsd/zfs13/r192269/ DA> DA> Note: these don't contain a full ports collection, but enough to get a DA> basic system installed, or a LiveCD/DVD started. DA> DA> Also, if you encounter issues with these ISOs that don't have to do with DA> ZFS, please don't bother Kip, but me instead. :) Would you please also post diff to RELENG_7 there? I tried to produce it myself, but got stuck somewhere between SVN and CVS working copies ;-) Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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"
Problem when compiling stable FreeBSD kernel
Hi ! I'm new on FreeBSD and I have some troubles with an option in the kernel config. I was reading http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/consoles.html#CONSOLES-VIDCONTROLto increase the resolution of my console. So I put this two options in my kernel config file : options VESA options SC_PIXEL_MODE And when I try to compile it, it says that option "VESA" is not recognise. Is it normal ? I'm using the stable kernel on an AMD64 cpu. (I'm not on my computer now, so I can't send you my conf file, and the error, but I will do it tonight.) Laurent. ___ 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/19/09, Dimitry Andric wrote: > On 2009-05-19 08:40, Chris H wrote: >> I see. Well I'm specifically using the nv driver. Here's another >> attempt to provide the relevant info: > > I could not find the error message from $subject in these logs. Where > is it? :) In thread subject. -- 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
On 2009-05-19 08:40, Chris H wrote: > I see. Well I'm specifically using the nv driver. Here's another > attempt to provide the relevant info: I could not find the error message from $subject in these logs. Where is it? :) ___ 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"
So where are we at with bce and lagg then ?
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. cheers, -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: help with 7.0-p12 crash analysis "panic: lockmgr: upgrade without shared"
On Mon, May 18, 2009 at 09:39:10PM -0400, Charles Owens wrote:
> Hello,
>
> We had a crash of a 7.0-RELEASE-p12 running on a dual quad-core Xeon
> system with 6 gig RAM and mfi-based RAID. Pasted below are the output
> of kgdb crashdump backtrace, custom kernel config, and boot log.
>
> We really need to understand what happened and would greatly appreciate
> assistance. What is the next step?
I believe this is fixed by r185210 on stable/7. The fix was included at
least into 7.1.
>
> Thanks very much,
>
> Charles
>
> (kgdb) newcastle# kgdb kernel.debug /crash/vmcore.0
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
> Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd".
>
> Unread portion of the kernel message buffer:
> panic: lockmgr: upgrade without shared
> cpuid = 3
> Uptime: 1d0h5m24s
> Physical memory: 6126 MB
> Dumping 495 MB: 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256
> 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16
>
> #0 doadump () at pcpu.h:195
> 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) backtrace
> #0 doadump () at pcpu.h:195
> #1 0xc0505537 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
> #2 0xc05057f9 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:563
> #3 0xc04f3cb7 in _lockmgr (lkp=0xcc69ee28, flags=8212, interlkp=0xcc69ee58,
> td=0xcc11e660, file=0xc088d931 "/usr/src/sys/kern/vfs_subr.c", line=2213)
> at /usr/src/sys/kern/kern_lock.c:310
> #4 0xc05710b0 in vop_stdlock (ap=0xec5c6bfc)
> at /usr/src/sys/kern/vfs_default.c:266
> #5 0xc07734b6 in VOP_LOCK1_APV (vop=0xc0919180, a=0xec5c6bfc)
> at vnode_if.c:1618
> #6 0xc06cc3eb in ffs_lock (ap=0xec5c6bfc)
> at /usr/src/sys/ufs/ffs/ffs_vnops.c:391
> #7 0xc07734b6 in VOP_LOCK1_APV (vop=0xc09296c0, a=0xec5c6bfc)
> at vnode_if.c:1618
> #8 0xc057f9b1 in vput (vp=0xcc69edd0) at vnode_if.h:851
> #9 0xc06f9f54 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1025
> #10 0xc04e43c9 in fork_exit (callout=0xc06f8f30 , arg=0x0,
> frame=0xec5c6d38) at /usr/src/sys/kern/kern_fork.c:781
> #11 0xc0746f80 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205
> (kgdb)
>
>
> * KERNEL CONF **
>
> # Inherit config (most stuff) -- this is slightly customized version...
> # inherits from GENERIC-cust (tweaked to disable the default scheduler)
> include PAE-cust
>
> # Name of this kernel
> ident BEACON
>
>
> # Scheduler -- From /usr/src/sys/conf/NOTES:
> #
> # SCHED_ULE provides significant performance advantages over 4BSD on many
> # workloads on SMP machines. It supports cpu-affinity, per-cpu runqueues
> # and scheduler locks. It also has a stronger notion of interactivity
> # which leads to better responsiveness even on uniprocessor machines. This
> # will eventually become the default scheduler.
> #
> optionsSCHED_ULE
>
>
> # Note: we're compiling modules in statically since with PAE we don't want to
> # load KLDs. See comments in pae(4) and PAE kernel conf file.
>
> # Hardware Monitoring / Management
>
> device ipmi
>
> # Storage
>
> options GEOM_JOURNAL
>
> # Firewall
>
> device pf #PF OpenBSD packet-filter firewall
> device pflog #logging support interface for PF
> # device pfsync #synchronization interface for PF
>
> options ALTQ
>
> options ALTQ_CBQ
> options ALTQ_RED
> options ALTQ_RIO
> options ALTQ_HFSC
> options ALTQ_CDNR
> options ALTQ_PRIQ
>
> options ALTQ_NOPCC # Required for SMP builds
>
> # Linux Emulation
>
> options COMPAT_LINUX
> options LINPROCFS
> options LINSYSFS
>
> # Screen saver
>
> device green_saver
>
> ### Network perf tuning
>
> options ACCEPT_FILTER_HTTP
>
> # See polling(4))
>
> options DEVICE_POLLING
> options HZ=1000
>
> # End config
>
>
> ** Boot Log **
>
> May 16 02:34:18 gbs01-etc kernel: mfi0: 4167 (295774362s/0x0020/0) - Patrol
> Read complete
> May 16 02:56:01 gbs01-etc heartbeat: [2685]: WARN: Gmain_timeout_dispatch:
> Dispatch function for send local status took too long to execute: 789 ms (>
> 50 ms) (GSource: 0x28620930)
> May 16 09:46:08 gbs01-etc su: beacon to root on /dev/ttyp0
> May 16 16:03:47 gbs01-etc sshd[8012]: error: PAM: authentication error for
> beacon from 10.102.144.81
> May 16 16:05:41 gbs01-etc sshd[8017]: error: ssh
