Re: Problems with zfsboot loader if raidz present on any drive
On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: Hello Hackers, Recently and friend and I have been trying to get the new gptzfsboot working on our machines and ran into a interesting problem. Initially I was building the world without the environment variable LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, didnt work very well. Every time the machine booted, it would throw 2 lines after the pin-wheel and then reboot. I couldent read what the lines were it went so fast. My friend had a bit more luck and got his machine working OK with a single drive and later a mirror drive added. I added the environment variable and rebuilt everything and installed. This time, I could see the bios drives and a further 2 lines of ZFS something and a reboot... No matter what I tried, I couldent get the machine to boot up to a point where I could try and fix the problem, so I started pulling devices out and found the following: If there is a raidz pool on any drive (not necessarily the one that you are trying to boot from) the loader dies and reboots the machine. My friend, as an experiment created 3 gpt partitions (in addition to the single partition that he had been previously booted from) on his single drive and made a raidz pool for testing. His machine showed the same condition as mine, however he was able to capture the message before the machine rebooted: ZFS: can only boot from disk or mirror vdevs ZFS: inconsistent nvlist contents The zfsboot code in current doesn't support raidz or raidz2. I have been working on adding that support but its not ready yet. The code works in my test harness but crashes instantly when I put it in the boot code :(. I should have time to finish debugging it soon. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with zfsboot loader if raidz present on any drive
On Sun, Dec 7, 2008 at 9:22 AM, Doug Rabson <[EMAIL PROTECTED]> wrote: > > On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: > >> Hello Hackers, >> >>Recently and friend and I have been trying to get the new >> gptzfsboot working >> on our machines and ran into a interesting problem. >> >>Initially I was building the world without the environment variable >> LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, didnt >> work >> very well. Every time the machine booted, it would throw 2 lines after the >> pin-wheel and then reboot. I couldent read what the lines were it went so >> fast. >> >>My friend had a bit more luck and got his machine working OK with a >> single >> drive and later a mirror drive added. >> >>I added the environment variable and rebuilt everything and >> installed. This >> time, I could see the bios drives and a further 2 lines of ZFS something >> and a >> reboot... >> >>No matter what I tried, I couldent get the machine to boot up to a >> point >> where I could try and fix the problem, so I started pulling devices out >> and >> found the following: If there is a raidz pool on any drive (not >> necessarily >> the one that you are trying to boot from) the loader dies and reboots the >> machine. My friend, as an experiment created 3 gpt partitions (in addition >> to >> the single partition that he had been previously booted from) on his >> single >> drive and made a raidz pool for testing. His machine showed the same >> condition >> as mine, however he was able to capture the message before the machine >> rebooted: >> >> >> ZFS: can only boot from disk or mirror vdevs >> >> ZFS: inconsistent nvlist contents > > The zfsboot code in current doesn't support raidz or raidz2. I have been > working on adding that support but its not ready yet. The code works in my > test harness but crashes instantly when I put it in the boot code :(. I > should have time to finish debugging it soon. > After installing my system yesterday on a single disk with gptzfsboot, I connected my old raidz and I only got cyclic reboots. I knew instantly it had something to do with the raidz. Disconnecting 2 out of the 4 disks of the raidz would allow the system to boot as the raidz would not present itself as ONLINE. As a temporary workaround for this problem I disabled those 2 disks on the BIOS, the system boots fine and the kernel is able to find them later. Doug, when you feel comfortable to share any patches, I'm willing to test :-) -- Joao Barros ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with zfsboot loader if raidz present on any drive
On Sunday 07 December 2008 09:22:16 Doug Rabson wrote: > On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: > > Hello Hackers, > > > > Recently and friend and I have been trying to get the new > > gptzfsboot working > > on our machines and ran into a interesting problem. > > > > Initially I was building the world without the environment variable > > LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, > > didnt work > > very well. Every time the machine booted, it would throw 2 lines > > after the > > pin-wheel and then reboot. I couldent read what the lines were it > > went so > > fast. > > > > My friend had a bit more luck and got his machine working OK with a > > single > > drive and later a mirror drive added. > > > > I added the environment variable and rebuilt everything and > > installed. This > > time, I could see the bios drives and a further 2 lines of ZFS > > something and a > > reboot... > > > > No matter what I tried, I couldent get the machine to boot up to a > > point > > where I could try and fix the problem, so I started pulling devices > > out and > > found the following: If there is a raidz pool on any drive (not > > necessarily > > the one that you are trying to boot from) the loader dies and > > reboots the > > machine. My friend, as an experiment created 3 gpt partitions (in > > addition to > > the single partition that he had been previously booted from) on his > > single > > drive and made a raidz pool for testing. His machine showed the same > > condition > > as mine, however he was able to capture the message before the machine > > rebooted: > > > > > > ZFS: can only boot from disk or mirror vdevs > > > > ZFS: inconsistent nvlist contents > > The zfsboot code in current doesn't support raidz or raidz2. I have > been working on adding that support but its not ready yet. The code > works in my test harness but crashes instantly when I put it in the > boot code :(. I should have time to finish debugging it soon. Hi Doug, In my haste to put a message to the group, I didnt do a very good job of explaining or give what platform I was working with. I set up a single disk pool with the gptzfsboot code on it as a boot drive. My idea was to have a single disk boot (and after it boots and I can kill the UFS drive I am currently booting from) convert it to a mirror. But I have 6 other drives in the machine that I have as a raidz for my /usr/home, et al. If the 6 raidz drives are present at boot time, the machine starts to cyclic reboot just after the pin-wheel. The machine I am working on is running FBSD8.0-Current as of midnight 7/12/2008 and the platform is AMD64. If I can help test in any way I would be more than happy to try, or provide any information necessary.. ~Peg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why FreeBSD not popular on hardware vendors
manufacturers of hardware. More recently there were times when anybody from because managers/bosses concentrate on majority, not minority of users. manufacturers did not notice Linux. However now it is possible to find a few given out "put normal OS - their list is at us on a site and then we will i recommend you to find "normal shop" to buy hardware, that allow you to fully test computer before buying. if you think there are larger (even hundreds means larger) start selling "FreeBSD compatible computers" in your area! You could make money on that, many people will easily spend 100$ more for computer that is already tested 100% FreeBSD compatible. All you have to do is to test/check lots of different parts of hardware if it actually work with FreeBSD fine, and make computers from that parts. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Timer driven tasks in FreeBSD 7
Hi All, What mechanism should I use for making my netwrok driver call a function every half a second, for instnace? I am already using task queues but I haven't found a way to make it work with a timer. Thanks Yony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Timer driven tasks in FreeBSD 7
On Sun, 7 Dec 2008 17:56:47 +0200, "Yony Yossef" <[EMAIL PROTECTED]> wrote: > Hi All, > > What mechanism should I use for making my netwrok driver call a > function every half a second, for instnace? > > I am already using task queues but I haven't found a way to make it > work with a timer. callout_xxx() functions should do the trick. See the timeout(9) manpage for more details. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Why safe using msleep with timeout=0 but not tsleep?
See subject. Interesting commit: http://svn.freebsd.org/viewvc/base?view=revision&revision=77059 - Marius ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Syscons with xterm emulation: one step closer to UTF-8 support?
Ed Schouten wrote: A couple of weeks ago I started working on a library (libteken) that implements a subset of features (escape sequences) of xterm, our trusty X11 terminal application. Ed, VT100 emulation in syscons is a great idea. The first time ;-) I implemented VT100 emulation I didn't know about all of the VT100 and VT220 torture tests floating around. If you haven't already, I strongly suggest you track down some of them. The various VT100 "movies" are useful tests and kind of fun to watch. Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD64 qemu completely broken?
On Thu, Dec 04, 2008 at 02:43:47PM -0800, Nate Eldredge wrote: > On Thu, 4 Dec 2008, Juergen Lock wrote: > >> I forgot to say the qemu-devel port (as well as the later snapshots I >> posted about on -emulation) also support -curses, which shows the emulated >> vga text(!)console on qemu's tty. This works quite well with FreeBSD guests >> (even the isos) if you extend your xterm/whatever by one line (the default >> vga textconsole is 80x25 instead of 80x24.) > > As long as we're sharing tips about qemu: > > I've recently been working with qemu on amd64 and have set up a Debian etch > i386 guest which is working well. I am using the qemu-devel and > kqemu-kmod-devel ports. I am not using -kernel-kqemu at the moment; I > thought I would get things working before trying to speed up. > > Using qemu I've finally achieved my goal of being able to use flash on > FreeBSD/amd64 (in some sense :-O). > Actually at least on RELENG_7 and later the original www/linux-flashplugin9 + www/nspluginwrapper don't work too bad at least for video sites these days (on 6 and 7.0 you need a patch and there it probably doesn't quite work on SMP because another patch concerning SMP can't be merged.) See e.g. this thread on -emulation for more: http://lists.freebsd.org/pipermail/freebsd-emulation/2008-October/005433.html (also later on that thread iirc were reports of hangs with ff3 and linux base fc4, so either use f7 or f8, or stick with ff2 for now, like if you're on 6 + linprocfs patch where only fc4 works. And you want to run that nspluginwrapper -i command under 5. as the user that will run the browser, not as root. Oh and that flash9 advisory is no longer an issue, it has been updated since.) I even got flash10 running, which probably can enter ports some time after the slush: http://lists.freebsd.org/pipermail/freebsd-emulation/2008-October/005438.html > savevm and loadvm don't work due to a security patch. Since my guest > system is trusted I reverted the patch. I filed a PR as ports/129417 . > Yup, fixed since. (I'm only saying this for the benefit of other readers. :) Merged a fix from debian sid kvm. > I found that '-net user' is horribly broken on amd64 (qemu segfaults). It > uses some ancient [*] BSD TCP/IP code (via slirp) which assumes that > pointers are 32 bits and doesn't hesitate to shove them into random 32-bit > corners of externally defined structures if it's convenient. Looks like a > pain to clean up. Yup slirp is ancient code and doesnt really work on 64 bit hosts. (as also mentioned in the qemu ports' pkg-message...) > '-net tap' works fine, but requires root privileges and > is more work to set up. > Actually it doesn't require root privs to run, only to setup. (Ok you _might_ need sudo to ifconfig the tap device and/or bridge in the qemu-ifup script... But qemu itself can certainly run as user.) > [*] Out of curiosity, I looked at some Unix Archive stuff and found the > identical code in BSD's Net2, circa 1991. It is identified in a comment as > a "quick hack" and adorned with several /* XXX */. Naturally the code and > the comments survive intact, 17 years later. :-( > This might be somewhat more understandable if you know that the original slirp code was written many moons ago and only later resurrected for emulation purposes. (It was originally invented for dialup users that logged into shellservers' gettys via serial modem lines so they could also use the box' inet connection locally before things like ppp were available...) Cheers, Juergen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Syscons with xterm emulation: one step closer to UTF-8 support?
* Tim Kientzle <[EMAIL PROTECTED]> wrote: > VT100 emulation in syscons is a great idea. > > The first time ;-) I implemented VT100 emulation I didn't > know about all of the VT100 and VT220 torture tests > floating around. If you haven't already, I strongly > suggest you track down some of them. The various > VT100 "movies" are useful tests and kind of fun to watch. Yes. That's a very good idea. So far I've mainly done testing with vttest, maintained by Thomas Dickey: http://invisible-island.net/vttest/vttest.html But I'll see if I can find others. They are very good to monitor regressions. -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://80386.nl/ pgpDHRDMOpkpr.pgp Description: PGP signature
crypto(9) choose another driver if we cannot open a session on it
Hello, I wrote a small patch to allow the crypto framework to choose another cryptographic driver if we cannot open a session on the driver. The current version selects the driver that handles all the requested algorithms and with the less count of active sessions. But this is not enough, by example the glxsb(4) driver does not accept AES session with key's length != 128 bits. It rejects also HMAC algorithms if there is no AES encryption to do in the session (HMAC is done by software to make it works with ipsec). The other way to deal with this problem would be to implement in the glxsb driver software implementations for AES 192 et AES 256. (OpenBSD did it recently). But I think this is a hack and it's better to revert to another driver. diff of sys/opencrypto/crypto.c between 8-CURRENT http://user.lamaiziere.net/patrick/opencrypto-071208/crypto.c-diff sys/opencrypto/crypto.c http://user.lamaiziere.net/patrick/opencrypto-071208/crypto.c That should not break anything. It would be nice to test it on a box with a Geode LX CPU and a crypto device like a VPN1411 card. I don't have the hardware but I've checked that we revert to the cryptosoft driver when using ipsec and glxsb with AES key's length != 128 bits. Thanks, regards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD64 qemu completely broken?
On Sun, 7 Dec 2008, Juergen Lock wrote: On Thu, Dec 04, 2008 at 02:43:47PM -0800, Nate Eldredge wrote: On Thu, 4 Dec 2008, Juergen Lock wrote: I forgot to say the qemu-devel port (as well as the later snapshots I posted about on -emulation) also support -curses, which shows the emulated vga text(!)console on qemu's tty. This works quite well with FreeBSD guests (even the isos) if you extend your xterm/whatever by one line (the default vga textconsole is 80x25 instead of 80x24.) As long as we're sharing tips about qemu: I've recently been working with qemu on amd64 and have set up a Debian etch i386 guest which is working well. I am using the qemu-devel and kqemu-kmod-devel ports. I am not using -kernel-kqemu at the moment; I thought I would get things working before trying to speed up. Using qemu I've finally achieved my goal of being able to use flash on FreeBSD/amd64 (in some sense :-O). Actually at least on RELENG_7 and later the original www/linux-flashplugin9 + www/nspluginwrapper don't work too bad at least for video sites these days (on 6 and 7.0 you need a patch and there it probably doesn't quite work on SMP because another patch concerning SMP can't be merged.) See e.g. this thread on -emulation for more: http://lists.freebsd.org/pipermail/freebsd-emulation/2008-October/005433.html Thanks for the pointer. I will probably wait until 7.1 is out and ports are defrosted, so I can go straight to flash10 and not to have to do everything twice, but this information should be very helpful. '-net tap' works fine, but requires root privileges and is more work to set up. Actually it doesn't require root privs to run, only to setup. (Ok you _might_ need sudo to ifconfig the tap device and/or bridge in the qemu-ifup script... But qemu itself can certainly run as user.) Okay. I was being lazy and letting qemu do some of that work for me. [*] Out of curiosity, I looked at some Unix Archive stuff and found the identical code in BSD's Net2, circa 1991. It is identified in a comment as a "quick hack" and adorned with several /* XXX */. Naturally the code and the comments survive intact, 17 years later. :-( This might be somewhat more understandable if you know that the original slirp code was written many moons ago and only later resurrected for emulation purposes. (It was originally invented for dialup users that logged into shellservers' gettys via serial modem lines so they could also use the box' inet connection locally before things like ppp were available...) Yep, I think I remember trying to use some slip implementation over a serial modem once. It's just unfortunate that qemu chose that code for their TCP/IP implementation rather than something else more modern. Not that I'm volunteering to update it :) -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
