Re: ZFS: i/o error - all block copies unavailable after upgrading to r225312
on 07/09/2011 19:35 Andriy Gapon said the following: Thanks to a lot of excellent testing, debugging and analysis from Sebastian (which went behind the scenes) we now have this patch: http://people.freebsd.org/~avg/zfs-boot-gang.diff The patch introduces the following changes: - checksum is now verified for gang header blocks - checksum is now verified for reconstituted data of whole gang blocks (previously it is verified only for individual gang member leaf blocks) - reconstituted data of a whole gang block is now decompressed if the gang block is compressed The last change is _the_ change. I am now investigating what looks like a miscompilation of the code by *gcc* after applying the patch. It seems that -mrtd option is to blame. I have found an older discussion about the -mrtd option causing trouble with clang: http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026263.html There was a patch that made clang happy without disabling the flag, so I wonder if I made some subtle mistake in my patch. Or maybe it's better to disable mrtd altogether for the zfs boot blocks, just to stay on the safe side. Some technical details in the form of a diff with some superimposed comments: --- /home/avg/tmp/vdev_read_phys-mrtd.s 2011-09-10 01:50:54.500620864 +0300 +++ /home/avg/tmp/vdev_read_phys-no-mrtd.s 2011-09-10 01:49:59.157701373 +0300 @@ -29,16 +29,17 @@ ... - in the code before this %edi gets assigned a pointer to a function movl60(%ecx), %eax movl%eax, 24(%esp) movl%ecx, 20(%esp) + movl%edi, %ecx - non-mrtd code saves the pointer popl%ebx popl%esi popl%edi - %edi gets over-written with an unrelated value popl%ebp - jmp *%edi - mrtd code calls some garbage code + jmp *%ecx - non-mrtd code calls the correct code .L601: movl$5, %eax popl%ebx popl%esi popl%edi popl%ebp - ret $24 + ret The problem is in the patched vdev_read_phys function in zfsimpl.c. Unpatched version of the function doesn't seem to be affected. Any help/ideas will be greatly appreciated! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS: i/o error - all block copies unavailable after upgrading to r225312
on 10/09/2011 10:32 Andriy Gapon said the following: I am now investigating what looks like a miscompilation of the code by *gcc* after applying the patch. It seems that -mrtd option is to blame. I have found an older discussion about the -mrtd option causing trouble with clang: http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026263.html There was a patch that made clang happy without disabling the flag, so I wonder if I made some subtle mistake in my patch. Or maybe it's better to disable mrtd altogether for the zfs boot blocks, just to stay on the safe side. Actually, removing either -mrtd _or_ -fno-unit-at-a-time produces the correct code. Puzzled. Some technical details in the form of a diff with some superimposed comments: --- /home/avg/tmp/vdev_read_phys-mrtd.s 2011-09-10 01:50:54.500620864 +0300 +++ /home/avg/tmp/vdev_read_phys-no-mrtd.s2011-09-10 01:49:59.157701373 +0300 @@ -29,16 +29,17 @@ ... - in the code before this %edi gets assigned a pointer to a function movl60(%ecx), %eax movl%eax, 24(%esp) movl%ecx, 20(%esp) + movl%edi, %ecx - non-mrtd code saves the pointer popl%ebx popl%esi popl%edi - %edi gets over-written with an unrelated value popl%ebp - jmp *%edi - mrtd code calls some garbage code + jmp *%ecx - non-mrtd code calls the correct code .L601: movl$5, %eax popl%ebx popl%esi popl%edi popl%ebp - ret $24 + ret The problem is in the patched vdev_read_phys function in zfsimpl.c. Unpatched version of the function doesn't seem to be affected. Any help/ideas will be greatly appreciated! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS: i/o error - all block copies unavailable after upgrading to r225312
on 10/09/2011 11:07 Andriy Gapon said the following: Actually, removing either -mrtd _or_ -fno-unit-at-a-time produces the correct code. Puzzled. The problem is reproducible with base gcc and gcc42, it is not reproducible with gcc45, gcc46 and clang. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cvsup broken on amd64?
On Fri, 09 Sep 2011 13:47:37 +0200 Oliver Lehmann lehm...@ans-netz.de wrote: Kostik Belousov kostik...@gmail.com wrote: For start, you should provide the information what exactly is the instruction that caused the fault. Show the disassembly from gdb for the function that caused the fault. Ok, I'm trying. I recompiled cvsup for purpose with -DSTATIC How do I continue from the gdb output below to help? nudel# gdb 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 amd64-marcel-freebsd. (gdb) file ./client/FBSD_AMD64/cvsup Reading symbols from ./client/FBSD_AMD64/cvsup...done. (gdb) exec-file ./client/FBSD_AMD64/cvsup (gdb) set args -g /usr/share/examples/cvsup/9-supfile (gdb) run Starting program: /usr/obj/amd64/usr/ports/net/cvsup-without-gui/work/cvsup-snap-16.1h/client/FBSD_AMD64/cvsup -g /usr/share/examples/cvsup/9-supfile Connected to cvsup.de.FreeBSD.org Updating collection src-all/cvs Edit src/crypto/openssl/ssl/s3_lib.c Program received signal SIGSEGV, Segmentation fault. 0x004d24c6 in tzload () [snip] Ah yes, I've seen this before. I don't know whether it's till the case, but my fix at the time (about 1 year ago) was to delete /usr/share/zoneinfo/UTC. I don't know whether that's even still installed. I know, it's just a work around and not a real fix. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS: i/o error - all block copies unavailable after upgrading to r225312
On 2011-Sep-10 12:46:50 +0300, Andriy Gapon a...@freebsd.org wrote: on 10/09/2011 11:07 Andriy Gapon said the following: Actually, removing either -mrtd _or_ -fno-unit-at-a-time produces the correct code. Puzzled. The problem is reproducible with base gcc and gcc42, it is not reproducible with gcc45, gcc46 and clang. I was just checking gcc44 gcc46. gcc44 inlines the entire function and I couldn't quickly find the offending code to see if the bug was there or not. I agree you've triggered a gcc bug but I'm not sure of the correct approach to fix it. I've tried a few trivial code transforms within vdev_read_phys() but haven't stumbled on one that avoids the problem. Since -mrtd changes the calling convention, it's a more intrusive change. I'm not sure if there's any simple way to alter CFLAGS for a single file (since we only want to alter the zfsboot.c compilation. -- Peter Jeremy pgpmdN08zKeyD.pgp Description: PGP signature
Re: Serial Port Configuration does not work
On Tue, 06 Sep 2011 16:29:51 +0400 Boris Samorodov wrote: the port does not work as expected (at least as per The Handbook, 26.2.5 Serial Port Configuration). Nether init nor lock devices can be used: - # uname -a FreeBSD host1.ipt.ru 9.0-BETA2 FreeBSD 9.0-BETA2 #14 r225395: Mon Sep 5 18:10:43 MSK 2011 b...@bb.ipt.ru:/usr/obj/usr/src/sys/HOSTS i386 # ls -l /dev/ttyu5* crw--- 1 root wheel0, 56 Sep 5 18:50 /dev/ttyu5 crw--- 1 root wheel0, 57 Sep 5 18:50 /dev/ttyu5.init crw--- 1 root wheel0, 58 Sep 5 18:50 /dev/ttyu5.lock # stty -f /dev/ttyu5.init 57600 stty: /dev/ttyu5.lock isn't a terminal # stty -f /dev/ttyu5.lock cs7 stty: /dev/ttyu5.lock isn't a terminal - Ping! -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
issue with old linuxbase.
Hi everybody! I've tried porting a few programs from Linux which's used a linuxulator. But I have the problem with old linux base system. My ports can't be run with old libstdc++.so.6 I have error with run linux apps. /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found strings /compat/linux/usr/lib/libstdc++.so.6|grep GLIBCXX GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_FORCE_NEW GLIBCXX_DEBUG_MESSAGE_LENGTH How to fix it or when'll upgraded linux base system? Site: http://www.zlonet.ru Skype: st_ss_19 g.veniamin(at)googlemail(dot)com XMMP: zloidemon(at)jabber(dot)ru signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ath0 no longer attaches, cardbus problems?
On Fri, 9 Sep 2011, Warner Losh wrote:
On Sep 9, 2011, at 1:22 PM, Daniel Eischen wrote:
I found the commit that broke ath for me, r222753,
specifically, the change to /dev/cardbus/cardbus_cis.c.
To be sure, I updated to head using svn, and applied
the patch included below. ath attaches and works. Without
the patch, ath does not attach.
On another note, I've no idea why updating from a local
CVS repo lead me down a wrong path. It seems wrong that
a 'cvs update -P -d -A -D 31 Mar 2011' works and
a 'cvs update -P -d -A -D 1 Apr 2011' does not work.
r222753 did not occur until much later (June 6).
Once John asked me to try r220195, I switched to using
svn. When that worked, it seemed strange to me because
nothing else committed after that on Mar 31 should have
broke ath.
Anyway, culprit found. Now what is the correct fix?
Do you need both chunks? The second one seems redundant given the definition
of bus_alloc_reosurce_any does exactly that.
I tried it separately with the 2 chunks, and only the first
chunk is needed. To be pedantic, this was the change that
made ath work again.
Index: sys/dev/cardbus/cardbus_cis.c
===
--- sys/dev/cardbus/cardbus_cis.c (revision 225463)
+++ sys/dev/cardbus/cardbus_cis.c (working copy)
@@ -441,6 +441,7 @@
{
if (res != CIS_CONFIG_SPACE) {
bus_release_resource(child, SYS_RES_MEMORY, rid, res);
+ bus_delete_resource(child, SYS_RES_MEMORY, rid);
}
}
While debugging the problem a couple of weeks ago, I did
seem to notice ath was trying to attach twice. I seem to
recall it was at different addresses. Could this possibly
cause the problem without the above patch?
--
DE
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Serial Port Configuration does not work
On Sat, 10 Sep 2011 15:57:25 +0400 Boris Samorodov b...@ipt.ru wrote: On Tue, 06 Sep 2011 16:29:51 +0400 Boris Samorodov wrote: the port does not work as expected (at least as per The Handbook, 26.2.5 Serial Port Configuration). Nether init nor lock devices can be used: - # uname -a FreeBSD host1.ipt.ru 9.0-BETA2 FreeBSD 9.0-BETA2 #14 r225395: Mon Sep 5 18:10:43 MSK 2011 b...@bb.ipt.ru:/usr/obj/usr/src/sys/HOSTS i386 # ls -l /dev/ttyu5* crw--- 1 root wheel0, 56 Sep 5 18:50 /dev/ttyu5 crw--- 1 root wheel0, 57 Sep 5 18:50 /dev/ttyu5.init crw--- 1 root wheel0, 58 Sep 5 18:50 /dev/ttyu5.lock # stty -f /dev/ttyu5.init 57600 stty: /dev/ttyu5.lock isn't a terminal # stty -f /dev/ttyu5.lock cs7 stty: /dev/ttyu5.lock isn't a terminal - Ping! Seems that the handbook is out of date. Looking at /sys/kern/tty.c the init and lock devices are only used internally and are not real open-able/close-able devices. Thye're created in tty_makedev() as required using make_dev_cred(), which is probably why they appear under /dev. The init device is initialized in tty_init_termios() and _never_ changed after that. It's only used to initialize real ttys. The lock device seems to only be used in tty_ioctl(). I wasn't able to figure out where it gets initialized. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: issue with old linuxbase.
On Sat, 10 Sep 2011 12:33:37 +0100 Veniamin Gvozdikov wrote: I've tried porting a few programs from Linux which's used a linuxulator. But I have the problem with old linux base system. My ports can't be run with old libstdc++.so.6 I have error with run linux apps. /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found strings /compat/linux/usr/lib/libstdc++.so.6|grep GLIBCXX GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_FORCE_NEW GLIBCXX_DEBUG_MESSAGE_LENGTH How to fix it You may try to replace libstdc++ package from the base port by the one from Fedora 11. But the result is unknown. FreeBSD-emulation is a better place to speak about the matter. or when'll upgraded linux base system? When somebody do the actual work. -- WBR, bsam ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Serial Port Configuration does not work
On Sat, 10 Sep 2011 16:08:21 +0200 Gary Jennejohn wrote: On Tue, 06 Sep 2011 16:29:51 +0400 Boris Samorodov wrote: the port does not work as expected (at least as per The Handbook, 26.2.5 Serial Port Configuration). Nether init nor lock devices can be used: Seems that the handbook is out of date. OK, how can I configure a serial port then? -- WBR, bsam ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: siba_bwn in GENERIC
Adrian Chadd wrote on 26.08.2011 15:15: On 26 August 2011 15:14, Ruslan Mahmatkhanovcvs-...@yandex.ru wrote: Good day! Right now we have this line in GENERIC: #device bwn # Broadcom BCM43xx wireless NICs From user POV all he need to do to make his broadcom wifi work, is to uncomment this line and recompile his kernel. But this actually not sufficient - he also need to add device siba_bwn, and then install net/bwn-firmware-kmod. But he will know that after recompiling his kernel when his wireless adapter will not work as expected :). So may be we need to also add siba_bwn (commented out by default) in GENERIC and some reference about net/bwn-firmware-kmod? I think it's a good idea, along with any other documentation related changes that need to occur. Thanks, Adrian Adrian, is there any hope this change will go to 9.0-R? Should i submit pr for that? -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FreeBSD 9.0-beta2 can't reboot with ZFS raidz2
Hi, My FreeBSD box (amd64, beta2, raidz2 on three disk) can't reboot after syncing buffer stage: http://www.scrnshots.com/users/subbsd/screenshots/293839 Also i got this issue on 8-disk system (GPT/ZFS). With UFS filesystem all ok on the same hardware ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: siba_bwn in GENERIC
Hi! #device bwn # Broadcom BCM43xx wireless NICs Does this by any chance also cover the BCM43224 ? -- p...@opsec.eu+49 171 3101372 9 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RELENG_8 / mpt / zpool Errors
I'm not sure what cards you can get now with the LSI 1068E chip. As LSI branded cards cost more, I went for for the LSI SAS2008 based Supermicro AOC-USAS2-L8i as I new I wasn't going to use port expanders. It could be hard to get cards with the older chip now (you might have to get something second hand). I'm not at all wedded to that card; any card that has two external ports will do for me. The bigger requirement is that it works well with FreeBSD 8.2 and eventually 9.0. If you had your pick of any (reasonably priced) card that had two external ports and would work in my configuration, which would it be? A port expander would be required and just a few older drives in the enclosure. A developer (of which I'm not) would need console access and ability to install new kernels, reboot etc. I can probably swing that, at least for a time, in 3 or 4 weeks. We have hardware on order that I can use to test with for a short while before it goes into production. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafsont...@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RELENG_8 / mpt / zpool Errors
On Sep 11, 2011 6:07 AM, Tim Gustafson t...@soe.ucsc.edu wrote: I'm not sure what cards you can get now with the LSI 1068E chip. As LSI branded cards cost more, I went for for the LSI SAS2008 based Supermicro AOC-USAS2-L8i as I knew I wasn't going to use port expanders. It could be hard to get cards with the older chip now (you might have to get something second hand). I'm not at all wedded to that card; any card that has two external ports will do for me. The bigger requirement is that it works well with FreeBSD 8.2 and eventually 9.0. If you had your pick of any (reasonably priced) card that had two external ports and would work in my configuration, which would it be? I don't know what's out there having chosen only one such card for home use. So you'll need to do your own research. Start with looking at any card with the right chip and then look for evidence that people have used said card with FreeBSD. A port expander would be required and just a few older drives in the enclosure. A developer (of which I'm not) would need console access and ability to install new kernels, reboot etc. I can probably swing that, at least for a time, in 3 or 4 weeks. We have hardware on order that I can use to test with for a short while before it goes into production. You should contact the driver maintainer and see if they're available inclined to take up your offer of hardware availability. You may also have access to some talented young students who might be interested in driver programming who could help. As a production user of FreeBSD it's always great if you can find a way to contribute back to the project in areas that help you too. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: siba_bwn in GENERIC
Please submit a PR so I/others don't forget. Then just follow through with an email to me w/ the PR number. Thanks, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: siba_bwn in GENERIC
On 11 September 2011 03:31, Kurt Jaeger li...@opsec.eu wrote: Hi! #device bwn # Broadcom BCM43xx wireless NICs Does this by any chance also cover the BCM43224 ? I'm not sure, I'm afraid. freebsd-wireless@ is likely a better list to try. I don't know who the current if_bwn maintainer is. Maybe the original author/porter would know - Weongyo Jeong weon...@freebsd.org . Thanks, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
