Re: Problem with zfsloader on 9.2-BETA2
on 07/08/2013 00:26 J David said the following: > $ sudo ./bootparttest da2 > GEOM provider "da2" opened > Mediasize: 1000204886016 Bytes (1953525168 sectors) > Sectorsize: 512 Bytes > da2: read 1 blocks from the offset 0 [+0] > da2: read 1 blocks from the offset 1 [+0] > ptable_open: PMBR detected > da2: read 1 blocks from the offset 1 [+0] > gpt_checkhdr: invalid entry size or number of entries > da2: read 1 blocks from the offset 1953525167 [+0] > gpt_checkhdr: invalid entry size or number of entries > Partition table detected: None > > (Output for da3 - da7 are identical to da2.) Could you please hack gpt_checkhdr() in sys/boot/common/part.c to print all the relevant values for this check and try bootparttest again? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Help with filing a [maybe] ZFS/mmap bug.
on 18/07/2013 20:44 George Hartzell said the following: > Andriy Gapon writes: > > on 17/07/2013 23:47 George Hartzell said the following: > > > How should I move forward with this? > > > > Could you please try to reproduce this problem using a kernel built with > > INVARIANTS options? > > I added INVARIANT_SUPPORT and INVARIANTS options to the GENERIC > kernel, rebuilt it, installed it and running through my "test case" > generated a lot of invalid flac files. I"m not sure what the options > are/were supposed to do though, it looks like they generally lead to > KASSERTS, which lead to abort()'s. Nothing in /var/log/messages or on > the console. George, do you have anything new on this issue? Could you please try the following patch? http://people.freebsd.org/~avg/zfs-putpages.diff I expect it to not really fix the issue, but it may help to narrow it down. Please keep INVARIANTS. Thank you. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: unexpected idprio 31 behavior on 9.2-BETA2 and 9.2-RC1
On 2013/08/06 05:15, Dave Mischler wrote: I have an i5-2500 machine 8GB RAM now running 9.2-RC1 amd64 with the GENERIC kernel. Today, while still running 9.2-BETA2, I updated my source tree and started building world with idprio 31 and I looked back a while later and all the CPU cores and disk were essentially idle, and hardly any progress had been made on the build. I stopped and restarted the build without the idle priority setting and it ran fine. Anybody else seen any of this? Anybody know about any fairly recent changes that might account for it? I did a "rm -rf /usr/src /usr/obj" and loaded a new source tree before going to RC1. I still see odd behavior at RC1. Sometimes it works just like it should (i.e. compute bound processes use most/all of the available CPU time), but a lot of the time both the CPU and disk are idle (e.g. CPU 97.8% idle, disk 1% busy per systat). I don't think I ever saw this behavior before while running "make buildworld -j4". Can anyone else confirm/rebut my findings? Thanks. idle should never be used, it can cause long term priority inversion in kernel, make the system slower. ___ 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: unexpected idprio 31 behavior on 9.2-BETA2 and 9.2-RC1
on 06/08/2013 00:15 Dave Mischler said the following:
> I have an i5-2500 machine 8GB RAM now running 9.2-RC1 amd64 with the
> GENERIC kernel. Today, while still running 9.2-BETA2, I updated my
> source tree and started building world with idprio 31 and I looked back
> a while later and all the CPU cores and disk were essentially idle, and
> hardly any progress had been made on the build. I stopped and restarted
> the build without the idle priority setting and it ran fine. Anybody
> else seen any of this? Anybody know about any fairly recent changes that
> might account for it?
>
> I did a "rm -rf /usr/src /usr/obj" and loaded a new source tree before
> going to RC1. I still see odd behavior at RC1. Sometimes it works just
> like it should (i.e. compute bound processes use most/all of the
> available CPU time), but a lot of the time both the CPU and disk are
> idle (e.g. CPU 97.8% idle, disk 1% busy per systat). I don't think I
> ever saw this behavior before while running "make buildworld -j4". Can
> anyone else confirm/rebut my findings? Thanks.
Are you sure that you really want to use idprio for a goal you want to achieve?
If yes, are you sure that you want to use idprio 31 specifically?
With sched_ule idprio 31 is equivalent to priority of a completely idle system.
So the scheduler is in its right to run the idle ("do nothing") thread instead
of your thread(s).
P.S.
https://wiki.freebsd.org/AvgThreadPriorityRanges
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with zfsloader on 9.2-BETA2
On 07.08.2013 01:26, J David wrote: > On Tue, Aug 6, 2013 at 5:53 AM, Andrey V. Elsukov wrote: >> looking to your `zfs status` output and this, we can see, that GPT >> wasn't detected on most of disks. Can you try to boot with this loader: >> http://people.freebsd.org/~ae/zfsloader >> It's from 10-CURRENT and was build with -DPART_DEBUG, so you will see >> some additional debug messages while booting. > > OK, some of the output scrolls too fast… since it can't load the > filesystem it doesn't know to copy to serial console. > > But looking at the tail end, it's a lot of this: > > gpt_checkhdr: invalid entry size or number of entries > gpt_checkhdr: invalid entry size or number of entries > ptable_open: PMBR detected > > At least five sets of those, so I assume they are for at least disk2 - > disk 7. Unfortunately I can't catch the output for disks 1 and 2, > which are the only two bootable disks. :( > > Here's the bootparttest output: > > $ sudo ./bootparttest da0 > GEOM provider "da0" opened > Mediasize: 32296140800 Bytes (63078400 sectors) > Sectorsize: 512 Bytes > da0: read 1 blocks from the offset 0 [+0] > da0: read 1 blocks from the offset 1 [+0] > ptable_open: PMBR detected > da0: read 1 blocks from the offset 1 [+0] > da0: read 32 blocks from the offset 2 [+0] > da0: read 1 blocks from the offset 63078399 [+0] > ptable_gptread: new GPT partition added > ptable_gptread: new GPT partition added > ptable_gptread: new GPT partition added > Partition table detected: GPT > da0p1: FreeBSD boot 64k > da0p2: FreeBSD swap 2048M > da0p3: FreeBSD ZFS 28G > GEOM provider "da1" opened > Mediasize: 320 Bytes (6250 sectors) > Sectorsize: 512 Bytes > da1: read 1 blocks from the offset 0 [+0] > da1: read 1 blocks from the offset 1 [+0] > ptable_open: PMBR detected > da1: read 1 blocks from the offset 1 [+0] > da1: read 32 blocks from the offset 2 [+0] > da1: read 1 blocks from the offset 6249 [+0] > ptable_gptread: new GPT partition added > ptable_gptread: new GPT partition added > ptable_gptread: new GPT partition added > Partition table detected: GPT > da1p1: FreeBSD boot 64k > da1p2: FreeBSD swap 2048M > da1p3: FreeBSD ZFS 27G > $ sudo ./bootparttest da2 > GEOM provider "da2" opened > Mediasize: 1000204886016 Bytes (1953525168 sectors) > Sectorsize: 512 Bytes > da2: read 1 blocks from the offset 0 [+0] > da2: read 1 blocks from the offset 1 [+0] > ptable_open: PMBR detected > da2: read 1 blocks from the offset 1 [+0] > gpt_checkhdr: invalid entry size or number of entries > da2: read 1 blocks from the offset 1953525167 [+0] > gpt_checkhdr: invalid entry size or number of entries > Partition table detected: None > > (Output for da3 - da7 are identical to da2.) > > So I'm guessing something doesn't like the metadata on the data drives. Hi, can you please dump first 34 blocks from da2 and send to me? i.e., # dd if=/dev/da2 of=./gpt count=34 Also, it is interesting, what tool did you use for partitioning? -- WBR, Andrey V. Elsukov ___ 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: wireless networking probelm with WEP
> De : owner-freebsd-wirel...@freebsd.org [mailto:owner-freebsd- > wirel...@freebsd.org] De la part de Oliver Pinter > Envoyé : mardi 6 août 2013 16:56 > À : freebsd-wirel...@freebsd.org; sta...@freebsd.org > Cc : adr...@freebsd.org > Objet : wireless networking probelm with WEP > > Hi All! Hello Oliver, > > I run in to problem, what described in some more place: > http://149.20.54.209/showthread.php?t=39724 . > > The concrete problem is: when I use FreeBSD with WEP, there are no RX > traffic received. Why using WEP ? It's a security hole. How is the network configured ? At boot time or by hand ? > So, when I probed a DHCP request, then here are no response from DHCP > server. > > The OS is: FreeBSD 9.2-BETA2 (freebsd-stable). > ___ > freebsd-wirel...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless- > unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: wireless networking probelm with WEP
On 8/7/13, Cedric GROSS wrote: >> De : owner-freebsd-wirel...@freebsd.org [mailto:owner-freebsd- >> wirel...@freebsd.org] De la part de Oliver Pinter >> Envoyé : mardi 6 août 2013 16:56 >> À : freebsd-wirel...@freebsd.org; sta...@freebsd.org >> Cc : adr...@freebsd.org >> Objet : wireless networking probelm with WEP >> >> Hi All! > > > Hello Oliver, > >> >> I run in to problem, what described in some more place: >> http://149.20.54.209/showthread.php?t=39724 . >> >> The concrete problem is: when I use FreeBSD with WEP, there are no RX >> traffic received. > > Why using WEP ? It's a security hole. Because there is no other. > > How is the network configured ? At boot time or by hand ? Both. And now I try to debug, why not work... So I'm now deep in the kernel source. > > >> So, when I probed a DHCP request, then here are no response from DHCP >> server. >> >> The OS is: FreeBSD 9.2-BETA2 (freebsd-stable). >> ___ >> freebsd-wirel...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to "freebsd-wireless- >> 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"
[releng_9 tinderbox] failure on amd64/amd64
TB --- 2013-08-07 08:55:22 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-08-07 08:55:22 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtan...@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-08-07 08:55:22 - starting RELENG_9 tinderbox run for amd64/amd64 TB --- 2013-08-07 08:55:22 - cleaning the object tree TB --- 2013-08-07 08:55:22 - /usr/local/bin/svn stat /src TB --- 2013-08-07 08:55:27 - At svn revision 254052 TB --- 2013-08-07 08:55:28 - building world TB --- 2013-08-07 08:55:28 - CROSS_BUILD_TESTING=YES TB --- 2013-08-07 08:55:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-07 08:55:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-07 08:55:28 - SRCCONF=/dev/null TB --- 2013-08-07 08:55:28 - TARGET=amd64 TB --- 2013-08-07 08:55:28 - TARGET_ARCH=amd64 TB --- 2013-08-07 08:55:28 - TZ=UTC TB --- 2013-08-07 08:55:28 - __MAKE_CONF=/dev/null TB --- 2013-08-07 08:55:28 - cd /src TB --- 2013-08-07 08:55:28 - /usr/bin/make -B buildworld >>> World build started on Wed Aug 7 08:55:29 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Aug 7 12:48:01 UTC 2013 TB --- 2013-08-07 12:48:01 - generating LINT kernel config TB --- 2013-08-07 12:48:01 - cd /src/sys/amd64/conf TB --- 2013-08-07 12:48:01 - /usr/bin/make -B LINT TB --- 2013-08-07 12:48:01 - cd /src/sys/amd64/conf TB --- 2013-08-07 12:48:01 - /usr/sbin/config -m LINT TB --- 2013-08-07 12:48:01 - building LINT kernel TB --- 2013-08-07 12:48:01 - CROSS_BUILD_TESTING=YES TB --- 2013-08-07 12:48:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-07 12:48:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-07 12:48:01 - SRCCONF=/dev/null TB --- 2013-08-07 12:48:01 - TARGET=amd64 TB --- 2013-08-07 12:48:01 - TARGET_ARCH=amd64 TB --- 2013-08-07 12:48:01 - TZ=UTC TB --- 2013-08-07 12:48:01 - __MAKE_CONF=/dev/null TB --- 2013-08-07 12:48:01 - cd /src TB --- 2013-08-07 12:48:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Aug 7 12:48:01 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/initcpu.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/io.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-flo
FreeBSD9.2-RC1 bootonly network installation fetch error (snapshots vs releases)
Hello :-) I am installing the 9.2-RC1 bootonly iso which wants to download stuff from snapshots while it is in releases directory: Installer wants to get 9.2-RC1 stuff from here (where it is missing): ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/i386/ While the stuff is at: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.2-RC1/ Please fix :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD-Update + Sendmail
On Tue, Aug 06, 2013 at 10:43:49PM +0100, Matthew Seaman wrote: > On 06/08/2013 22:28, Thomas Laus wrote: > > I like the 'sendmail from ports' suggestion a little better. Going this > > route, I only need to make configuration changes to /etc/mail/mailer.conf > > once. All subsequent freebsd-update operations won't require rebuilding > > sendmail and it's tools. Any updates to the port version are covered by > > the > > normal port update system. Future updates to the port version only require > > a > > 'make restart' in the /etc/mail directory after reviewing my .mc file for > > any > > affected changes. > > If you're using the ports version of sendmail, a handy tip is to add > this to /etc/make.conf: > > SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf > MAKEMAP=/usr/local/sbin/makemap > > so you use a version of the sendmail M4 config bits that matches the > sendmail binary you're running, and you can use /etc/mail/Makefile to > generate and install the configs exactly as if you were using the base > system sendmail. Indeed, plus: SENDMAIL=/usr/local/sbin/sendmail And in /etc/rc.conf: sendmail_program="/usr/local/sbin/sendmail" Regards, Panagiotis -- Panagiotis J. ChristiasNetwork Management Center p.christ...@noc.ntua.grNational Technical Univ. of Athens, GREECE ___ 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: FreeBSD9.2-RC1 bootonly network installation fetch error (snapshots vs releases)
On Wed, Aug 07, 2013 at 04:18:41PM +0200, CeDeROM wrote: > Hello :-) > > I am installing the 9.2-RC1 bootonly iso which wants to download stuff from > snapshots while it is in releases directory: > > Installer wants to get 9.2-RC1 stuff from here (where it is missing): > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/i386/ > > While the stuff is at: > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.2-RC1/ > > Please fix :-) > Ugh. I'll get this fixed as soon as possible. Thank you for the report. Glen pgpYUNOSwUmEy.pgp Description: PGP signature
Re: FreeBSD9.2-RC1 bootonly network installation fetch error (snapshots vs releases)
On Wed, Aug 7, 2013 at 4:31 PM, Glen Barber wrote: > On Wed, Aug 07, 2013 at 04:18:41PM +0200, CeDeROM wrote: >> I am installing the 9.2-RC1 bootonly iso which wants to download stuff from >> snapshots while it is in releases directory: > > Ugh. I'll get this fixed as soon as possible. > Thank you for the report. > Glen Sure thing! No problem! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD-Update + Sendmail
On 07/08/2013 15:19, Panagiotis Christias wrote: > On Tue, Aug 06, 2013 at 10:43:49PM +0100, Matthew Seaman wrote: >> On 06/08/2013 22:28, Thomas Laus wrote: >>> I like the 'sendmail from ports' suggestion a little better. Going this >>> route, I only need to make configuration changes to /etc/mail/mailer.conf >>> once. All subsequent freebsd-update operations won't require rebuilding >>> sendmail and it's tools. Any updates to the port version are covered by >>> the >>> normal port update system. Future updates to the port version only require >>> a >>> 'make restart' in the /etc/mail directory after reviewing my .mc file for >>> any >>> affected changes. >> >> If you're using the ports version of sendmail, a handy tip is to add >> this to /etc/make.conf: >> >> SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf >> MAKEMAP=/usr/local/sbin/makemap >> >> so you use a version of the sendmail M4 config bits that matches the >> sendmail binary you're running, and you can use /etc/mail/Makefile to >> generate and install the configs exactly as if you were using the base >> system sendmail. > > > Indeed, plus: > > SENDMAIL=/usr/local/sbin/sendmail > > And in /etc/rc.conf: > > sendmail_program="/usr/local/sbin/sendmail" /etc/mail/mailer.conf does that bit for you. Cheers, Matthew ___ 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: FreeBSD9.2-RC1 bootonly network installation fetch error (snapshots vs releases)
On Wed, Aug 07, 2013 at 04:48:58PM +0200, CeDeROM wrote: > On Wed, Aug 7, 2013 at 4:31 PM, Glen Barber wrote: > > On Wed, Aug 07, 2013 at 04:18:41PM +0200, CeDeROM wrote: > >> I am installing the 9.2-RC1 bootonly iso which wants to download stuff from > >> snapshots while it is in releases directory: > > > > Ugh. I'll get this fixed as soon as possible. > > Thank you for the report. > > Glen > > Sure thing! No problem! :-) > Some mirrors have already begun to pick up the change. Sorry for the inconvenience. It was my fault. :( Glen pgpQSLb3UwOjI.pgp Description: PGP signature
Re: FreeBSD9.2-RC1 bootonly network installation fetch error (snapshots vs releases)
On Wed, Aug 7, 2013 at 5:04 PM, Glen Barber wrote: > Some mirrors have already begun to pick up the change. > Sorry for the inconvenience. It was my fault. :( > Glen Naah, this is still 9.2-RC1 for testing, important that 9.2-RELEASE gets fine :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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: unexpected idprio 31 behavior on 9.2-BETA2 and 9.2-RC1
On 08/07/2013 04:09, Andriy Gapon wrote:
> on 06/08/2013 00:15 Dave Mischler said the following:
>> I have an i5-2500 machine 8GB RAM now running 9.2-RC1 amd64 with the
>> GENERIC kernel. Today, while still running 9.2-BETA2, I updated my
>> source tree and started building world with idprio 31 and I looked back
>> a while later and all the CPU cores and disk were essentially idle, and
>> hardly any progress had been made on the build. I stopped and restarted
>> the build without the idle priority setting and it ran fine. Anybody
>> else seen any of this? Anybody know about any fairly recent changes that
>> might account for it?
>>
>> I did a "rm -rf /usr/src /usr/obj" and loaded a new source tree before
>> going to RC1. I still see odd behavior at RC1. Sometimes it works just
>> like it should (i.e. compute bound processes use most/all of the
>> available CPU time), but a lot of the time both the CPU and disk are
>> idle (e.g. CPU 97.8% idle, disk 1% busy per systat). I don't think I
>> ever saw this behavior before while running "make buildworld -j4". Can
>> anyone else confirm/rebut my findings? Thanks.
> Are you sure that you really want to use idprio for a goal you want to
> achieve?
> If yes, are you sure that you want to use idprio 31 specifically?
> With sched_ule idprio 31 is equivalent to priority of a completely idle
> system.
> So the scheduler is in its right to run the idle ("do nothing") thread
> instead
> of your thread(s).
That sounds like a bug to me, or a POLA violation at least. A user
thread should never have the same priority as the idle threads, because
a user thread, by definition, has work to do.
>From the rtprio(1) examples:
To make depend while not disturbing other machine usage:
idprio 31 make depend
> P.S.
> https://wiki.freebsd.org/AvgThreadPriorityRanges
Nice! Thank you for writing it and sending the link.
Eric
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD-Update + Sendmail
On Wed, Aug 07, 2013 at 04:02:14PM +0100, Matthew Seaman wrote: > On 07/08/2013 15:19, Panagiotis Christias wrote: > > On Tue, Aug 06, 2013 at 10:43:49PM +0100, Matthew Seaman wrote: > >> On 06/08/2013 22:28, Thomas Laus wrote: > >>> I like the 'sendmail from ports' suggestion a little better. Going this > >>> route, I only need to make configuration changes to /etc/mail/mailer.conf > >>> once. All subsequent freebsd-update operations won't require rebuilding > >>> sendmail and it's tools. Any updates to the port version are covered by > >>> the > >>> normal port update system. Future updates to the port version only > >>> require a > >>> 'make restart' in the /etc/mail directory after reviewing my .mc file for > >>> any > >>> affected changes. > >> > >> If you're using the ports version of sendmail, a handy tip is to add > >> this to /etc/make.conf: > >> > >> SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf > >> MAKEMAP=/usr/local/sbin/makemap > >> > >> so you use a version of the sendmail M4 config bits that matches the > >> sendmail binary you're running, and you can use /etc/mail/Makefile to > >> generate and install the configs exactly as if you were using the base > >> system sendmail. > > > > > > Indeed, plus: > > > > SENDMAIL=/usr/local/sbin/sendmail > > > > And in /etc/rc.conf: > > > > sendmail_program="/usr/local/sbin/sendmail" > > /etc/mail/mailer.conf does that bit for you. Hm, you are right. -- Panagiotis J. ChristiasNetwork Management Center p.christ...@noc.ntua.grNational Technical Univ. of Athens, GREECE ___ 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"
Enabling pf in 9-STABLE guest on KVM triggers abrt crash report
I have been using 9-STABLE as a guest under KVM on RHEL 6 for several months
now without incident. I am using the virtio drivers and using bridged
networking on the host to attach my guests.
Recently, I enabled pf in one of my 9-STABLE (r253579) guests and subsequently
started to receive intermittent crash reports from abrt on the KVM host. Has
anyone else encountered problems using pf under KVM virtualisation?
A typical crash report from the host goes like this:
=
abrt_version: 2.0.8
cmdline:ro root=/dev/mapper/chumby-root rd_LVM_LV=chumby/root
rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=chumby/swap SYSFONT=latarcyrheb-sun16
crashkernel=137M@0M rd_MD_UUID=b7338ac5:b08fdc1b:34d0fcf1:cf28da17
KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet console=tty0
console=ttyS1,115200
kernel: 2.6.32-358.14.1.el6.x86_64
not-reportable: A kernel problem occurred, but your kernel has been tainted
(flags:GW ). Kernel maintainers are unable to diagnose tainted reports.
time: Wed 07 Aug 2013 11:41:22 AM EDT
sosreport.tar.xz: Binary file, 2114408 bytes
backtrace:
:WARNING: at net/core/dev.c:1759 skb_gso_segment+0x1df/0x2b0() (Tainted: G
W --- )
:Hardware name: AX1204-819-R700UB
:igb: caps=(0x12114bb3, 0x0) len=2084 data_len=0 ip_summed=0
:Modules linked in: iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
iptable_filter ip_tables ebtable_nat ebtables xt_CHECKSUM cpufreq_ondemand
powernow_k8 freq_table mperf bridge stp llc ipt_REJECT ip6t_REJECT
nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter
ip6_tables ipv6 ext2 vhost_net macvtap macvlan tun kvm_amd kvm igb dca ptp
pps_core microcode sg serio_raw fam15h_power k10temp amd64_edac_mod edac_core
edac_mce_amd i2c_piix4 i2c_core shpchp ext4 mbcache jbd2 raid1 sr_mod cdrom
sd_mod crc_t10dif pata_acpi ata_generic pata_atiixp ahci dm_mirror
dm_region_hash dm_log dm_mod [last unloaded: nf_defrag_ipv4]
:Pid: 3262, comm: vhost-3242 Tainted: GW ---
2.6.32-358.14.1.el6.x86_64 #1
:Call Trace:
: [] ? warn_slowpath_common+0x87/0xc0
:[] ? warn_slowpath_fmt+0x46/0x50
:[] ? igb_get_drvinfo+0x82/0xe0 [igb]
:[] ? skb_gso_segment+0x1df/0x2b0
:[] ? dev_hard_start_xmit+0x1b0/0x530
:[] ? sch_direct_xmit+0x15a/0x1c0
:[] ? dev_queue_xmit+0x3b0/0x550
:[] ? br_dev_queue_push_xmit+0x6c/0xa0 [bridge]
:[] ? br_forward_finish+0x58/0x60 [bridge]
:[] ? __br_forward+0xaa/0xd0 [bridge]
:[] ? nf_hook_slow+0x74/0x110
:[] ? br_forward+0x5d/0x70 [bridge]
:[] ? br_handle_frame_finish+0x179/0x2a0 [bridge]
:[] ? rebalance_domains+0x1a6/0x5a0
:[] ? br_handle_frame+0x1aa/0x250 [bridge]
:[] ? __netif_receive_skb+0x529/0x750
:[] ? process_backlog+0x9a/0x100
:[] ? net_rx_action+0x103/0x2f0
:[] ? __do_softirq+0xc1/0x1e0
:[] ? call_softirq+0x1c/0x30
:[] ? call_softirq+0x1c/0x30
: [] ? do_softirq+0x65/0xa0
:[] ? netif_rx_ni+0x28/0x30
:[] ? tun_sendmsg+0x229/0x4ec [tun]
:[] ? handle_tx+0x275/0x5e0 [vhost_net]
:[] ? handle_tx_kick+0x15/0x20 [vhost_net]
:[] ? vhost_worker+0xbc/0x140 [vhost_net]
:[] ? vhost_worker+0x0/0x140 [vhost_net]
:[] ? kthread+0x96/0xa0
:[] ? child_rip+0xa/0x20
:[] ? kthread+0x0/0xa0
:[] ? child_rip+0x0/0x20
=
I get these crash reports even with a simple firewall rule set like this:
=
# $FreeBSD: stable/9/share/examples/pf/pf.conf 218854 2011-02-19
14:57:00Z brucec $
# $OpenBSD: pf.conf,v 1.34 2007/02/24 19:30:59 millert Exp $
#
# See pf.conf(5) and /usr/share/examples/pf for syntax and examples.
# Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1
# in /etc/sysctl.conf if packets are to be forwarded between interfaces.
ext_if="vtnet0"
set skip on lo
scrub in
block in
pass out
pass in on $ext_if proto tcp to ($ext_if) port ssh
pass in on $ext_if inet proto icmp from any to ($ext_if) icmp-type { unreach,
redir, timex }
=
Does anyone know of any problems using pf with the virtio vtnet driver, or
indeed in using pf at all under KVM virtualisation? For now, I've turned off
pf, but I would like to be able to enable it in future to do firewalling on the
virtual guest. I have no problems using iptables for firewalling on my Linux
KVM guests.
Cheers,
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: Sendmail-8.14.7 doesn't work with MS DNS in IPv4 network
> I found a problem in new FreeBSD 9.2-{BETA2,RC1} which uses Sendmail-8.14.7.
> If you try to send email from FreeBSD 9.2 in IPv4 network with MS DNS
> you won't receive it.
> But in same time email passes from FreeBSD 9.1-RELEASE which uses
> Sendmail-8.14.5.
The recent release made the following change:
--- sendmail/conf.c 25 Jan 2011 18:31:30 - 8.1168
+++ sendmail/conf.c 5 Apr 2013 17:39:09 - 8.1182
@@ -4726,7 +4726,12 @@
#else /* (SOLARIS > 1 && SOLARIS < 20400) || (defined(SOLARIS) && SOLARIS
< 204) || (defined(sony_news) && defined(__svr4)) */
int nmaps;
# if NETINET6
- int flags = AI_DEFAULT|AI_ALL;
+# ifndef SM_IPNODEBYNAME_FLAGS
+/* For IPv4-mapped addresses, use: AI_DEFAULT|AI_ALL */
+# define SM_IPNODEBYNAME_FLAGS AI_ADDRCONFIG
+# endif /* SM_IPNODEBYNAME_FLAGS */
+
+ int flags = SM_IPNODEBYNAME_FLAGS;
int err;
# endif /* NETINET6 */
char *maptype[MAXMAPSTACK];
Which is described in this release note:
Drop support for IPv4-mapped IPv6 addresses to prevent the MTA
from using a mapped address over a legitimate IPv6 address
and to enforce the proper semantics over the IPv6
connection. Problem noted by Ulrich Sporlein.
It looks like that SERVFAIL from Microsoft's DNS server is getting
in the way of that. I can look at adding this exception to
WorkAroundBroken as a possibility for a future release.
I'd also like to hear feedback on whether the above change (changing
getipnodebyname() flags from 'AI_DEFAULT | AI_ALL' to 'AI_ADDRCONFIG' went
too far and what the accepted norm is for getipnodebyname().
___
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 9.2-RC1 i386 frozen to death
Hey :-) I have just installed FreeBSD 9.2-RC1 on Dell Latitude D620 i386 laptop. After first run and installation of some packets with pkg(ng) then some xorg configuration when I was in console it hung badly with totally no response. This looks bad :-( http://www.youtube.com/watch?v=7Tngr7YpP_I Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.2-RC1 i386 frozen to death
No crashdump was made, I was on second console so I dont know what happened exactly, no backtrace, nothing, sorry :-( -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS in jails 9.2-RC1 permission denied
Hi list, With a 9.1 system and the following: /etc/sysctl.conf: security.jail.mount_allowed=1 security.jail.mount_zfs_allowed=1 security.jail.enforce_statfs=1 zfs set jailed=on Pool zfs jail 1 Pool jexec 1 tcsh jail1# zfs create Pool/test1 jail1# zfs list NAME USED AVAIL REFER MOUNTPOINT Pool 223K 19.6G31K /Pool Pool/test1 31K 19.6G31K /Pool/test After upgrading to 9.2-RC1 the same operation results in: jail1# zfs create Pool/test2 cannot create 'Pool/test2': permission denied What am I missing? Thanks -- George Kontostanos --- ___ 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: [releng_9 tinderbox] failure on amd64/amd64
On Wed, Aug 07, 2013 at 01:09:08PM +, FreeBSD Tinderbox wrote: > /src/sys/amd64/amd64/machdep.c: In function 'db_show_sysregs': > /src/sys/amd64/amd64/machdep.c:1226: error: 'MSR_IA32_FEATURE_CONTROL' > undeclared (first use in this function) Should be fixed with the r254066, sorry for the breakage. pgpRuU_ZfZ70O.pgp Description: PGP signature
Some missong patches in 9.2-RC2
Hello, I went through my local patches against base/releng/, 9.2 in that case. There are some fixes which are noct in 9.2-RC1: - Regarding kerberized builds: http://lists.freebsd.org/pipermail/freebsd-bugs/2011-April/043902.html - Regarding mfi and >2TB corruption, seems MFC reminder failed http://www.freebsd.org/cgi/query-pr.cgi?pr=173291 - Regarding mount failok (seems r230226 got lost?) http://www.freebsd.org/cgi/query-pr.cgi?pr=163668&cat=conf I guess it's far too late to get anything i n9.2 but maby 9.3? Sorry, I couldn't find time to chekc this earlier :-( Thanks, -Harry ___ 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: Sendmail-8.14.7 doesn't work with MS DNS in IPv4 network
On 8/7/2013 12:05 PM, Gregory Shapiro wrote:
>> I found a problem in new FreeBSD 9.2-{BETA2,RC1} which uses Sendmail-8.14.7.
>> If you try to send email from FreeBSD 9.2 in IPv4 network with MS DNS
>> you won't receive it.
>> But in same time email passes from FreeBSD 9.1-RELEASE which uses
>> Sendmail-8.14.5.
> The recent release made the following change:
>
> --- sendmail/conf.c 25 Jan 2011 18:31:30 - 8.1168
> +++ sendmail/conf.c 5 Apr 2013 17:39:09 - 8.1182
> @@ -4726,7 +4726,12 @@
> #else /* (SOLARIS > 1 && SOLARIS < 20400) || (defined(SOLARIS) &&
> SOLARIS < 204) || (defined(sony_news) && defined(__svr4)) */
> int nmaps;
> # if NETINET6
> - int flags = AI_DEFAULT|AI_ALL;
> +# ifndef SM_IPNODEBYNAME_FLAGS
> +/* For IPv4-mapped addresses, use: AI_DEFAULT|AI_ALL */
> +# define SM_IPNODEBYNAME_FLAGS AI_ADDRCONFIG
> +# endif /* SM_IPNODEBYNAME_FLAGS */
> +
> + int flags = SM_IPNODEBYNAME_FLAGS;
> int err;
> # endif /* NETINET6 */
> char *maptype[MAXMAPSTACK];
>
> Which is described in this release note:
>
> Drop support for IPv4-mapped IPv6 addresses to prevent the MTA
> from using a mapped address over a legitimate IPv6 address
> and to enforce the proper semantics over the IPv6
> connection. Problem noted by Ulrich Sporlein.
>
> It looks like that SERVFAIL from Microsoft's DNS server is getting
> in the way of that. I can look at adding this exception to
> WorkAroundBroken as a possibility for a future release.
>
> I'd also like to hear feedback on whether the above change (changing
> getipnodebyname() flags from 'AI_DEFAULT | AI_ALL' to 'AI_ADDRCONFIG' went
> too far and what the accepted norm is for getipnodebyname().
>
getipnodebyname() is deprecated... getaddrinfo() should be used in this ipv6
world instead.
-lee
___
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 with zfsloader on 9.2-BETA2
On Wed, Aug 7, 2013 at 4:08 AM, Andriy Gapon wrote:
> Could you please hack gpt_checkhdr() in sys/boot/common/part.c to print all
> the
> relevant values for this check and try bootparttest again?
Your wish is my command:
--- common/part.c.orig 2013-08-05 19:00:49.536868414 +
+++ common/part.c 2013-08-07 18:34:09.277972724 +
@@ -184,7 +184,7 @@
if (hdr->hdr_entries < 128 ||
hdr->hdr_entsz < sizeof(struct gpt_ent) ||
sectorsize % hdr->hdr_entsz != 0) {
- DEBUG("invalid entry size or number of entries");
+ DEBUG("invalid entry size (%u/%lu) or number of entries (%u)",
hdr->hdr_entsz, sizeof(struct gpt_ent), hdr->hdr_entries);
return (NULL);
}
hdr->hdr_lba_start = le64toh(hdr->hdr_lba_start);
$ sudo ./bootparttest da2
GEOM provider "da2" opened
Mediasize: 1000204886016 Bytes (1953525168 sectors)
Sectorsize: 512 Bytes
da2: read 1 blocks from the offset 0 [+0]
da2: read 1 blocks from the offset 1 [+0]
ptable_open: PMBR detected
da2: read 1 blocks from the offset 1 [+0]
gpt_checkhdr: invalid entry size (128/128) or number of entries (9)
da2: read 1 blocks from the offset 1953525167 [+0]
gpt_checkhdr: invalid entry size (128/128) or number of entries (9)
Partition table detected: None
So it looks like this check is tripping because of hdr->hdr_entries (9 < 128).
If I change the minimum to 9 instead of 128, I get the following:
$ sudo ./bootparttest da2
GEOM provider "da2" opened
Mediasize: 1000204886016 Bytes (1953525168 sectors)
Sectorsize: 512 Bytes
da2: read 1 blocks from the offset 0 [+0]
da2: read 1 blocks from the offset 1 [+0]
ptable_open: PMBR detected
da2: read 1 blocks from the offset 1 [+0]
da2: read 2 blocks from the offset 2 [+0]
da2: read 1 blocks from the offset 1953525167 [+0]
ptable_gptread: new GPT partition added
Partition table detected: GPT
da2p1: FreeBSD ZFS 931G
That looks like it's reading it. So is "128 partitions is the
minimum" more of a guideline than an actual rule? Maybe "be
restrictive with what you generate but permissive in what you accept"
would apply here.
Unfortunately since I am currently resilvering one of the drives with
a fresh gpart-built table, I won't be in a position to reboot this
machine for awhile to see if a zfsloader built with this change would
boot the pool. But it seems like it might.
Thanks!
___
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 with zfsloader on 9.2-BETA2
On Wed, Aug 7, 2013 at 6:49 AM, Andrey V. Elsukov wrote: > can you please dump first 34 blocks from da2 and send to me? Will send off-list. > Also, it is interesting, what tool did you use for partitioning? Unfortunately I'm not sure. This pool may have been created on Solaris. Seems like maybe the Gnu parted folks hit this as well: http://git.savannah.gnu.org/cgit/parted.git/commit/?id=ce85c5145ed5e267e http://thread.gmane.org/gmane.comp.gnu.parted.bugs/10173 Thanks! ___ 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 with zfsloader on 9.2-BETA2
On Wed, Aug 7, 2013 at 11:59 AM, J David wrote: > On Wed, Aug 7, 2013 at 4:08 AM, Andriy Gapon wrote: >> Could you please hack gpt_checkhdr() in sys/boot/common/part.c to print all >> the >> relevant values for this check and try bootparttest again? [..] > So it looks like this check is tripping because of hdr->hdr_entries (9 < 128). I've run into this before. Our loader and kernel are excessively pedantic about this. gpart create -s gpt -n ... leads to bootblocks or loader or kernel rejecting it if it is < 128, and some of the bootblocks reject it if it is > 128. As things stand, the -n option is basically "make my system unusable". -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ZFS must be the bacon of file systems. "everything's better with ZFS" ___ 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 filing a [maybe] ZFS/mmap bug.
Andriy Gapon writes: > on 18/07/2013 20:44 George Hartzell said the following: > > Andriy Gapon writes: > > > on 17/07/2013 23:47 George Hartzell said the following: > > > > How should I move forward with this? > > > > > > Could you please try to reproduce this problem using a kernel built with > > > INVARIANTS options? > > > > I added INVARIANT_SUPPORT and INVARIANTS options to the GENERIC > > kernel, rebuilt it, installed it and running through my "test case" > > generated a lot of invalid flac files. I"m not sure what the options > > are/were supposed to do though, it looks like they generally lead to > > KASSERTS, which lead to abort()'s. Nothing in /var/log/messages or on > > the console. > > George, > > do you have anything new on this issue? Since the message that you quoted I narrowed down my "test case" somewhat but I have not yet produced a stand-alone tool that reproduces it (you still have to go through picard et al.). > Could you please try the following patch? > http://people.freebsd.org/~avg/zfs-putpages.diff > > I expect it to not really fix the issue, but it may help to narrow it down. > Please keep INVARIANTS. Absolutely. Probably not until the weekend, but I'll give it a go. Thanks for following up. g. ___ 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"
how to remove usb-storage devices without CAM errors
H i@list, i have a simple wuestion caused by a "device loss". is there a special routine for unplugging usb-storage devices? in the meaning: may be settle some commends before unplugging the device other than umount. according to the handbook there ist no special routine. unmounting should be enough and pull the USB-Devie out of the bus. i could not find anything related by the help of the big oracle. i have some usb-sticks that i need to write with prepared disk-images by using dd. two or more drives are already plugged in and da0 is already finished, da1 or da2 still at writing. unplugging da0 causes a CAM error and interrupts the ongoing write. i am not sure if all writes to each different device gets stopped. this is a reproduceable behaviour thats new to me. see the listing below. let me know if i can and what to do to help to further identify and investigate this error. iirc this happens for the first time this way. my last upgrade before this was feb./march. time of svn checkout was 2013-07-22 so its may be already fixed? many thanks in advance regards michael === ugen3.2: at usbus3 umass0: on usbus3 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:8:0:-1: Attached to scbus8 da0 at umass-sim0 bus 0 scbus8 target 0 lun 0 da0: Removable Direct Access SCSI-6 device da0: 40.000MB/s transfers da0: 7385MB (15124992 512 byte sectors: 255H 63S/T 941C) da0: quirks=0x2 ugen7.2: at usbus7 umass1: on usbus7 umass1: SCSI over Bulk-Only; quirks = 0x0100 umass1:9:1:-1: Attached to scbus9 da1 at umass-sim1 bus 1 scbus9 target 0 lun 0 da1: Removable Direct Access SCSI-6 device da1: 40.000MB/s transfers da1: 7385MB (15124992 512 byte sectors: 255H 63S/T 941C) da1: quirks=0x2 (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 02 44 80 00 00 80 00 ugen3.2: at usbus3 (disconnected) (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error umass0: (da0:at uhub3, port 3, addr 2 (disconnected) umass-sim0:0:0:0): Retrying command (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 02 44 80 00 00 80 00 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 02 44 80 00 00 80 00 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Error 5, Retries exhausted (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Error 5, Retries exhausted (da0:umass-sim0:0:0:0): got CAM status 0x44 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 5 refs (da0:umass-sim0:0:0:0): removing device entry ___ 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"
SOLVED: Re: NFS locking between 8.3-STABLE (jan 2013) and 9.2-BETA2 -- Firefox SQLite locking issue
About all you need to do is add a "V4: ..." line to your /etc/exports and then set nfsv4_server_enable="YES" in /etc/rc.conf and reboot. On the client mount, you need to add "nfsv4" as a mount option. I had to enable the proper daemons and mount on the client from the actual server mount point (previously in NFSv3 I could mount a symbolic link which pointed to the actual disk--now with NFSv4 I couldn't do that, but it's OK) but it worked! After I got my home dir to mount under NFSv4 I went into Xorg and fired up Firefox (with a brand new profile just to be on the safe side) and BOOM! Everything works that Firefox relies on SQLite for (bookmarks, and link history). Bookmark editor as well as the <- and -> arrows show up and work now as expected. I am running 8.4-STABLE as of Aug 6th on my server (it will be upgraded to 9.2-STABLE once I can find the time) and the client is 9.2-BETA2 just for the record. So it seems that 8.x and 9.x talk to each other just fine. I have not noticed anything odd performancewise--just that when I "umount" the directory it seems to "think about it" for 10-15 seconds before doing it. I don't know if that's just the "way it is" or if I can configure something more fine-tuned. However, I'm just happy--actually ecstatic--that it's working. That was my last missing link (no pun intended) to letting the "users" in the house on this new machine as their new desktop. Can't have FF broken! :) Thanks all for your responses and help. -jr ___ 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"
