Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-21:02.extattr
> On Fri, 29 Jan 2021 02:34:06 + (UTC), FreeBSD Errata Notices said: > > 2) To update your system via a source code patch: > > The following patches have been verified to apply to the applicable > FreeBSD release branches. > > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > > [FreeBSD 11.4] > # fetch https://security.FreeBSD.org/patches/EN-12:02/extattr.patch > # fetch https://security.FreeBSD.org/patches/EN-12:02/extattr.patch.asc > # gpg --verify extattr.patch.asc There is a typo in the URLs (12 instead of 21). __Martin ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: efirtc causing panic (was Re: Panic booting 12-RC2 on amd64)
Hi,
This patch resolves the panic when booting without efi.rt.disabled=1 for me.
Thanks!
Jan M.
> On 31 May 2019, at 20:35, Konstantin Belousov wrote:
>
> On Fri, May 31, 2019 at 04:19:57PM +0200, Jan Martin Mikkelsen wrote:
>> Hi,
>>
>> Christian has pointed me at this
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233534 which he raised
>> after his email. The workaround was to boot with “efi.rt.disabled=1”.
>>
>> I took a closer look at what is going on. The problem is that the EFI
>> rt_gettime call is faulting, and the fault is handled in efirt_support.S and
>> a failure is reported. These messages is in the kernel output:
>>
>> kernel trap 12 with interrupts disabled
>> kernel trap 12 with interrupts disabled
>> EFI rt_gettime call faulted, error 14
>> efirtc0: cannot read EFI realtime clock, error 14
>>
>> So far, so good. The problem is that that later in startup the
>> "smp_targeted_tlb_shootdown: interrupts disabled” panic occurs, if the SMP
>> is enabled. With SMP disabled this does not occur and the system runs.
>>
>> I’m not sure whether this is a BIOS problem (seems likely) or something that
>> could handled after dealing with the fault in efirt_support.S.
>>
>> While looking I found the code below that looks wrong in efi_enter(), but
>> that is not the problem in this case.
>>
>> Just adding this to the archive in case someone else looks more closely
>> later.
>
> Try this. Only compile-time tested.
>
> diff --git a/sys/amd64/amd64/efirt_support.S b/sys/amd64/amd64/efirt_support.S
> index cd578eddcfb..b54b13b01fe 100644
> --- a/sys/amd64/amd64/efirt_support.S
> +++ b/sys/amd64/amd64/efirt_support.S
> @@ -47,6 +47,9 @@ ENTRY(efi_rt_arch_call)
> movq%r13, EC_R13(%rdi)
> movq%r14, EC_R14(%rdi)
> movq%r15, EC_R15(%rdi)
> + pushfq
> + popq%rax
> + movq%rax, EC_RFLAGS(%rdi)
> movqPCPU(CURTHREAD), %rax
> movq%rdi, TD_MD+MD_EFIRT_TMP(%rax)
> movqPCPU(CURPCB), %rsi
> @@ -98,6 +101,8 @@ efi_rt_arch_call_tail:
> movqEC_RBP(%rdi), %rbp
> movqEC_RSP(%rdi), %rsp
> movqEC_RBX(%rdi), %rbx
> + pushq EC_RFLAGS(%rdi)
> + popfq
>
> popq%rbp
> ret
> diff --git a/sys/amd64/amd64/genassym.c b/sys/amd64/amd64/genassym.c
> index de3969734a1..2e81b823262 100644
> --- a/sys/amd64/amd64/genassym.c
> +++ b/sys/amd64/amd64/genassym.c
> @@ -272,3 +272,4 @@ ASSYM(EC_R12, offsetof(struct efirt_callinfo, ec_r12));
> ASSYM(EC_R13, offsetof(struct efirt_callinfo, ec_r13));
> ASSYM(EC_R14, offsetof(struct efirt_callinfo, ec_r14));
> ASSYM(EC_R15, offsetof(struct efirt_callinfo, ec_r15));
> +ASSYM(EC_RFLAGS, offsetof(struct efirt_callinfo, ec_rflags));
> diff --git a/sys/amd64/include/efi.h b/sys/amd64/include/efi.h
> index 082223792ac..e630a338c17 100644
> --- a/sys/amd64/include/efi.h
> +++ b/sys/amd64/include/efi.h
> @@ -72,6 +72,7 @@ struct efirt_callinfo {
> register_t ec_r13;
> register_t ec_r14;
> register_t ec_r15;
> + register_t ec_rflags;
> };
>
> #endif /* __AMD64_INCLUDE_EFI_H_ */
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
efirtc causing panic (was Re: Panic booting 12-RC2 on amd64)
Hi,
Christian has pointed me at this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233534 which he raised after
his email. The workaround was to boot with “efi.rt.disabled=1”.
I took a closer look at what is going on. The problem is that the EFI
rt_gettime call is faulting, and the fault is handled in efirt_support.S and a
failure is reported. These messages is in the kernel output:
kernel trap 12 with interrupts disabled
kernel trap 12 with interrupts disabled
EFI rt_gettime call faulted, error 14
efirtc0: cannot read EFI realtime clock, error 14
So far, so good. The problem is that that later in startup the
"smp_targeted_tlb_shootdown: interrupts disabled” panic occurs, if the SMP is
enabled. With SMP disabled this does not occur and the system runs.
I’m not sure whether this is a BIOS problem (seems likely) or something that
could handled after dealing with the fault in efirt_support.S.
While looking I found the code below that looks wrong in efi_enter(), but that
is not the problem in this case.
Just adding this to the archive in case someone else looks more closely later.
Regards,
Jan M.
--- a/src/sys/dev/efidev/efirt.c2018-11-19 15:43:47.0 1100
+++ b/src/sys/dev/efidev/efirt.c2018-11-19 15:43:47.0 1100
@@ -245,6 +245,7 @@
static int
efi_enter(void)
{
+ int error;
struct thread *td;
pmap_t curpmap;
@@ -255,7 +256,14 @@
PMAP_LOCK(curpmap);
mtx_lock(_lock);
fpu_kern_enter(td, NULL, FPU_KERN_NOCTX);
- return (efi_arch_enter());
+ error = efi_arch_enter();
+ if (error != 0) {
+ fpu_kern_leave(td, NULL);
+ mtx_unlock(_lock);
+ PMAP_UNLOCK(curpmap);
+ }
+
+ return (error);
}
static void
> On 31 May 2019, at 12:26, Jan Martin Mikkelsen
> wrote:
>
> Hi,
>
> I see exactly the same stacktrace on a Celeron J1900 based system with
> 12.0-p5 when using a UEFI boot. With a non-UEFI boot it works fine (except vt
> not working until the new 915kms.ko is loaded). With safe mode on it also
> works fine.
>
> Did you find any more information?
>
> Regards,
>
> Jan.
>
>> On 25 Nov 2018, at 19:26, Christian Ullrich wrote:
>>
>> Hello,
>>
>> I have a reproducible panic booting 12-RC2 and stable/12, 2cf4a7e0d8
>> from Friday, on a Jetway JNF9HG board, Celeron N2930 CPU, booting with
>> UEFI. The same box has no problems with stable/11 18f83cbbc9 from Thursday.
>>
>> There is no serial console on the box right now, but the last screenful
>> of boot output is this (from the -RC2; the panic'ing symbol is the same
>> with the stable/12 kernel):
>>
>> random: entropy device external interface
>> kbd1 at kbdmux0
>> netmap: loaded module
>> [ath_hal] loaded
>> module_register_init: MOD_LOAD (vesa, 0x810f8750, 0) error 19
>> random: registering fast source Intel Secure Key RNG
>> random: fast provider: "Intel Secure Key RNG"
>> nexus0
>> kernel trap 12 with interrupts disabled
>> kernel trap 12 with interrupts disabled
>> cryptosoft0: on motherboard
>> acpi0: <_> on motherboard
>> panic: smp_targeted_tlb_shootdown: interrupts disabled
>> cpuid = 2
>> time = 1
>> KDB: stack backtrace:
>> #0 0x80be74a7 at kdb_backtrace+0x67
>> #1 0x80b9b093 at vpanic+0x1a3
>> #2 0x80b9aee3 at panic+0x43
>> #3 0x811eda2f at smp_targeted_tlb_shootdown+0x40f
>> #4 0x811ed60d at smp_masked_invltlb+0x3d
>> #5 0x8105d5c5 at pmap_invalidate_range+0x1b5
>> #6 0x8106a429 at pmap_change_attr_locked+0x859
>> #7 0x81069804 at pmap_mapdev_internal+0x424
>> #8 0x81075ed0 at pcie_cfgregopen+0x60
>> #9 0x80451f10 at acpi_attach+0x390
>> #10 0x80bd6efc at device_attach+0x3ec
>> #11 0x80bd81dc at bus_generic_attach+0x5c
>> #12 0x80bd6efc at device_attach+0x3ec [sic!]
>> #13 0x80bd88b8 at bus_generic_new_pass+0x118
>> #14 0x80bda577 at root_bus_configure+0x77
>> #15 0x811dbce9 at configure+0x9
>> #16 0x80b31a78 at mi_startup+0x118
>> #17 0x8034102c at btext+0x2c
>> Uptime: 1s
>> Automatic reboot in 15 seconds - press a key on the console to abort
>>
>> If it matters, the build from svn was with CPUTYPE=slm, the -RC2 is
>> FreeBSD-12.0-RC2-amd64-mini-memstick.img, i.e. without CPUTYPE. I have
>> been running stable/11 with CPUTYPE=slm on this and other identical CPUs
>> for a long time with no trouble, so I think it is unrelated.
>>
>> I'd really like to upgrade to 12. If anyone can suggest something I can
Re: Panic booting 12-RC2 on amd64
Hi, I see exactly the same stacktrace on a Celeron J1900 based system with 12.0-p5 when using a UEFI boot. With a non-UEFI boot it works fine (except vt not working until the new 915kms.ko is loaded). With safe mode on it also works fine. Did you find any more information? Regards, Jan. > On 25 Nov 2018, at 19:26, Christian Ullrich wrote: > > Hello, > > I have a reproducible panic booting 12-RC2 and stable/12, 2cf4a7e0d8 > from Friday, on a Jetway JNF9HG board, Celeron N2930 CPU, booting with > UEFI. The same box has no problems with stable/11 18f83cbbc9 from Thursday. > > There is no serial console on the box right now, but the last screenful > of boot output is this (from the -RC2; the panic'ing symbol is the same > with the stable/12 kernel): > > random: entropy device external interface > kbd1 at kbdmux0 > netmap: loaded module > [ath_hal] loaded > module_register_init: MOD_LOAD (vesa, 0x810f8750, 0) error 19 > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > nexus0 > kernel trap 12 with interrupts disabled > kernel trap 12 with interrupts disabled > cryptosoft0: on motherboard > acpi0: <_> on motherboard > panic: smp_targeted_tlb_shootdown: interrupts disabled > cpuid = 2 > time = 1 > KDB: stack backtrace: > #0 0x80be74a7 at kdb_backtrace+0x67 > #1 0x80b9b093 at vpanic+0x1a3 > #2 0x80b9aee3 at panic+0x43 > #3 0x811eda2f at smp_targeted_tlb_shootdown+0x40f > #4 0x811ed60d at smp_masked_invltlb+0x3d > #5 0x8105d5c5 at pmap_invalidate_range+0x1b5 > #6 0x8106a429 at pmap_change_attr_locked+0x859 > #7 0x81069804 at pmap_mapdev_internal+0x424 > #8 0x81075ed0 at pcie_cfgregopen+0x60 > #9 0x80451f10 at acpi_attach+0x390 > #10 0x80bd6efc at device_attach+0x3ec > #11 0x80bd81dc at bus_generic_attach+0x5c > #12 0x80bd6efc at device_attach+0x3ec [sic!] > #13 0x80bd88b8 at bus_generic_new_pass+0x118 > #14 0x80bda577 at root_bus_configure+0x77 > #15 0x811dbce9 at configure+0x9 > #16 0x80b31a78 at mi_startup+0x118 > #17 0x8034102c at btext+0x2c > Uptime: 1s > Automatic reboot in 15 seconds - press a key on the console to abort > > If it matters, the build from svn was with CPUTYPE=slm, the -RC2 is > FreeBSD-12.0-RC2-amd64-mini-memstick.img, i.e. without CPUTYPE. I have > been running stable/11 with CPUTYPE=slm on this and other identical CPUs > for a long time with no trouble, so I think it is unrelated. > > I'd really like to upgrade to 12. If anyone can suggest something I can > try, I'll be happy to do experiments. > > -- > Christian > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Creating jails from pkgbase packages
/amd64.amd64/worldstage/runtime.ucl -p /root/pkgs/runtime.plist -r /usr/obj/usr/src/amd64.amd64/worldstage --output-dir /usr/repo/FreeBSD:12:amd64/latest and rebuilding the repo metadata with: root@betablock:~ # pkg repo /usr/repo/FreeBSD:12:amd64/latest a jail created with this Freebsd-runtime starts directly, without the steps mentioned above. My Question: Is the ommission of these files intentional? - one last experiment: i deleted the manpages, the examples, and the /boot directory (i guessed a jail has no need for it), the jail build from this file is 75M, the installation of packages like nginx works like in the original file. - should the FreeBSD-libcasper package be installed as a dependency of the FreeBSD-casper package? - i did not observe more missing libraries like libcasper above, but depending on the tasks that are executed or packages that are installed, there might be more that are missing. So that was my pkgbase-jail experiment, it was fun and i learned some things about pkgbase. Any comments, tips, tricks and (mild) critique are welcome. Greetings Martin ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Creating jails from packagebase
___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Status of libarchive/bsdtar maintainership
I have created a pull request for the proposed patch. It breaks bsdtar's test "test_missing_file" so I need to investigate. https://github.com/libarchive/libarchive/pull/1131 On 02.02.19 00:35, Warner Losh wrote: > > > On Thu, Jan 31, 2019 at 11:19 PM Eugene Grosbein <mailto:eu...@grosbein.net>> wrote: > > On 01.02.2019 11:10, Warner Losh wrote: > > > On Thu, Jan 31, 2019, 8:22 PM Eugene Grosbein > mailto:eu...@grosbein.net> > <mailto:eu...@grosbein.net <mailto:eu...@grosbein.net>> wrote: > > > > Hi! > > > > I wonder what is status of our contrib/libarchive and > bsdtar/bsdcpio etc. in modern versions of FreeBSD > > in a sense of serious bug fixing. Long story short: I faced > a bug in the libarchive bundled with 11.2 > > that makes it impossible to create reliable backups of live > file system or its subtree > > using cron+bsdtar utility that delegate actial work to the > libarchive that just aborts > > if a file disappears (is removed) in process (GNU tar > continues with just warning). > > > > This is serious issue for me as I used 'tar' command to make > backups for distinct subtrees > > since FreeBSD 6.x and when my GPS+ntpd subsystem went insane > and shifted system clock to 3 years > > in the future, I lost data in several thousands of RRD > databases and looked for backups to restore them > > and found only small portion of databases in the tar instead > of full backup. > > > > I've create the PR > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233006 and later > attached a patch > > solving the problem in same way as GNU tar deals with it. > > > > Martin Matuska (mm) asked me to create an issue at GitHub > for libarchive. > > I have no GitHub account nor I need one, and he was so kind > and created it himself: > > https://github.com/libarchive/libarchive/issues/1082 > > > > Almost 3 months have passed and no response from upstream. > > Should we go ahead and fix it despite of it is part of contrib? > > > > > > If you fix it, protocol is to submit it upstream first. > > That was done 3 months ago. > > > I see the problem report in the github, but no pull request. Did I > miss it? > > > > It causes fewer problems in the long run. While it is tempting > to just fix it in FreeBSD and move on, > > almost every time we've done that in the past someone else has > had to come in and fix the mess. > > > > Do you have a fix? Can you put it up for review somewhere? > > It is attached to mentioned PR: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233006#c6 > > > Did you submit it as a pull request? That seems to be how this > upstream takes in code. > > > We are no where near a release, so there is no reason to rush > this in. > > I waited for almost 3 months already. It seems, there would be no > response at all. > > > They didn't fix it in 3 months, sure. But it wasn't clear from the > issue that you had an actual fix (I certainly missed that the first > time through when I only looked at the github and not at our bug > database). I'd try submitting a pull request and see what happens. I'd > also send an email to mm@ telling him about the pull request and > asking when he'll have time to look into integrating it or commenting > on it. If he won't have time to get to it soon, I'd make the commit > referencing the upstream pull request so the next person who imports > things will notice if they tweak it before accepting the request. > > Warner ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Status of libarchive/bsdtar maintainership
Hi Warner and Eugene, our resources at the libarchive project are currently very limited and the progress is slow. The project founder and leader Tim Kientzle is irresponsive for more than a month now. The only active core developers are me and Joerg Sonnenberger (joerg@NetBSD). At the moment Joerg deals mostly with writing bugfixes for bugs found oss-fuzz and does some pull-request reviews. I am currently reviewing and merging bugfix and some feature pull requests from GitHub and have finally managed to set up automated testing via Cirrus CI that includes FreeBSD to speed up evaluation of new pull requests. We actually do rely on code coming from external developers. The fastest way of getting code in is submitting a pull request. If possible a testable one, including tests for the bugs fixed or features implemented. Martin On 02.02.19 00:35, Warner Losh wrote: > > > On Thu, Jan 31, 2019 at 11:19 PM Eugene Grosbein <mailto:eu...@grosbein.net>> wrote: > > On 01.02.2019 11:10, Warner Losh wrote: > > > On Thu, Jan 31, 2019, 8:22 PM Eugene Grosbein > mailto:eu...@grosbein.net> > <mailto:eu...@grosbein.net <mailto:eu...@grosbein.net>> wrote: > > > > Hi! > > > > I wonder what is status of our contrib/libarchive and > bsdtar/bsdcpio etc. in modern versions of FreeBSD > > in a sense of serious bug fixing. Long story short: I faced > a bug in the libarchive bundled with 11.2 > > that makes it impossible to create reliable backups of live > file system or its subtree > > using cron+bsdtar utility that delegate actial work to the > libarchive that just aborts > > if a file disappears (is removed) in process (GNU tar > continues with just warning). > > > > This is serious issue for me as I used 'tar' command to make > backups for distinct subtrees > > since FreeBSD 6.x and when my GPS+ntpd subsystem went insane > and shifted system clock to 3 years > > in the future, I lost data in several thousands of RRD > databases and looked for backups to restore them > > and found only small portion of databases in the tar instead > of full backup. > > > > I've create the PR > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233006 and later > attached a patch > > solving the problem in same way as GNU tar deals with it. > > > > Martin Matuska (mm) asked me to create an issue at GitHub > for libarchive. > > I have no GitHub account nor I need one, and he was so kind > and created it himself: > > https://github.com/libarchive/libarchive/issues/1082 > > > > Almost 3 months have passed and no response from upstream. > > Should we go ahead and fix it despite of it is part of contrib? > > > > > > If you fix it, protocol is to submit it upstream first. > > That was done 3 months ago. > > > I see the problem report in the github, but no pull request. Did I > miss it? > > > > It causes fewer problems in the long run. While it is tempting > to just fix it in FreeBSD and move on, > > almost every time we've done that in the past someone else has > had to come in and fix the mess. > > > > Do you have a fix? Can you put it up for review somewhere? > > It is attached to mentioned PR: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233006#c6 > > > Did you submit it as a pull request? That seems to be how this > upstream takes in code. > > > We are no where near a release, so there is no reason to rush > this in. > > I waited for almost 3 months already. It seems, there would be no > response at all. > > > They didn't fix it in 3 months, sure. But it wasn't clear from the > issue that you had an actual fix (I certainly missed that the first > time through when I only looked at the github and not at our bug > database). I'd try submitting a pull request and see what happens. I'd > also send an email to mm@ telling him about the pull request and > asking when he'll have time to look into integrating it or commenting > on it. If he won't have time to get to it soon, I'd make the commit > referencing the upstream pull request so the next person who imports > things will notice if they tweak it before accepting the request. > > Warner ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mps and LSI SAS2308: controller resets on 12.0 - IOC Fault 0x40000d04, Resetting
> On 17 Dec 2018, at 20:14, Mike Tancsa wrote: > > On 12/17/2018 10:52 AM, Mark Martinec wrote: >> Anyone else seen problems with mps driver and LSI SAS2308 controller? >> >> (btw, on another machine the mps driver with LSI SAS2004 is working >> just fine under 12.0) > > > Sort of ran into this as well, but with the mfi driver. The same card in > *some* machines would boot just fine, but in others, it would hang at > boot time. Not sure if its related or not > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231432 > > I was able to get a MegaRAID SAS-3 3108 [Invader] card working by > forcing it to use the mrsas driver instead of the mfi. However, my > 9240s fail with the mfi and they will not work with the mrsas > Interesting. I have a machine with a 9240 and a 9261 that I have just upgraded to 12.0 from 10.2 and is working fine with the mfi driver. However, the standard machine build procedure here includes: hw.mfi.msi=“1” in /boot/loader.conf. This was added to our build procedure back in 2011 to deal with the 9261 not working on FreeBSD 9.0. I wonder if using MSI interrupts would help with your problem? Regards, Jan M. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11.0 and tw_cli fail
From my experience;
I posess one 9650se card 12 ports with a computer build with freeBSD
with a custom kernel build.
i haved this particular error one day (it uses old mmap calls, which have
removed some time ago)
you can see why it fails by invoking the tw_cli after the truss(1) command
# truss tw_cli
readlink("/etc/malloc.conf",0x7fffea50,63) ERR#2 'No such file or
directory'
issetugid() = 0 (0x0)
compat6.mmap(0x0,0x1000,0x3,0x1002,0x,0x0,0x0) = 34366898176
(0x8006d4000)
break(0x78f000) = 0 (0x0)
break(0x79) = 0 (0x0)
break(0x791000) = 0 (0x0)
sysarch(AMD64_SET_FSBASE,0x7fffeb10) = 0 (0x0)
snip
the tw_cli utility worked again with COMPAT_FREEBSD6 compiled in the kernel
and the compat libraries from the same version also installed...
this two things solved this very particular problem; for me at least.
hope it helps you.
Regards.
> Message du 30/05/17 23:34
> De : "Alan Somers"
> A : "CBL"
> Copie à : "FreeBSD"
> Objet : Re: 11.0 and tw_cli fail
>
> Was the tw_cli utility built for FreeBSD 10? If so, you need to
> either rebuilt it, or build your kernel with COMPAT_FREEBSD10 in the
> config file. It's in the GENERIC config file, so you'll have it if
> you don't use a custom kernel.
> -Alan
>
> On Tue, May 30, 2017 at 3:19 PM, CBL wrote:
> > Updated a box to 11.0 with a legacy 3ware 9690SA using the twe driver.
> > Now the tw_cli utility is now throwing "Bad system call (core dumped).
> >
> > Anybody have any suggestions? Was working fine on 10.3.
> >
> > Thanks
> > ___
> > freebsd-stable@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: reset not working like 70% of the time
On 2017-01-25 12:59:27, Brandon Allbery wrote: > On Wed, Jan 25, 2017 at 4:52 AM, Eugene M. Zheganin <e...@norma.perm.ru> > wrote: > > > does anyone suffer from this too ? Right now (and for several last > > years) a 100% decent way to reset a terminal session (for instance, > > after a connection reset, after acidentally displaying a binary file > > with symbols that are treated as terminal control sequence, after > > breaking a cu session, etc) is to launch midnight commander and then > > quit from it. And the reset is working like in 30% of cases only. Unlike > > in Linux, where it's 100% functional. > > > > Using an application like that to reset the terminal is dubious at best. > You are at the mercy of how exactly it does terminal conditioning, and > nobody makes any promises about its actual behavior. In fact it could be > argued that, if it does not put the terminal back exactly the way it found > it, the application is broken. But this is actually impossible to do > correctly as the application can't know the terminal's full ANSI X3.64 > state. Additionally there's a bit of a "religious issue" around whether > full screen applications use xterm's alternate screen (and whether xterm > even has that enabled) which will save and restore more of the X3.64 state > around the application. > > "tput reset; stty sane" (or just "reset") should usually put the terminal > into a sensible state. If it doesn't, figure out whether the part that > isn't happening is a termios or a terminfo setting and focus on that part. > Check if xterm has "Enable alternate screen switching" checked on the > control-middle button menu. OP stated he's using konsole (KDE wannabe xterm). OP, try and create a minimal file with script that doesn't clean up your terminal on reset(1). Make sure it doesn't contain confidential information. Publish your environment (env | grep TERM) and this script file somewhere. Let others know the URL. Then we can actually begin to answer your original question, whether or not we see this as well. You could also try to reproduce your problems with different terminal emulators (xterm, freebsd console) Regards, -Martin ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: reset not working like 70% of the time
On 2017-01-25 11:15:17, Kurt Jaeger wrote: > Hi! > > > does anyone suffer from this too ? Right now (and for several last > > years) a 100% decent way to reset a terminal session (for instance, > > after a connection reset, after acidentally displaying a binary file > > with symbols that are treated as terminal control sequence, after > > breaking a cu session, etc) is to launch midnight commander and then > > quit from it. And the reset is working like in 30% of cases only. > [...] > > Am I the only person seeing this ? > > I had some cases in the past where xterm was hanging, too -- but > not with *that* high rate of problems. > > Most of the times, xterm's Full Reset options works fine. > > The question is: how to debug that... ? Use script(1) to record an offending session, including the reset. Then replay with script or cat or ... Regards, -Martin ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Fix ZFS bug before releasing 10.3
Hi, Could someone with enough knowledge please look into https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207714 and fix it before 10.3? It is rather nasty as it corrupts files with holes when doing 'zfs send/zfs receive'. Such files appear 'automatically' if compression is enabled and a large enough chunk of zeros exists in a file. Pointer to a possible patch is attached in the PR. -- Martin ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: file(1) command very slow
Dear Eugene, Thank you for your efforts, I have been following them in the upstream PR you filed. Regards, Martin On 09/12/15 08:18, Eugene Grosbein wrote: > 05.09.2015 15:53, Martin Birgmeier пишет: >> Running the file(1) command on a 7 MB text file takes much longer in >> 10.2 than in 10.1. >> >> Example: >> >> # ll /tmp/x6 >> -rw-r--r-- 1 root wheel 7384414 Sep 5 10:30 /tmp/x6 >> # file /tmp/x6 >> /tmp/x6: ASCII text >> file /tmp/x6 26.12s user 0.00s system 99% cpu 26.237 total >> # >> >> I have this on all my machines since installing 10.2. > > The problem is now fixed upstream libmagic code repository > but we'll have to wait for file-5.25 release. > > I've extracted official code fix from its repository, apply as following: > > fetch http://www.grosbein.net/file/patch-regexmax.diff > cd /usr/src > patch < /path/to/patch-regexmax.diff > cd lib/libmagic > make obj depend && make all install > > > > > > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
file(1) command very slow
Running the file(1) command on a 7 MB text file takes much longer in 10.2 than in 10.1. Example: # ll /tmp/x6 -rw-r--r-- 1 root wheel 7384414 Sep 5 10:30 /tmp/x6 # file /tmp/x6 /tmp/x6: ASCII text file /tmp/x6 26.12s user 0.00s system 99% cpu 26.237 total # I have this on all my machines since installing 10.2. Any ideas on what is wrong? -- Martin ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Release schedule
Dear community, I have a question regarding the scheduling of releases. All of my production machines are currently running releng/10.1. This release has at least two severe (for me) problems: - An external USB 3.0 HD enclosure never negotiates successfully for USB 3.0 when connected. This worked better in 9.2 (PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196332) - A serious kernel memory allocation issue involving VirtualBox which did not exist in 9.2 (PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195970) At least the first one might already be corrected in stable/10, but, the release engineering page https://www.freebsd.org/releng/index.html tells me that 10.2 is planned only for November 2015 (and 11.0 for July 2016). So my question is, would it be possible to have a somewhat less drawn-out release schedule? Maybe at fixed times twice during the year, so that a certain rhythm will evolve? Regards, Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD LVS replacement
Hi Maciej, you may also want to take a look at the OpenBSD relayd port (net/relayd). Cheers, mm On 2013-07-22 21:13, Maciej Jan Broniarz wrote: Hello, I'm looking for a functional FreeBSD replacement of the Linux LVS software? There is an LVS port for FreeBSD but it looks deat since 2005. Is there anything comparable or better? All best, mjb ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE
On 13.12.2012 18:54, Andriy Gapon wrote: on 13/12/2012 19:46 olivier said the following: Thanks. I'll be sure to follow your suggestions next time this happens. I have a naive question/suggestion though. I see from browsing past discussions on ZFS problems that it has been suggested a number of times that problems that appear to originate in ZFS in fact come from lower layers; in particular because of driver bugs or disks in the process of failing. It seems that it can take a lot of time to troubleshoot such problems. I accept that ZFS behavior correctly leaves dealing with timeouts to lower layers, but it seems to me that the ZFS layer would be a great place to warn the user about issues and provide some information to troubleshoot them. For example, if some I/O requests get lost because of a buggy driver, the driver itself might not be the best place to identify those lost requests. But perhaps we could have a compile time option in ZFS code that spits out a warning if it gets stuck waiting for a particular request to come back for more than say 10 seconds, and identifies the problematic disk? I'm sure there would be cases where these warnings would be unwarranted, and I imagine that changes in the code to provide such warnings would impact performance; so one certainly would not want that code active by default. But someone in my position could certainly recompile the kernel with a ZFS debugging option turned on to figure out the problem. I understand that ZFS code comes from upstream, and that you guys probably want to keep FreeBSD-specific changes minimal. If that's a big problem, even just a patch provided as such that does not make it into the FreeBSD code base might be extremely useful. I wish I could help write something like that, but I know very little about the kernel or ZFS. I would certainly be willing to help with testing. Google for zfs deadman. This is already committed upstream and I think that it is imported into FreeBSD, but I am not sure... Maybe it's imported just into the vendor area and is not merged yet. So, when enabled this logic would panic a system as a way of letting know that something is wrong. You can read in the links why panic was selected for this job. And speaking FreeBSD-centric - I think that our CAM layer would be a perfect place to detect such issues in non-ZFS-specific way. I can try to merge the ZFS deadman stuff (r242732) to HEAD, but I guess this will be something for a 1-month MFC period. Afterwards, a 9-STABLE patch can be easily created. https://www.illumos.org/issues/3246 https://hg.openindiana.org/upstream/illumos/illumos-gate/rev/921a8bb4 Cheers, mm -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ 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: Thinkpad X61s cannot boot 9.1-BETA1
On Sun, 26 Aug 2012, Per olof Ljungmark wrote: On 08/26/12 18:37, Kurt Jaeger wrote: Hi! On our X61s's setting 'debug.acpi.disabled=hostres' does not change the inability to boot 9-BETA1, 9-RC1 or -current. I tested 9.1-RC1 on X61, and it worked without any troubles. Yes, it does on this one too if I install a mechanical disk. The problem is related to installing on a SSD drive, Kingston SSDNow SV200S37A/128G. This must be related to a change in the base system some time between 9.0-RELEASE and -BETA1 as 9.0 runs and installs fine. Perhaps someone could suggest anther SSD drive with equal capacity that works? debug.acpi.disabled=hostres fixed it for me on T61 and T410 with normal HD and (older) SSD (OCZ Summit) FreeBSD 9.1-PRERELEASE #16: Tue Aug 21 m. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Thinkpad X61s cannot boot 9.1-BETA1
On Tue, 31 Jul 2012, John Baldwin wrote: On Friday, July 20, 2012 10:11:33 am jb wrote: Did anyone else experience this? With 9.1-BETA1 the boot process freezes, among the last lines with verbose boot are acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times after this, dead. ... set debug.acpi.disabled=hostres boot Or, put the following line into /boot/loader.conf: debug.acpi.disabled=hostres ... Anyway, regardless of this attempt, file a PR# for 9.1-BETA1. Please try this and let me know if it works. The bugs that I knew of related to hostres should be fixed in 9.1, so if there are still problems I'd like to know about it. this seems to work on a T410, at least it can boot the latest USB-image now. T61 has the same problem, btw. m. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD ?
Am Sat, 09 Jun 2012 21:09:09 +0700 schrieb Adam Strohl adams-free...@ateamsystems.com: I get the feeling people are updating their ports tree and then recompiling/reinstalling everything just because and then are complaining when one thing breaks (its the only thing I can think of). Hi. But it does not need to break. Sometimes it would be enough just to test if the port compiles before committing it (I'm talking about libreoffice here which is broken). Some people rely on some essential ports. I can understand that porters are not Gods and make errors, but they should be fixed within hours, when they have been found on important ports. I mean, ports collection is sure great and this is one of the aspects why I am using FreeBSD, but at the moment FreeBSD is losing strength here, in my opinion. Martin signature.asc Description: PGP signature
Re: Why Are You NOT Using FreeBSD ?
Am Sun, 10 Jun 2012 11:37:09 +0100 schrieb Chris Rees cr...@freebsd.org: Er... people always test their commits. Sometimes edge cases will creep in, such as the libreoffice failure which was due to different configurations, but to suggest that the commit wasn't tested is quite frankly insulting-- it built on a clean system perfectly well. Hi, I don't mean to insult anyone. As I have already told, I am really thankful that people invest their precious time into updating the ports collection. Whatever clean system means. It is surely not the default case that someone has got a freshly installed set of ports. Among all the default problems with ports, libreoffice[1] adds to the group of annoyances[2] at the moment. I don't know when I have seen portmaster -ad run through successfully last time. I need more and more -x options to exclude ports which fail to build. [1] german/libreoffice and libreoffice fails all the time in (LOCALIZED_LANG is set to de): Module 'lingucomponent' delivered successfully. 12 files copied, 2 files unchanged --- Oh dear - something failed during the build - sorry ! For more help with debugging build errors, please see the section in: http://wiki.documentfoundation.org/Development internal build errors: ERROR: error 65280 occurred while making /usr/workdir-ports/usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/vcl/prj it seems that the error is inside 'vcl', please re-run build inside this module to isolate the error and/or test your fix: --- Whatever this tries to tell me. I don't get it. This is a completely useless error message for me. [2] The default annoyances are for example: - After updating perl, php or whatever, it makes sense to enforce updating the modules that belong to these ports. I've seen 100x the same message that p5-XML-Parser does not work and know what it means, but this should be resolved by the port system. I mean, when you update perl, the perl modules won't work anymore. This is totally clear and it makes sense to update them first before going on. - When specifying WITHOUT_X11 the ports should respect this and not try to pull in the X11 variants of ports. I regularly see some ports pulling ImageMagick instead of the already installed ImageMagick-nox11. I still do not fully understand what is going on with WITHOUT_GNOME, but I'll try to figure it out later. But I am quite sure that some ports pull in unneeded Gnome dependencies. - Ports are being marked as interactive and stop the update process. The idea behind portmaster was (earlier) to avoid interactive building of ports and ask all the needed questions, before the builds start. I mean, earlier, I could get out and enjoy some coffee outdoors, now I have to sit at the keyboard. This is unacceptable! ;) - It would be nice to have a mechanism that tells you that your perl, mysql or whatever is not the default version anymore and you should consider updating to the default (and recommended) port. Martin signature.asc Description: PGP signature
Re: ULE Scheduler
Am Fri, 8 Jun 2012 08:04:12 +0200 schrieb Andreas Nilsson andrn...@gmail.com: My t61p also had overheating problems with fbsd, but never in linux. For me the fan control was somewhat broken: I had to turn off auto-mode and set max myself to get any heavy usage out of it. You might want to check that as well. Regards Andreas I checked this and my fan was already at full speed (all the time). Linux has got voltage regulation in fglrx as far as I know. As soon as the GPU was using power saving functions on MS-Windows the GPU temperature was far below 50°C. With FreeBSD it was always at 70°C! I don't have the T60p anymore (thanks god). It was an awful laptop. So I cannot give more precise information about this anymore. Martin signature.asc Description: PGP signature
Re: ULE Scheduler
Am Thu, 07 Jun 2012 03:01:07 +0200 schrieb Момчил Иванов momc...@xaxo.eu: Is there some remedy? Hi, I remember this series, I've had a T60p and when I compiled world, I placed a fan in front of it to cool it down from 100°C. The difference with T60p was that it simply shut off reaching 101°C. The problem is the hardware, not FreeBSD. T60p and obviously T60, too, was made by some crazy people who had the idea to cool the CPU und the GPU under the same heat sink. The funny thing is that the GPU is running at 70°C all the time, because FreeBSD does not implement voltage regulation for the VGA chipset. The result is that the GPU warms up the CPU to at least 55°C while idle. If you want to have a cooler CPU implement power saving for the Radeon chipset there. Martin signature.asc Description: PGP signature
Re: /usr/bin/unzip not being installed on 8.3-STABLE
Hi, Yes I can do that. +-oOO--(_)--OOo-+ With best Regards, Martin Wilke (miwi_(at)_FreeBSD.org) Mess with the Best, Die like the Rest On May 29, 2012, at 12:36 PM, Doug Barton do...@freebsd.org wrote: This needs more than diff-posting, it needs actual testing. By humans, and an -exp run. Since miwi is on the cc list, perhaps he can arrange it? Doug On 5/28/2012 10:59 AM, Jason Hellenthal wrote: Here is the unzip diff from stable/8 - head On Mon, May 28, 2012 at 07:20:03PM +0200, Dag-Erling Smørgrav wrote: Jason Hellenthal jhellent...@dataix.net writes: Could someone MFC this to stable/8 please... Is unzip in stable/8 identical to unzip in head and stable/9? If not, this should be addressed first. Otherwise, there is a good chance that many ports will fail to build. -- This .signature sanitized for your protection ___ 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: DKIM FreeBSD 9.0
Am Thu, 26 Apr 2012 08:05:06 - schrieb Prabhpal S. Mavi prabh...@digital-infotech.net: Gmail servers says: smtp.mail=m...@digital-infotech.net; dkim=neutral (bad format) header.i=@digital-infotech.net Yahoo Servers Says: Authentication-Results: mta1273.mail.mud.yahoo.com from=digital-infotech.net; domainkeys=neutral (no sig); from=digital-infotech.net dkim=permerror (future timestamp) i tried to google to know the cause, but unable to figure out, is this my configuration problem or the public key is not correct that have copied in to DNS. ( imean the format). any idea please? format of created DKIM in DNS: v=DKIM1; g=*; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC678E6Ssjhf7Lw0By0BkjapnD4 1gG0zaB6NSNxUoXu0jblYqd+ZQEOxut9v/IvQXISVZnHFdX2Ilw8eTPS57lG4E/x FUx2bhYwp8wLQ1vK8rgrwl9im2lp3ELiwEfYXDy1BXxDRFY8x85xr5Zqxwkwm0i6 7/99HWWtcQTkV3VztwIDAQAB Hi Prabhpal, can you please take a look at your signature header. My email client shows that your emails has been signed 2 times (there are 2 headers called DKIM-Signature:). This can be a problem. Test it by sending an email to yourself. Also... you should know about the problems around DKIM. Many servers append illegal headers and possibly modify email contents (like this mailing list here; it appends a signature and destroys the verification phase). Sometimes you need to take action manually and filter out headers from free mail providers etc. When you save an email, this command will verify the signature manually: /usr/local/sbin/opendkim -t email-file.eml I cannot really tell what's going on and this can take very long to figure this out. You should move the discussion to the official forums as a more appropriate place for these kinds of discussions. -- Martin signature.asc Description: PGP signature
Re: DKIM FreeBSD 9.0
Am Wed, 25 Apr 2012 12:12:27 - schrieb Prabhpal S. Mavi prabh...@digital-infotech.net: Dear Friends, is anyone is able to setup DKIM with FreeBSD 9.0 and Postfix? thanks / Prabhpal Hi Prabhal, I would ask this in official forums, if I were you. I use opendkim as milter at port 8891 and have this line in main.cf: smtpd_milters = inet:localhost:8891 /etc/rc.conf: milteropendkim_enable=YES milteropendkim_uid=dkim milteropendkim_cfgfile=/usr/local/etc/mail/opendkim.conf You need to setup opendkim.conf properly and, of course, you need a DNS TXT entry with your key. You can find some howtos online about how to configure everything step-by-step. I hope this helps. -- Martin signature.asc Description: PGP signature
Re: DKIM FreeBSD 9.0
Am Wed, 25 Apr 2012 19:48:37 - schrieb Prabhpal S. Mavi prabh...@digital-infotech.net: Dear Martin, Thank you very much for you response. I will cross check everything as you explained and update you tomorrow morning. Do have any document or link for FreeBSD 9.0? Hello Prabhal, you can use the official docs [1]. There is nothing specific as long as you know some basics about FreeBSD (services setup etc). [1] http://www.opendkim.org/docs.html (especially opendkim filter README File) -- Regards, Martin signature.asc Description: PGP signature
Re: problems with AHCI on FreeBSD 8.2
Am Tue, 14 Feb 2012 18:17:19 +0100 schrieb Harald Schmalzbauer h.schmalzba...@omnilan.de: I find it interesting that, at least so far, the only people reporting problems of this type with the ahci.ko driver are people using Samsung disks. The only difference is that your models are F1s while the OPs are F2s. I saw such timeouts long ago and mav@ had a look at my postings and he mentioned it could be a NCQ problem. I suspected the disks firmware. I never tracked it down further, because after replacing the Samsung (F3 in that case) disks with hitachi ones solved all my problems and gave a big performance kick as well (with zfs). You can find the discussion here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055374.html Hi, I just want to add here that I am using 2 drives of type Samsung HD103SJ (SpinPoint F3). And I did not have problems with ZFS and with UFS either (for several years now). Everything has been deployed ontop ada(4) since FreeBSD-8. Actually the speed is very good (sequential read at 140 MB/s and more). -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: problems with AHCI on FreeBSD 8.2
Am Tue, 14 Feb 2012 20:24:32 +0100 schrieb Harald Schmalzbauer h.schmalzba...@omnilan.de: I guess it's always the firmware of the EcoGreen models which cause these problems. Your drive isn't EG... I don't remember exactly the different model numbers, but I'm sure they were all EcoGreen. The lower power consumption was the reason to choose these specific drives (different capacities and F2/F3 series tried), with acceptable performance loss - I thought. But it turned out that EcoGreen and NCQ as well as RAIDZ demands dont' fit together... Hi, I intentionally did not buy any Eco or Green model because I don't like them (Load_Cycle_Count bugs and so on). I realized, I like to use 1 Watt more power but have the performance doubled. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Timekeeping in stable/9
Am Wed, 18 Jan 2012 07:50:49 +0100 schrieb Martin Sugioarto mar...@sugioarto.com: I can confirm this on VirtualBox. I've been running WinXP inside VirtualBox and measured network I/O during downloads. It showed me very high download rates (around 800kB/s) while it's physically possible to download 200kB/s through DSL here (Germany sucks with DSL, even in largest cities, btw!). I correlated this behavior with high disk I/O on the host. That means that the timer issues on the virtual host appear when I start a larger cp job on the host. I also immediately thought that this has something to do with timers. Hi everybody, I just want to add some information on this. I tested a few things with VirtualBox yesterday. I switched off ntpd on the host and tested if there are differences, but the clock is working correctly on the host. I tested it a few times, it is stable, as I expect it to be. It seems to be rather a software problem with VirtualBox. I can see that when the host is under heavy load (CPU!) the guest does not get enough runtime to adjust the clock correctly. After a few minutes there has been a difference of 50 seconds between the host and guest clock. And furthermore, I don't quite understand how the real time clock works in VirtualBox but it seems to slide in the different directions causing weird results with progress bars on MS-Windows XP. I just want to explain why I thought that I/O influences this. I have got my hard disk encrypted, so it puts some load on the CPU, too. If you want to test VirtualBox behavior, you can simple dd from /dev/random and look at the weird results in VirtualBox. -- I hope it helps further, Martin signature.asc Description: PGP signature
Re: Timekeeping in stable/9
Am Sat, 21 Jan 2012 13:20:51 +0100 schrieb Ronald Klop ronald-freeb...@klop.yi.org: Hi, As I understand it. Host: FreeBSD 9 Guest: WinXP Which one has troubles with its clock? The host or the guest or both? Hi, only inside VirtualBox, I think it's only an application problem and my emails would be probably better addressed to ports@. ONLY the guest is affected when host is loaded. I noticed additionally: You get better results with a desync'ed clock in the guest system, when you start openssl speed -multi 20 or similar. Within a few seconds the clock gets a 20 seconds difference. How many CPU's did you assign to the guest? Did you install virtualbox guest additions to the guest? Here a few details (guest additions are installed): Memory size: 1600MB Page Fusion: off VRAM size: 256MB HPET:on/off (tried both settings) Chipset: piix3 Firmware:BIOS Number of CPUs: 1 Synthetic Cpu: off CPUID overrides: None [...] ACPI:on IOAPIC: off PAE: on Time offset: 0 ms RTC: local time Hardw. virt.ext: on Hardw. virt.ext exclusive: on Nested Paging: on Large Pages: on VT-x VPID: on [...] 3D Acceleration: off 2D Video Acceleration: on Do you run NTP on the guest XP also? If yes, turn it off. Windows XP default installation (synch'ed to time.windows.com). Switching this off, does not have any influence. I think MS-Windows does not do continuous synchronization, only at system start, I guess. VBox guest additions can sync the guest clock with the host. I'll try to deinstall them. But I somehow like my shared folder. BTW: My experience with VBox is that it is nice for hobby stuff, but not for heavy load server stuff. VMWare does a better job there. Yes. I know. Still VirtualBox ist nice and cheap solution. -- Martin signature.asc Description: PGP signature
Re: Timekeeping in stable/9
Am Sat, 21 Jan 2012 14:30:53 +0200 schrieb Alexander Motin m...@freebsd.org: Hi Alexander, I am not using VirtualBox right now, so I'll need to setup it to test this. Meanwhile you could try to experiment with switching to different timecounters and eventtimers. May be some change in 9.0 changed default timecounter for you, causing the problem. I think we have a misunderstanding here. The host (FreeBSD 9.0R) works fine. The time is being updated under heavy load without problems. I already said that this seems to be an application problem and this email(s) should be rather seen by the VBox maintainer. The problem is that VBox seems to stop working properly when you put heavy CPU load on the host. It even does not keep the clock up-to-date. I can desync the guest clock to -1 minute in a few seconds, just by running openssl speed -multi 20. timecounter wrap should be the main cause of time drift (if timecounter hardware is emulated correctly at all). Different timecounters have different wrap periods that can be calculated by dividing kern.timecounter.tc.X.mask on kern.timecounter.tc.X.frequency. In my case there are: 300s for HPET, 5s for ACPI-fast, 2s for TSC and 55ms for i8254. If system won't get timer interrupts within half of that time -- time will drift. Start from looking what you are using and how good it is in your case. This is my current timecounter setting: kern.timecounter.choice: TSC-low(1000) HPET(950) i8254(0) ACPI-fast(900) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 10400371 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 41849 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3255982446 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 1587561917 kern.timecounter.tc.TSC-low.frequency: 8593928 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 I can try other timer counter settings, if you think it will improve responsivity inside VBox guest. -- Martin signature.asc Description: PGP signature
Re: Timekeeping in stable/9
Am Tue, 17 Jan 2012 20:12:51 + schrieb Joe Holden li...@rewt.org.uk: Hi guys, Has anyone else noticed the tendency for 9.0-R to be unable to accurately keep time? I've got a couple of machines that have been upgraded from 8.2 that are struggling, in particular a Virtual box guest that was fine on 8.2, but now that's its been upgraded to 9.0 counts at anything from 2 to 20 seconds per 5 second sample, the result is similar with HPET, ACPI-fast and TSC. Hi Joe, I can confirm this on VirtualBox. I've been running WinXP inside VirtualBox and measured network I/O during downloads. It showed me very high download rates (around 800kB/s) while it's physically possible to download 200kB/s through DSL here (Germany sucks with DSL, even in largest cities, btw!). I correlated this behavior with high disk I/O on the host. That means that the timer issues on the virtual host appear when I start a larger cp job on the host. I also immediately thought that this has something to do with timers. You can perhaps try yourself and confirm, if it's the disk I/O that influences timers. I somehow don't like the hard disk behavior. It makes desktop unusable in some situations (mouse pointer skipping, applications lock for several seconds). I also have physical boxes which new seem to drift quite substantially, ntpd cannot keep up and as these boxes need to be able to report the time relatively accurately, it is causing problems with log times and such... Not sure about physical boxes. I have not taken a look at this, yet. -- Martin signature.asc Description: PGP signature
Re: [releng_8 tinderbox] failure on i386/i386
On 5.1.2012 21:51, John Baldwin wrote: On Thursday, January 05, 2012 3:25:42 pm John Baldwin wrote: On Thursday, January 05, 2012 1:02:05 pm David Wolfskill wrote: On Thu, Jan 05, 2012 at 01:28:25PM +, FreeBSD Tinderbox wrote: ... cc -O2 -pipe - I/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzpool/common - I/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/include - I/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/lib/libumem - I/src/cddl/sbin/zpool/../../../sys/cddl/compat/opensolaris - I/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/head - I/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libuutil/common - I/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libumem/common - I/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzfs/common - I/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libnvpair - I/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/common/zfs - I/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common - I/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys - I/src/cddl/sbin/zpool/../../../cddl/contrib/o! pensolaris/lib/libzpool/common - I/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/stat/common - DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wno-unknown-pragmas -o zpool zpool_main.o zpool_vdev.o zpool_iter.o zpool_util.o zfs_comutil.o timestamp.o -lavl -lbsdxml -lgeom -lm -lnvpair -lsbuf -lumem -lutil -luutil - lzfs zpool_main.o(.text+0x34fd): In function `zpool_do_labelclear': : undefined reference to `zpool_pool_state_to_name' *** Error code 1 ... Attached patch gets around the above for me. Looks like revision 224169 needs to be merged to 8 (it includes the changes in your patch along with some others): http://svnweb.freebsd.org/base?view=revisionrevision=224169 I'm testing this now and if it fixes the build I'll commit. My amd64 buildworld finished with this applied, so I've committed it. Thank you very much. -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ 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: Mystery panic, FreeBSD 7.2-PRE
Thanks, jeremy! On 12/22/2011 05:07 PM, Jeremy Chadwick wrote: On Thu, Dec 22, 2011 at 04:04:48PM -0700, Charlie Martin wrote: We've got another mystery panic in 7.2-PRE. Upgrading is not an option; however, if this is familiar to anyone, backporting a patch would be. The stack trace is: db_trace_self_wrapper() at 0x8019120a = db_trace_self_wrapper+0x2a^M panic() at 0x80308797 = panic+0x187^M devfs_populate_loop() at 0x802a45c8 = devfs_populate_loop+0x548^M devfs_populate() at 0x802a46ab = devfs_populate+0x3b^M devfs_lookup() at 0x802a7824 = devfs_lookup+0x264^M VOP_LOO[24165][irq261: plx0] DEBUG (hasc_sv_rcv_cb): rcvd hrtbt ts 24051, 7/9, rc 0^M KUP_APV() at 0x804d5995 = VOP_LOOKUP_APV+0x95^M lookup() at 0x80384a3e = lookup+0x4ce^M namei() at 0x80385768 = namei+0x2c8^M vn_open_cred() at 0x8039b283 = vn_open_cred+0x1b3^M kern_open() at 0x8039a4a0 = kern_open+0x110^M syscall() at 0x804b0e3c = syscall+0x1ec^M Xfast_syscall() at 0x80494ecb = Xfast_syscall+0xab^M --- syscall (5, FreeBSD ELF64, open), rip = 0x800e022fc, rsp = 0x7fbfa128, rbp = 0x801002240 ---^M KDB: enter: panic^M devfs(5) has been massively worked on in RELENG_8 and newer. You should go through the below commits and see if you can find one that references a PR with a similar backtrace, or mentions things like devfs_lookup(). http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/devfs/ Also, be aware that the above stack trace is interspersed. Ultimately you get to clean up the output yourself. This is a long-standing problem with FreeBSD which can be helped but only slightly/barely by using options PRINTF_BUFR_SIZE=256 in your kernel configuration (the default configs have a value of 128. Do not increase the value too high, there are concerns about it causing major issues; I can dig up the post that says that, but I'd rather not). It *will not* solve the problem of interspersed output entirely. There still is no fix for this problem... :-( What I'm referring to: devfs_lookup() at 0x802a7824 = devfs_lookup+0x264^M VOP_LOO[24165][irq261: plx0] DEBUG (hasc_sv_rcv_cb): rcvd hrtbt ts 24051, 7/9, rc 0^M lookup() at 0x80384a3e = lookup+0x4ce^M This should actually read (I think): devfs_lookup() at 0x802a7824 = devfs_lookup+0x264^M VOP_LOOKUP_APV() at 0x804d5995 = VOP_LOOKUP_APV+0x95^M [24165][irq261: plx0] DEBUG (hasc_sv_rcv_cb): rcvd hrtbt ts 24051, 7/9, rc 0^M -- Charles R. (Charlie) Martin Senior Software Engineer SGI logo 1900 Pike Road Longmont, CO 80501 Phone: 303-532-0209 E-Mail: crmar...@sgi.com mailto:crmar...@sgi.com Website: www.sgi.com http://www.sgi.com ___ 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
PRINTF_BUFR_SIZE=4096?
In the course of looking at Jeremy's reponse to my query about a mystery panic, I noted his recommendation that PRINTF_BUFR_SIZE be set to 256. Ever-obedient, I went to set the value, and discovered instead that the conf file already has it set to 4096. As he says below, there are concerns about setting the value too high causing major issues. I being Christmas and all I hate to ask Jeremy to dig up the post he mentioned, but wonder if anyone can clue me in on what the major issues might be? Thanks, and regards Charlie Martin On 12/22/2011 05:07 PM, Jeremy Chadwick wrote: Also, be aware that the above stack trace is interspersed. Ultimately you get to clean up the output yourself. This is a long-standing problem with FreeBSD which can be helped but only slightly/barely by using options PRINTF_BUFR_SIZE=256 in your kernel configuration (the default configs have a value of 128. Do not increase the value too high, there are concerns about it causing major issues; I can dig up the post that says that, but I'd rather not). -- Charles R. (Charlie) Martin Senior Software Engineer SGI logo 1900 Pike Road Longmont, CO 80501 Phone: 303-532-0209 E-Mail: crmar...@sgi.com mailto:crmar...@sgi.com Website: www.sgi.com http://www.sgi.com ___ 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: PRINTF_BUFR_SIZE=4096?
Thanks, Jeremy, I really was trying to keep you from needing to dig this out. This is inherited code with some very peculiar intermittent panics, so you can imagine that I would be interested in specifics of the odd behavior. Sadly, I don't think we're seeing any stack overflows. On 12/23/2011 03:54 PM, Jeremy Chadwick wrote: On Fri, Dec 23, 2011 at 03:21:06PM -0700, Charlie Martin wrote: When I was doing FreeBSD stuff as part of the Project, I added this to my Commonly Reported Issues wiki page since it comes up quite often. Search for BUFR. http://wiki.freebsd.org/BugBusting/Commonly_reported_issues I will note that all the Commonly reported page says is set the value to 256 and point to three examples of people seeing garbled output. -- Charles R. (Charlie) Martin Senior Software Engineer SGI logo 1900 Pike Road Longmont, CO 80501 Phone: 303-532-0209 E-Mail: crmar...@sgi.com mailto:crmar...@sgi.com Website: www.sgi.com http://www.sgi.com ___ 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
Mystery panic, FreeBSD 7.2-PRE
We've got another mystery panic in 7.2-PRE. Upgrading is not an option; however, if this is familiar to anyone, backporting a patch would be. The stack trace is: db_trace_self_wrapper() at 0x8019120a = db_trace_self_wrapper+0x2a^M panic() at 0x80308797 = panic+0x187^M devfs_populate_loop() at 0x802a45c8 = devfs_populate_loop+0x548^M devfs_populate() at 0x802a46ab = devfs_populate+0x3b^M devfs_lookup() at 0x802a7824 = devfs_lookup+0x264^M VOP_LOO[24165][irq261: plx0] DEBUG (hasc_sv_rcv_cb): rcvd hrtbt ts 24051, 7/9, rc 0^M KUP_APV() at 0x804d5995 = VOP_LOOKUP_APV+0x95^M lookup() at 0x80384a3e = lookup+0x4ce^M namei() at 0x80385768 = namei+0x2c8^M vn_open_cred() at 0x8039b283 = vn_open_cred+0x1b3^M kern_open() at 0x8039a4a0 = kern_open+0x110^M syscall() at 0x804b0e3c = syscall+0x1ec^M Xfast_syscall() at 0x80494ecb = Xfast_syscall+0xab^M --- syscall (5, FreeBSD ELF64, open), rip = 0x800e022fc, rsp = 0x7fbfa128, rbp = 0x801002240 ---^M KDB: enter: panic^M -- Charles R. (Charlie) Martin Senior Software Engineer SGI logo 1900 Pike Road Longmont, CO 80501 Phone: 303-532-0209 E-Mail: crmar...@sgi.com mailto:crmar...@sgi.com Website: www.sgi.com http://www.sgi.com ___ 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: [9.0-RC3] tar xf with zip archive is broken
On 20.12.2011 16:41, Patrick Lamaiziere wrote: Hello, Looks like tar -xf with zip archive is broken on 9.0. It creates the directories but files are empty. See with nagios-checker firefox plugin (.xpi which is a zip file) http://code.google.com/p/nagioschecker/downloads/detail?name=nagioschecker-0.16.xpican=2q= total 20 drwxr-xr-x 4 patrick patrick 6 20 déc 16:35 ./ drwxr-xr-x 43 patrick patrick 89 20 déc 16:34 ../ drwxr-xr-x 3 patrick patrick 3 20 déc 16:35 chrome/ -rwxr-xr-x 1 patrick patrick 0 15 déc 2010 chrome.manifest* drwxr-xr-x 3 patrick patrick 3 20 déc 16:35 defaults/ -rwxr-xr-x 1 patrick patrick 0 31 déc 2010 install.rdf* On 8.2 that works fine. Regards. ___ 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 This is a libarchive bug. Fixed in upstream r3723: http://code.google.com/p/libarchive/source/detail?r=3723 I am preparing a libarchive update to 2.8.5 + recent SVN bugfixes. This won't make it to 9.0, though. -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ 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
Spinlock panic in FreeBSD 7
(This was originally posted to freebsd-hackers, I'm reposting following email suggestions.) We've observed a panic in FreeBSD 7 (7.2-PRERELEASE FreeBSD) several times that we've not been able to track down. Upgrading is not an option at this time. Does this look at all familiar to anyone? Here's an example stack trace after panic: spin lock 0x8086bdc0 (smp rendezvous) held by 0xff0006d1f000 (tid 100060) too long panic: spin lock held too long cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0x8019120a = db_trace_self_wrapper+0x2a panic() at 0x80308797 = panic+0x187 _mtx_lock_spin_failed() at 0x802fbda9 = _mtx_lock_spin_failed+0x39 _mtx_lock_spin() at 0x802fbe4e = _mtx_lock_spin+0x9e _mtx_lock_spin_flags() at 0x802fc354 = _mtx_lock_spin_flags+0x104 smp_rendezvous_cpus() at 0x80340cb3 = smp_rendezvous_cpus+0xd3 xcall() at 0x80ad755e = xcall+0x3e cyclic_remove_here() at 0x80ad7715 = cyclic_remove_here+0x1a5 cyclic_remove() at 0x80ad7a0f = cyclic_remove+0x5f profile_disable() at 0x80acf0e5 = profile_disable+0x15 dtrace_state_destroy() at 0x80adfabd = dtrace_state_destroy+0x35d dtrace_close() at 0x80adffed = dtrace_close+0x8d devfs_close() at 0x802a825d = devfs_close+0x2dd vn_close() at 0x8039cb06 = vn_close+0xb6 vn_closefile() at 0x8039cc00 = vn_closefile+0x80 devfs_close_f() at 0x802a5738 = devfs_close_f+0x28 fdrop() at 0x802d98bb = fdrop+0xdb closef() at 0x802db2f9 = closef+0x29 fdfree() at 0x802dc061 = fdfree+0x161 exit1() at 0x802e56b2 = exit1+0x2c2 sigexit() at 0x8030a86f = sigexit+0x8f postsig() at 0x8030b6ce = postsig+0x38e ast() at 0x803425f7 = ast+0x337 Xfast_syscall() at 0x80494efd = Xfast_syscall+0xdd --- syscall (32, FreeBSD ELF64, getsockname), rip = 0x800df4d5c, rsp = 0x7fffe398, rbp = 0x5 --- KDB: enter: panic The panic always shows up from a syscall, and almost always from syscall 32, getsockname, but we've also observed it with syscall 5. -- Charles R. (Charlie) Martin Senior Software Engineer SGI logo 1900 Pike Road Longmont, CO 80501 Phone: 303-532-0209 E-Mail: crmar...@sgi.com mailto:crmar...@sgi.com Website: www.sgi.com http://www.sgi.com ___ 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: svn commit: r226946 - stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On 30. 10. 2011 22:34, Jason Hellenthal wrote: On Sun, Oct 30, 2011 at 09:03:12PM +, Martin Matuska wrote: Author: mm Date: Sun Oct 30 21:03:12 2011 New Revision: 226946 URL: http://svn.freebsd.org/changeset/base/226946 Modified: stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c == --- stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c Sun Oct 30 21:02:01 2011(r226945) +++ stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c Sun Oct 30 21:03:12 2011(r226946) @@ -21,6 +21,9 @@ /* * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. */ +/* + * Copyright 2011 Nexenta Systems, Inc. All rights reserved. + */ With (c) being a literal copyright symbol it seems to be missing above. Hi Jason, this is a 1:1 upstream merge: http://hg.openindiana.org/upstream/illumos/illumos-gate/file/205481e35e49/usr/src/uts/common/fs/zfs/dmu_tx.c If you don't like it you can try to contact Illumos and/or Nexenta ;-) -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ 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
9.0 B1 Panic
9.0 Beta1 Panic Hi guys, I just downloaded and install 9.0 BETA1 but it panics on ACPI. Please view attached screenshot for the error. If you need more information, do let us know. 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: 9.0 B1 Panic
On Aug 2, 2011, at 6:58 PM, Lystopad Olexandr wrote: Hello, Martin Wilke! On Tue, Aug 02, 2011 at 12:41:29PM +0800 m...@freebsd.org wrote about 9.0 B1 Panic: 9.0 Beta1 Panic Hi guys, I just downloaded and install 9.0 BETA1 but it panics on ACPI. Please view attached screenshot for the error. If you need more information, do let us know. There no attachments in your mail. Erms Sorry forgot about that. http://people.freebsd.org/~miwi/90b1.png -- Lystopad Olexandr ___ 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: 9.0 B1 Panic
On Aug 3, 2011, at 12:56 AM, John Baldwin wrote: On Tuesday, August 02, 2011 8:58:10 am Martin Wilke wrote: On Aug 2, 2011, at 6:58 PM, Lystopad Olexandr wrote: Hello, Martin Wilke! On Tue, Aug 02, 2011 at 12:41:29PM +0800 m...@freebsd.org wrote about 9.0 B1 Panic: 9.0 Beta1 Panic Hi guys, I just downloaded and install 9.0 BETA1 but it panics on ACPI. Please view attached screenshot for the error. If you need more information, do let us know. There no attachments in your mail. Erms Sorry forgot about that. http://people.freebsd.org/~miwi/90b1.png Can you get a stack trace? Hi, unfortunately no, because the system freeze few sec after the panic. - Martin -- 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: ZFS v28 and aclmode
Dňa 22. 7. 2011 9:48, Eugene Mitrofanov wrote / napísal(a): Hi all, I just updated to 8.2S and zfs v28 and notice strange thing: in the manual i can read about aclmode but i can not use it in the real life: # zfs set aclmode=passthrough data/public cannot set property for 'data/public': invalid property 'aclmode' Obsolete manual? Good luck I imported reintroduction of aclmode from Illumos to 9-CURRENT in revsion 224174 MFC to 8-STABLE will be around Aug 1, 2011. More information: https://www.illumos.org/issues/742 http://svnweb.freebsd.org/base?view=revisionrevision=224174 -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ 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
HEADS UP: ZFS v28 merged to 8-STABLE
Hi, I have merged ZFS version 28 to 8-STABLE (revision 222741) New major features: - data deduplication - triple parity RAIDZ (RAIDZ3) - zfs diff - zpool split - snapshot holds - zpool import -F. Allows to rewind corrupted pool to earlier transaction group - possibility to import pool in read-only mode For updating, there is a compatibility layer so that in the update phase most functionality of the new zfs binaries can be used with the old kernel module and old zfs binaries with the new kernel module. If upgrading your boot pool to version 28, please don't forget to read UPDATING and properly update your boot code. Thanks to everyone working on the ZFS port, especially to Pawel Jakub Dawidek (pjd) for doing most of the work! -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ 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 8.2 Release, ZFS + Samba, running out of memory
There looks like a known bug of not activating memory pages if using sendfile(2). This was fixed by kib@ in revision 218795 of stable/8. Please try the following patch and report the result: http://people.freebsd.org/~mm/patches/releng_8_2/218795.zfs.patch Dňa 22.02.2011 22:55, Henner Heck wrote / napísal(a): Hello, i experience freezing of my FreeBSD machine when performing certain operations on a Samba share. Technical info: - FreeBSD 8.2 Release 64 Bit (it also happened with 8.2 RC3) - Samba 3.5.6.1 - Athlon II Quadcore, 4 GB Ram - 1 SSD with a ZFS pool (No.0) containing the FreeBSD system - 12x2TB RaidZ2 pool (No.1) for data, created on 12 GEOM eli encrypted partitions on 12 disks, shared to a Windows 7 PC with Samba, 8 of the disks are attached to 2 Marvell SATA controllers, 4 to the onboard controller - ZPool v15, ZFS v4 Scenarios (checked using top): A: When copying files from one directory in pool 1 to another, the free memory drops from about 3700M to abaout 200M in the process, but seems to stabilize then. B: When copying the files onto a Windows machine using the Samba share, the free memory seems to stabilize at about 100M. C: When computing a hashvalue of files from the share on Windows or doing a binary compare to copies of the files stored on the Windows PC (using Total Commander), the free memory on the FreeBSD machine drops even lower and shortly after the BSD system freezes. ___ 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 8.1 re0 shows half duplex
Howdy Guys, I have a strange problem, I'm on FreeBSD 8.1 and ifconfig re0 shows half-duplex (see output) and the download speed is damn slow, maximum 20 kbps. I'm not sure how to debug this so it would be nice if someone can help me to fix it. When i change it manually via command line, the media line appeared to have 2 entries -- full-duplex and half-duplex re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=389bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC ether 6c:62:6d:90:6e:63 inet XX netmask 0xffc0 broadcast XX media: Ethernet 100baseTX full-duplex (100baseTX half-duplex) status: active main# uname -a FreeBSD 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Fri Jan 14 04:15:56 UTC 2011 root@freebsd:/usr/obj/usr/src/sys/GENERIC amd64 main# # dmesg re0: RealTek 8168/8111 B/C/CP/D/DP/E PCIe Gigabit Ethernet port 0xe800-0xe8ff mem 0xfbeff000-0xfbef,0xf6ff-0xf6ff irq 16 at device 0.0 on pci6 re0: Using 1 MSI messages re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: MII bus on re0 re0: Ethernet address: 6c:62:6d:90:6e:63 re0: [FILTER] re0: link state changed to UP main# # pciconf -lv re0@pci0:6:0:0: class=0x02 card=0x75221462 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet # dmideco http://nopaste.unixfreunde.de/46256 ___ 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: Next ZFSv28 patchset ready for testing.
To use with newer stable (or releng/8.2) use a more recent patch from: http://people.freebsd.org/~mm/patches/zfs/v28/ Cheers, mm Dňa 14.01.2011 18:19, Christopher J. Ruwe wrote / napísal(a): Hi, I would like to test Martin Matuskas patch for ZFS v28 against stable. Can I patch against any stable (like stable of today) or does it necessarily need to be the stable-tree of the date specified in the patch-file? If the latter should be true, how do I obtain a stable tree of any given date? Thanks for any help, kind regards, ___ 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: New ZFSv28 patchset for 8-STABLE: Kernel Panic
Please don't consider these patches as production-ready. What we want to do is find and resolve as many bugs as possible. To help us fix these bugs, a way to reproduce the bug from a clean start (e.g. in virtualbox) would be great and speed up finding the cause for the problem. Your problem looks like some sort of deadlock. In your case, when you experiene the hang, try running procstat -k -k PID in another shell (console). That will give us valuable information. Cheers, mm Dňa 28.12.2010 18:39, Jean-Yves Avenard wrote / napísal(a): On 29 December 2010 03:15, Jean-Yves Avenard jyaven...@gmail.com wrote: # zpool import load: 0.00 cmd: zpool 405 [spa_namespace_lock] 15.11r 0.00u 0.03s 0% 2556k load: 0.00 cmd: zpool 405 [spa_namespace_lock] 15.94r 0.00u 0.03s 0% 2556k load: 0.00 cmd: zpool 405 [spa_namespace_lock] 16.57r 0.00u 0.03s 0% 2556k load: 0.00 cmd: zpool 405 [spa_namespace_lock] 16.95r 0.00u 0.03s 0% 2556k load: 0.00 cmd: zpool 405 [spa_namespace_lock] 32.19r 0.00u 0.03s 0% 2556k load: 0.00 cmd: zpool 405 [spa_namespace_lock] 32.72r 0.00u 0.03s 0% 2556k load: 0.00 cmd: zpool 405 [spa_namespace_lock] 40.13r 0.00u 0.03s 0% 2556k ah ah ! it's not the separate log that make zpool crash, it's the cache ! Having the cache in prevent from importing the pool again rebooting: same deal... can't access the pool any longer ! Hopefully this is enough hint for someone to track done the bug ... More details as I was crazy enough to try various things. The problem of zpool being stuck in spa_namespace_lock, only occurs if you are using both the cache and the log at the same time. Use one or the other : then there's no issue But the instant you add both log and cache to the pool, it becomes unusable. Now, I haven't tried using cache and log from a different disk. The motherboard on the server has 8 SATA ports, and I have no free port to add another disk. So my only option to have both a log and cache device in my zfs pool, is to use two slices on the same disk. Hope this helps.. Jean-Yves ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Updated py-zfs ? Re: New ZFSv28 patchset for 8-STABLE
I have updated the py-zfs port right now so it should work with v28, too. The problem was a non-existing solaris.misc module, I had to patch and remove references to this module. Cheers, mm Dňa 23.12.2010 09:27, Ruben van Staveren wrote / napísal(a): Hi, On 16 Dec 2010, at 13:44, Martin Matuska wrote: Hi everyone, following the announcement of Pawel Jakub Dawidek (p...@freebsd.org) I am providing a ZFSv28 testing patch for 8-STABLE. Where can I find an updated py-zfs so that zfs (un)allow/userspace/groupspace can be tested ? Regards, Ruben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ 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
New ZFSv28 patchset for 8-STABLE
Hi everyone, following the announcement of Pawel Jakub Dawidek (p...@freebsd.org) I am providing a ZFSv28 testing patch for 8-STABLE. Link to the patch: http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101215.patch.xz Link to mfsBSD ISO files for testing (i386 and amd64): http://mfsbsd.vx.sk/iso/zfs-v28/8.2-beta-zfsv28-amd64.iso http://mfsbsd.vx.sk/iso/zfs-v28/8.2-beta-zfsv28-i386.iso The root password for the ISO files: mfsroot The ISO files work on real systems and in virtualbox. They conatin a full install of FreeBSD 8.2-PRERELEASE with ZFS v28, simply use the provided zfsinstall script. The patch is against FreeBSD 8-STABLE as of 2010-12-15. When applying the patch be sure to use correct options for patch(1) and make sure the file sys/cddl/compat/opensolaris/sys/sysmacros.h gets deleted: # cd /usr/src # fetch http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101215.patch.xz # xz -d stable-8-zfsv28-20101215.patch.xz # patch -E -p0 stable-8-zfsv28-20101215.patch # rm sys/cddl/compat/opensolaris/sys/sysmacros.h From Pawel's announcement: Some of the changes since the last patchset (zfs_20100831.patch): - Boot support for ZFS v28 (only RAIDZ3 is not yet supported). - Various fixes for the existing ZFS boot code. - Support for sendfile(2) (by avg@). - Userland-kernel compatibility with v13-v15 (by mm@). - ACL fixes (by trasz@). - Various bug fixes. Please test, test, test. Chances are this is the last patchset before v28 going to HEAD (finally) and after a reasonable testing period into 8-STABLE. Especially test new changes, like boot support and sendfile(2) support. Also be sure to verify if you can import for existing ZFS pools (v13-v15) when running v28 or boot from your existing pools. Please test the (v13-v15) compatibility layer as well: Old usereland + new kernel / old kernel + new userland More information about ZFS on my blog: http://blog.vx.sk ___ 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: 8.1-STABLE: problem with unmounting ZFS snapshots
No, this is not good for us. Solaris does not allow mounting of snapshots on any vnode, like we do. Solaris has them only in .zfs/snapshots. This allows us to have read-only mounts without even mounting the parent zfs. Before v15 we have been happy with that code and had no issues :-) I have a very simple testcase where just fixing the VFS_RELE breaks our forced unmount. Let's say we use the correct VFS_RELE in zfs_vfsops.c: VFS_RELE(vfsp-mnt_vnodecovered-v_vfsp); Now let's say you have a mounted filesystem (e.g. md) under /mnt: /dev/md5 on /mnt (ufs, local) # mkdir /mnt/test # mount -t zfs t...@t2 /mnt/test # umount -f /mnt Now you will hang because the second VFS_HOLD. So I stick to my opinion that this extra protection is more a problem than a solution in our case and it should be commented out. Dňa 13.11.2010 11:27, Andriy Gapon wrote / napísal(a): on 13/11/2010 04:27 Martin Matuska said the following: Yes, this is indeed a leak introduced by importing onnv revision 9214 and it exists in perforce as well - very easy to reproduce. # mount -t zfs t...@t1 /mnt # umount /mnt (- hang) http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6604992 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6810367 This is not compatible with mounting snapshots outside mounted ZFS and I was not able to reproduce the errors defined in 6604992 and 6810367 (they are Solaris-specific). I suggest we comment out this code (from head, later MFC and p4 as well). Patch (should work with HEAD and 8-STABLE): http://people.freebsd.org/~mm/patches/zfs/zfs_vfsops.c.patch Not quite sure, but perhaps it's better to make the logic in each place match the other. That is, I see that the code does hold on a filesystem of a covered vnode, but does rele on a parent ZFS filesystem. Or is this kind of protection not needed at all for 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: 8.1-STABLE: problem with unmounting ZFS snapshots
Yes, this is indeed a leak introduced by importing onnv revision 9214 and it exists in perforce as well - very easy to reproduce. # mount -t zfs t...@t1 /mnt # umount /mnt (- hang) http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6604992 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6810367 This is not compatible with mounting snapshots outside mounted ZFS and I was not able to reproduce the errors defined in 6604992 and 6810367 (they are Solaris-specific). I suggest we comment out this code (from head, later MFC and p4 as well). Patch (should work with HEAD and 8-STABLE): http://people.freebsd.org/~mm/patches/zfs/zfs_vfsops.c.patch Dňa 12.11.2010 15:27, Andriy Gapon wrote / napísal(a): on 12/11/2010 16:00 Alexander Zagrebin said the following: Thanks for your reply! 2. the umount is waiting for disk #ps | egrep 'PID|umount' PID TT STAT TIME COMMAND 958 0 D+ 0:00,04 umount /mnt # procstat -t 958 PIDTID COMM TDNAME CPU PRI STATE WCHAN 958 100731 umount - 3 133 sleep mntref procstat -kk pid $ ps a | grep umount 86874 2- D 0:00,06 umount /mnt 90433 3 S+ 0:00,01 grep umount $ sudo procstat -kk 86874 PIDTID COMM TDNAME KSTACK 86874 100731 umount -mi_switch+0x176 sleepq_wait+0x42 _sleep+0x317 vfs_mount_destroy+0x5a dounmount+0x4d4 unmount+0x38b syscall+0x1cf Xfast_syscall+0xe2 Looks like possible mnt_ref leak. I think that something like that was fixed some not long time ago. Perhaps you either don't have the fix or there is another leak. What revision do you have? Perhaps Martin has an insight here. ___ 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
Cyrus saslauthd: Problems with plugins
Hello
My system:
FreeBSD acsvfbsd04.tld.ch 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Thu Oct
7 18:45:49 CEST 2010
mar...@acsvfbsd04.tld.ch:/usr/obj/usr/src/sys/GENERIC i386
Since I updated from FreeBSD 7.2 to 8.1 there seems to be a problem
with the Kerberos5 (Heimdal 1.1) which is in the base system . There
are some threads around this problem in
http://docs.freebsd.org/mail/archive/2010/freebsd-stable/20100725.freebsd-stable.html
and
http://docs.freebsd.org/mail/archive/2010/freebsd-stable/20100718.freebsd-stable.html.
Until now there were no realy workaround which works on my systems.
Any way... Under this circumstance I checked saslauthd with truss and
there I saw:
stat(/usr/lib/plugin/krb5,0xbfbfbf30) ERR#2 'No such file
or directory'
But I have no ideas what in this directory should be? Because it does
not exist. Should there be the SASL plugins? After some study around I
set a symlink to
lrwxr-xr-x 1 root wheel20B 7 Okt 11:58 krb5 -
/usr/local/lib/sasl2 (which helds all the SASL plugins)
but with no realy success. Since I'm not a programmer I can not
interpret the output of truss. With the above symlink I get results
like this:
[snip]
...
stat(/usr/lib/plugin/krb5,{ mode=drwxr-xr-x
,inode=1578253,size=1024,blksize=16384 }) = 0 (0x0)
open(/usr/lib/plugin/krb5,O_NONBLOCK,05001342626) = 10 (0xa)
fstat(10,{ mode=drwxr-xr-x ,inode=1578253,size=1024,blksize=16384 }) = 0 (0x0)
fcntl(10,F_SETFD,FD_CLOEXEC) = 0 (0x0)
__sysctl(0xbfbfbc68,0x2,0x284f5860,0xbfbfbc70,0x0,0x0) = 0 (0x0)
fstatfs(0xa,0xbfbfbd40,0x1,0xbfbfbcb4,0x280963a0,0xa) = 0 (0x0)
getdirentries(0xa,0x28612000,0x1000,0x28602114,0x44f59c4e,0x28097800)
= 1024 (0x400)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVT
open(/usr/lib/plugin/krb5/.,O_RDONLY,027757736550) = 11 (0xb)
fstat(11,{ mode=drwxr-xr-x ,inode=1578253,size=1024,blksize=16384 }) = 0 (0x0)
pread(0xb,0x28086d80,0x1000,0x0,0x0,0x3) = 1024 (0x400)
close(11)= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVT
open(/usr/lib/plugin/krb5/..,O_RDONLY,027757737434) = 11 (0xb)
fstat(11,{ mode=drwxr-xr-x ,inode=1530887,size=15872,blksize=16384 }) = 0 (0x0)
pread(0xb,0x28086d80,0x1000,0x0,0x0,0x0) = 4096 (0x1000)
close(11)= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVT
open(/usr/lib/plugin/krb5/libsasldb.so.2,O_RDONLY,027757737434) = 11 (0xb)
...
[snip]
It seems that saslauthd reads all files in this directory. But is this
correct, resp. what do saslauthd expect there? What do I wrong? Any
help is welcome.
Regards,
--
Martin Schweizer
off...@pc-service.ch
PC-Service M. Schweizer GmbH; Bannholzstrasse 6; CH-8608 Bubikon
Tel. +41 55 243 30 00; Fax: +41 55 243 33 22
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: zfs send/receive: is this slow?
Try using zfs receive with the -v flag (gives you some stats at the end): # zfs send storage/bac...@transfer | zfs receive -v storage/compressed/bacula And use the following sysctl (you may set that in /boot/loader.conf, too): # sysctl vfs.zfs.txg.write_limit_override=805306368 I have good results with the 768MB writelimit on systems with at least 8GB RAM. With 4GB ram, you might want to try to set the TXG write limit to a lower threshold (e.g. 256MB): # sysctl vfs.zfs.txg.write_limit_override=268435456 You can experiment with that setting to get the best results on your system. A value of 0 means using calculated default (which is very high). During the operation you can observe what your disks actually do: a) via ZFS pool I/O statistics: # zpool iostat -v 1 b) via GEOM: # gstat -a mm Dňa 4. 10. 2010 4:06, Artem Belevich wrote / napísal(a): On Sun, Oct 3, 2010 at 6:11 PM, Dan Langille d...@langille.org wrote: I'm rerunning my test after I had a drive go offline[1]. But I'm not getting anything like the previous test: time zfs send storage/bac...@transfer | mbuffer | zfs receive storage/compressed/bacula-buffer $ zpool iostat 10 10 capacity operationsbandwidth pool used avail read write read write -- - - - - - - storage 6.83T 5.86T 8 31 1.00M 2.11M storage 6.83T 5.86T207481 25.7M 17.8M It may be worth checking individual disk activity using gstat -f 'da.$' Some time back I had one drive that was noticeably slower than the rest of the drives in RAID-Z2 vdev and was holding everything back. SMART looked OK, there were no obvious errors and yet performance was much worse than what I'd expect. gstat clearly showed that one drive was almost constantly busy with much lower number of reads and writes per second than its peers. Perhaps previously fast transfer rates were due to caching effects. I.e. if all metadata already made it into ARC, subsequent zfs send commands would avoid a lot of random seeks and would show much better throughput. --Artem ___ 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
Broken SASL/Kerberos authentication: openldap client GSSAPI authentication segfaults on FreeBSD 8.1 Release too
Hello I use the system as a mail server (Cyrus Impad) which I authenticate against Kerberos5 (Windows Active Directory) with Cyrus SASL (saslauthd -a kerberos5). Here are the details: cyrus-imapd-2.3.16_2 The cyrus mail server, supporting POP3 and IMAP4 protocols cyrus-sasl-2.1.23 RFC SASL (Simple Authentication and Security Layer) cyrus-sasl-saslauthd-2.1.23 SASL authentication server for cyrus-sasl2 My system: FreeBSD acsvfbsd04.acutronic.ch 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Thu Sep 30 12:33:18 CEST 2010 mar...@acsvfbsd04.acutronic.ch:/usr/obj/usr/src/sys/GENERIC i386 After I upgaded from 7.2 to 8.1 the SASL authentication (with Kerberos5) is broken. See http://docs.freebsd.org/cgi/getmsg.cgi?fetch=301304+0+archive/2010/freebsd-stable/20100718.freebsd-stable and the following threads. See alo PR 147454. I did what you suggested in different threads around july regarding the subject: 1. cvsup a fresh copy of RELEASE 8.1 in /usr/src 2. Now I apply the patch in /usr/src with patch -p1 -E patch name 3. Now I make buildworld make buidlkernel make installkernel and I get the following messages: cc -fpic -DPIC -O2 -pipe -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/krb5 -I/usr/src/kerb cc -fpic -DPIC -O2 -pipe -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/krb5 -I/usr/src/kerb cc -fpic -DPIC -O2 -pipe -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/krb5 -I/usr/src/kerb cc -fpic -DPIC -O2 -pipe -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/krb5 -I/usr/src/kerb cc -fpic -DPIC -O2 -pipe -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/krb5 -I/usr/src/kerb cc -fpic -DPIC -O2 -pipe -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/krb5 -I/usr/src/kerb cc -fpic -DPIC -O2 -pipe -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/krb5 -I/usr/src/kerb cc -fpic -DPIC -O2 -pipe -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/krb5 -I/usr/src/kerb cc -fpic -DPIC -O2 -pipe -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/krb5 -I/usr/src/kerb acc -fpic -DPIC -O2 -pipe -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/krb5 -I/usr/src/ker cc -fpic -DPIC -O2 -pipe -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/krb5 -I/usr/src/kerb make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libpthread.a. Stop *** Error code 2 Stop in /usr/src. What I'm doing wrong? Kind regards, -- Martin Schweizer off...@pc-service.ch PC-Service M. Schweizer GmbH; Bannholzstrasse 6; CH-8608 Bubikon Tel. +41 55 243 30 00; Fax: +41 55 243 33 22 ___ 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: Broken SASL/Kerberos authentication: openldap client GSSAPI authentication segfaults on FreeBSD 8.1 Release too
Hello Jeremy Am Sat, Oct 02, 2010 at 07:11:46AM -0700 Jeremy Chadwick schrieb: On Sat, Oct 02, 2010 at 03:11:07PM +0200, Martin Schweizer wrote: [...] 3. Now I make buildworld make buidlkernel make installkernel and I get the following messages: [...] cc -fpic -DPIC -O2 -pipe -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi/krb5 -I/usr/src/kerb make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libpthread.a. Stop *** Error code 2 Stop in /usr/src. What I'm doing wrong? Did you specify any -j flags during your make buildworld (ex. make -j2 buildworld)? If so, please remove them and restart the build. Then you will see where the actual compile/make error happens. From the above output, it doesn't look like it's related to the Kerberos or libgssapi stuff. No, I did not use any flags when I did start make buildworld. Regards, -- Martin Schweizer off...@pc-service.ch PC-Service M. Schweizer GmbH; Bannholzstrasse 6; CH-8608 Bubikon Tel. +41 55 243 30 00; Fax: +41 55 243 33 22 ___ 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: MFC of ZFSv15
Dont forget to read the general ZFS notes section in UPDATING: ZFS notes - When upgrading the boot ZFS pool to a new version, always follow these two steps: 1.) recompile and reinstall the ZFS boot loader and boot block (this is part of make buildworld and make installworld) 2.) update the ZFS boot block on your boot drive The following example updates the ZFS boot block on the first partition (freebsd-boot) of a GPT partitioned drive ad0: gpart bootcode -p /boot/gptzfsboot -i 1 ad0 Non-boot pools do not need these updates. Dňa 16. 9. 2010 17:43, Mike Tancsa wrote / napísal(a): At 11:18 AM 9/16/2010, jhell wrote: On 09/16/2010 09:55, Mike Tancsa wrote: Thanks again for all the ZFS fixes and enhancements! Are there any caveats to upgrading ? Do I just do zpool upgrade -a zfs upgrade -a or are there any extra steps ? Hi Mike, No-one knows your bootcode better than you. So if you are upgrading don't forget if you are on a ZFS root then your bootcode might need updating. Hi, I am booting off UFS right now so no bootcode updates for me :) I did look at UPDATING which does mention 20100915: A new version of ZFS (version 15) has been merged. This version uses a python library for the following subcommands: zfs allow, zfs unallow, zfs groupspace, zfs userspace. For full functionality of these commands the following port must be installed: sysutils/py-zfs ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MFC of ZFSv15
I have fixed the missing bits in r212688. Thanks for the notice. Dňa 15. 9. 2010 21:12, Xin LI wrote / napísal(a): On 2010/09/15 11:30, Mike Tancsa wrote: At 02:07 PM 9/15/2010, Pascal Stumpf wrote: First of all, a great thanks to mm@ and pjd@ for the excellent work on ZFS in FreeBSD. :) And especially for the MFC of v15 a few hours ago. [...] here too. RELENG_8 AMD64. The tinderboxes havent hit that branch yet (http://tinderbox.freebsd.org/http://tinderbox.freebsd.org/), so it will be a few hrs before they get to test RELENG_8 [...] -lsbuf -lm -lnvpair -luutil -lutil /usr/obj/usr/src/tmp/usr/lib/libzfs.so: undefined reference to `getmntent' *** Error code 1 Sorry for that, it seems to be caused by a partial merge (cddl/compat/opensolaris/misc/mnttab.c). mm@ is going to fix that ASAP. Cheers, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: zpool - low speed write
Try booting with the following on /boot/loader.conf: vfs.zfs.vdev.max_pending=10 vfs.zfs.txg.write_limit_override=268435456 And remove setting: vfs.zfs.cache_flush_disable=1 Then try a dd from /dev/zero. Cheers, mm Dňa 4. 8. 2010 16:13, Alex V. Petrov wrote / napísal(a): interesting results: From single-UDF-disk to pool: $ dd if=petrovs-disk1.iso of=/tank/petrovs-disk1.iso bs=1M 3545+1 records in 3545+1 records out 3718002688 bytes transferred in 438.770195 secs (8473690 bytes/sec) From single-UDF-disk to null: $ dd if=petrovs-disk1.iso of=/dev/null bs=1M 3545+1 records in 3545+1 records out 3718002688 bytes transferred in 83.304575 secs (44631435 bytes/sec) -- Alex V. Petrov ___ 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
ath(4) hostap with fake MAC/BSSID results in station dropping packets when associated
Hi, I noticed a bug that was introduced somewhere in the Atheros 9280 support in 8.1-RELEASE when used as a station. I had this already running correctly with 7.x releases. What happens: I cannot connect to a hostap ath(4) (Atheros 2413) when using a fake MAC/BSSID (on the hostap!). How to reproduce it: 1) Put this into your rc.local on your hostap machine and replace xx's by an address of your choice (first octet needs to have lowest bit 0): ifconfig ath0 ether xx:xx:xx:xx:xx:xx 2) Start hostapd (must be configured, of course). Eventually you need to set BSSID also in hostapd.conf. 3) Try to connect with an Atheros 9280. You don't need to fake MAC address here (I'm only talking about the hostap MAC/BSSID). What you get: - You get association. This is OK, so far. - Try DHCP. You won't see packets arriving at the station. They are not recognized and filtered somewhere. - When you watch with tcpdump on the hostap interface you'll see DHCP requests arriving and being answered. - I further noticed, even you don't have any IP (set to 0.0.0.0, because of failed DHCP), you can see packets being sent to different machines - You can try to setup a static address, but when you ping the station, you don't see a ping arriving (watch tcpdump on the station wireless interface and try to ping from the hostap machine). Further information: - This only affects ath(4) and I could only see this on Atheros 9280, because I don't have any other ath(4) adapters at the moment. - I tried rum(4). It does not have any problems like this. DHCP and everything else works with this driver (of course with a fake MAC/BSSID!). - Running 8.1-RELEASE on all machines. Kernel is GENERIC, but on hostap machine there is ALTQ added (should not affect anything, as I said, I had this running already). - hostapd is configured with 11g, WPA2 and passwords in hostapd.wpapsk. WME is switched off, because it does not work at all for me. I can provide more information, if needed. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Sat, 13 Feb 2010 15:27:04 -0600 Robert Noland rnol...@freebsd.org wrote: On Sat, 2010-02-13 at 11:37 -0800, Norbert Papke wrote: On February 13, 2010, Robert Noland wrote: Ok, I've put up a patch at: http://people.freebsd.org/~rnoland/drm-radeon-test.patch http://people.freebsd.org/~rnoland/drm-radeon-8-test.patch This one should work on 8... robert. This is sort of a mega patch and includes: Re-worked drm mapping code, that ensures that we don't end up incorrectly mapping certain maps with overlapping offsets. This generally shows up as the ring buffer not being cleared (contents != 0 in xorg.log) which leads to corruption and other bad behavior. Re-written scatter gather allocation code. This interacts directly with the VM system, rather than using bus_dma to allow us to grab non-contiguous pages for the scatter gather backing of the GART. It also makes it easier to handle the caching mode of the backing pages. Disable cache snooping on radeon cards, since we have write combining set properly now. I have at least done a test build on -CURRENT with this patch, but I haven't had time to do much else without the rest of the code in my tree. I've been running most all of this code for a month or two now at least, so it is mostly just a question of whether or not I got all of the conflicts sorted out properly when I made this patch. The re-mapping code has the most widespread impact and has been tested on radeon r600 amd64, intel g45 i386 and mga amd64. robert. The patch applied cleanly. I have applied the patch to a clean 8-STABLE environment with WITNESS, INVARIANTS and KDB_UNATTENDED in the kernel. I still see the crashes when starting X with DRI on. This is what I see in messages: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7b000 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7c000 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7d000 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7e000 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset 070001c7f000 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_ioctl] pid=30467, cmd=0xc0286415, nr=0x15, dev 0xff0001a79400, auth=1 Feb 14 19:13:44 alpha kernel: Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] offset = 0xfe8e, size = 0x0001, type = 1 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] Found kernel map 1 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] Added map 1 0xfe8e/0x1 Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_ioctl] pid=30467, cmd=0x80106459, nr=0x59, dev 0xff0001a79400, auth=1 There has been one odd development. If I startx with DRI off or NoAccel set it starts as usual. If I then quit and to cli and restart, I see the same crash as if I had DRI on. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 16:01:58 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Just checked... This card should work with Accel and DRI... At least on -CURRENT with updated ports. Check UPDATING, and set WITHOUT_NOUVEAU to get correct version of libdrm. robert. I am on -STABLE built on Jan. 19. I updated mesa today (to libdrm-2.4.17), and rebuilt xorg-server and drivers. I have WITHOUT_NOUVEAU=YES in /etc/make.conf. pkg_info reports libGL-7.6.1. Is that 8-STABLE or 7? 8 should work, and I think 7 should as well, but just checking. 6 won't work. I am on 8-STABLE. I have tried loading radeon.ko manually before startx. What are the results? If things are not working, I'll want to see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X started if you can get it. robert. I have attached the output from pciconf -lvb, sysctl -a |grep ^hw.dri reports: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: hw.dri.0.clients: hw.dri.0.vblank: hw.dri.0.debug: 0 I loaded radeon.ko from within my X session, which was started with DRI OFF. If I run startx with DRI True or without an xorg.conf, the screen goes into standby as if the pc is turned off, the mouse and keyboard stops responding to keypresses (ie. numlock-led will not respond to me pressing the key.) and I cannot ssh into the machine. As far as I can tell it has crashed. There is nothing in /var/log/messages, which gives any indication that something went wrong (If I boot the machine - startx and force a reboot I get 2 x dmesg plus fsck messages). Xorg.0.log contains only messages from the last successful start of xorg, and is a far as I can tell useless in tracking this down. If it will help, I can switch to -CURRENT to see if that changes anything. Martin PS. Robert, in researching this I got some idea of the effort you put into this, thanks! Martin -- Martin Kristensen pciconf.out Description: Binary data ___ 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: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Thu, 11 Feb 2010 06:16:12 -0600 Robert Noland rnol...@freebsd.org wrote: On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 16:01:58 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Just checked... This card should work with Accel and DRI... At least on -CURRENT with updated ports. Check UPDATING, and set WITHOUT_NOUVEAU to get correct version of libdrm. robert. I am on -STABLE built on Jan. 19. I updated mesa today (to libdrm-2.4.17), and rebuilt xorg-server and drivers. I have WITHOUT_NOUVEAU=YES in /etc/make.conf. pkg_info reports libGL-7.6.1. Is that 8-STABLE or 7? 8 should work, and I think 7 should as well, but just checking. 6 won't work. I am on 8-STABLE. I have tried loading radeon.ko manually before startx. What are the results? If things are not working, I'll want to see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X started if you can get it. robert. I have attached the output from pciconf -lvb, sysctl -a |grep ^hw.dri reports: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: hw.dri.0.clients: hw.dri.0.vblank: hw.dri.0.debug: 0 I loaded radeon.ko from within my X session, which was started with DRI OFF. Ok, if X doesn't try to open drm, then nothing will show up as being mapped. If you do a sysctl hw.dri it will show the mappings, but the above grep is cutting out most of the useful info. Sorry, I did not understand what you wanted, here is sysctl hw.dri: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: slot offset size type flags addressmtrr 0 0xfe8e 0x0001 REG 0x82 0xff00fe8e no hw.dri.0.clients: a devpid uid magic ioctls hw.dri.0.vblank: crtc ref countlast enabled inmodeset 00 00 00 00 01 00 00 00 hw.dri.0.debug: 0 If I run startx with DRI True or without an xorg.conf, the screen goes into standby as if the pc is turned off, the mouse and keyboard stops responding to keypresses (ie. numlock-led will not respond to me pressing the key.) and I cannot ssh into the machine. As far as I can tell it has crashed. There is nothing in /var/log/messages, which gives any indication that something went wrong (If I boot the machine - startx and force a reboot I get 2 x dmesg plus fsck messages). Xorg.0.log contains only messages from the last successful start of xorg, and is a far as I can tell useless in tracking this down. This sounds suspiciously like a WITNESS issue... I wonder if I have accidentally MFC'd something that isn't safe. You don't get a core dump eventually do you? robert. I have left it for at least the time it takes to boot my laptop and try to ssh into the machine (5 min.). I have dumpdev defined. I will crash it and leave it for 15 min. to see if something happens. If it will help, I can switch to -CURRENT to see if that changes anything. Martin PS. Robert, in researching this I got some idea of the effort you put into this, thanks! Martin -- Martin Kristensen ___ 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: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Thu, 11 Feb 2010 14:50:44 +0100 Martin Kristensen m...@pc.dk wrote: On Thu, 11 Feb 2010 06:16:12 -0600 Robert Noland rnol...@freebsd.org wrote: On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 16:01:58 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Just checked... This card should work with Accel and DRI... At least on -CURRENT with updated ports. Check UPDATING, and set WITHOUT_NOUVEAU to get correct version of libdrm. robert. I am on -STABLE built on Jan. 19. I updated mesa today (to libdrm-2.4.17), and rebuilt xorg-server and drivers. I have WITHOUT_NOUVEAU=YES in /etc/make.conf. pkg_info reports libGL-7.6.1. Is that 8-STABLE or 7? 8 should work, and I think 7 should as well, but just checking. 6 won't work. I am on 8-STABLE. I have tried loading radeon.ko manually before startx. What are the results? If things are not working, I'll want to see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X started if you can get it. robert. I have attached the output from pciconf -lvb, sysctl -a |grep ^hw.dri reports: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: hw.dri.0.clients: hw.dri.0.vblank: hw.dri.0.debug: 0 I loaded radeon.ko from within my X session, which was started with DRI OFF. Ok, if X doesn't try to open drm, then nothing will show up as being mapped. If you do a sysctl hw.dri it will show the mappings, but the above grep is cutting out most of the useful info. Sorry, I did not understand what you wanted, here is sysctl hw.dri: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: slot offset size type flags address mtrr 0 0xfe8e 0x0001 REG 0x82 0xff00fe8e no hw.dri.0.clients: a devpid uid magic ioctls hw.dri.0.vblank: crtc ref countlast enabled inmodeset 00 00 00 00 01 00 00 00 hw.dri.0.debug: 0 If I run startx with DRI True or without an xorg.conf, the screen goes into standby as if the pc is turned off, the mouse and keyboard stops responding to keypresses (ie. numlock-led will not respond to me pressing the key.) and I cannot ssh into the machine. As far as I can tell it has crashed. There is nothing in /var/log/messages, which gives any indication that something went wrong (If I boot the machine - startx and force a reboot I get 2 x dmesg plus fsck messages). Xorg.0.log contains only messages from the last successful start of xorg, and is a far as I can tell useless in tracking this down. This sounds suspiciously like a WITNESS issue... I wonder if I have accidentally MFC'd something that isn't safe. You don't get a core dump eventually do you? robert. I have left it for at least the time it takes to boot my laptop and try to ssh into the machine (5 min.). I have dumpdev defined. I will crash it and leave it for 15 min. to see if something happens. Alas, I have crashed it a couple of times and left it for ~30 min. There was no change, and I got no core dump. If it will help, I can switch to -CURRENT to see if that changes anything. Martin PS. Robert, in researching this I got some idea of the effort you put into this, thanks! Martin -- Martin Kristensen
Re: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. -- Martin Kristensen ___ 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: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Wed, 10 Feb 2010 15:57:42 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Is that an HD5xxx? robert. No, HD4890. -- Martin Kristensen ___ 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: freebsd7 (and 8), radeon, xorg-server - deadlock or so
On Wed, 10 Feb 2010 16:01:58 -0600 Robert Noland rnol...@freebsd.org wrote: On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon a...@icyb.net.ua wrote: on 10/02/2010 20:29 Vitaly Magerya said the following: Robert Noland wrote: It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices Off in xorg.conf. Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. Just checked... This card should work with Accel and DRI... At least on -CURRENT with updated ports. Check UPDATING, and set WITHOUT_NOUVEAU to get correct version of libdrm. robert. I am on -STABLE built on Jan. 19. I updated mesa today (to libdrm-2.4.17), and rebuilt xorg-server and drivers. I have WITHOUT_NOUVEAU=YES in /etc/make.conf. pkg_info reports libGL-7.6.1. I have tried loading radeon.ko manually before startx. If it will help, I can switch to -CURRENT to see if that changes anything. Martin PS. Robert, in researching this I got some idea of the effort you put into this, thanks! -- Martin Kristensen ___ 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 install linux base f10
8.0 stable freshly installed and updated, am trying to install linux base f10 and getting the following error sysctrl: unknown oid 'compat.linux.osrelease' linuxulator is not (kld)loaded, exiting pkg_add: install script returned error status is there some work around for this? cheers -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: problem install linux base f10
Scot Hetzel wrote: On Thu, Jan 14, 2010 at 10:52 AM, Martin Smith m...@rakupottery.org.uk wrote: 8.0 stable freshly installed and updated, am trying to install linux base f10 and getting the following error sysctrl: unknown oid 'compat.linux.osrelease' linuxulator is not (kld)loaded, exiting pkg_add: install script returned error status is there some work around for this? cheers You need to load the linux kernel module, before installing the linux_base-f10 port. Just do a 'kldload linux' before installing the port. Then to have the linux module always load at boot, add linux_enable=YES to /etc/rc.conf. Thanks a lot for that Scot. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: What happened to DVD writing?
Zaphod Beeblebrox (21:12 2009-09-20): On Sun, Sep 20, 2009 at 4:35 PM, Richard Mahlerwein mahle...@yahoo.comwrote: I have had several exhibit behavior even more odd. The most unusual was this particular CD writer... It read both DVDs and CDs but would write neither (it had worked fine the week before). I took it out of the drive bay and hooked it to another PC to test and it worked fine there. I put it back in the original PC and it failed. I was swapping things around on that PC (assuming bad cable, bad power, etc) and had it sitting loose on the desk and found that it now worked again. Put it back in the drive cage and it again would not write, though reading was fine. Anyway, I finally figured out that even slight pressure in on the sides where it mounts would make it fail to burn CDs. The cage itself exerted a bit of pressure and that was enough to make it fail at any attempt to burn a CD. This is not necessarily odd. The CD burner is one of the highest draw bits in your system... save possibly your CPU and/or graphics card (depending on what they are). I have found that various DVD drives have been very sensitive to power supply voltages and fail to burn properly when they're marginal. Your description here seems to point in that direction. If it works in computer B, try using B's power supply for A --- or maybe B has other lighter draws. Power supplies can also degrade over time --- especially if you have some cheap capacitors in there. I find the DVD drive is often the canary for spotting power supply problems. Hi, I have the same problem. I can read DVDs and CDs and write CDs, but I'm unable to write DVDs. I can't be sure that it is a software problem, but I think it happened when upgrading from 8.0-BETA2 to 8.0-BETA4. Not sure at all though. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem with IBM Thinkpad T30 shutting down due to high temperatures
Am Mon, 10 Aug 2009 23:53:10 +0200 schrieb Christian Walther cptsa...@gmail.com: What could I try next to prevent this from happening again? I guess it's needless to say that rebuilding ports (for example after the jpeg version bump) is next to impossible because it would require manual intervention everytime the temperature reaches the limit... I'm happy about any help I can get on this issue. Hi Christian, I've had this too with my T60p. The temperature when it shut down was 101°C. Also while compiling ports on FreeBSD. Other OSes were fine on this laptop (around 90°C when on high load). This seems to happen when using ATI based Thinkpads. The fan is for both CPU and GPU and the GPU runs idle at over 70°C, because FreeBSD is missing any power saving modes that tune down the GPU voltage (this is the only way to keep the GPU cool). Also idle temperature with FreeBSD is very high, at around 70°C instead of 50°C on OSes that can use power management for ATI mobile adapters. What to do? - check the fan and look if there is dust (clean it, but don't touch the fan too hard, because it will break!) - when compiling ports/world, make sure you have your laptop near fresh air - use a script that tunes down the frequency when temperature is above a sane level (it should tune up again, when it's sinking too far) and use it while doing some heavy things on FreeBSD I don't have the laptop anymore, because of this problem, but I still have the script. You have to check if it still works and tune the values for the temperatures and sysctls. I really don't care to make it an universal solution. http://bsdforen.pastebin.com/f331d2357 The perl script keeps a history of the temperature in last few seconds and tunes it according to the average, afair. It also prints the CPU temperature and the CPU speed. Have fun with it. ;) -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Zpool on raw disk and weird GEOM complaint
Am Mon, 29 Jun 2009 16:49:01 +0200 schrieb Marius Nünnerich mar...@nuenneri.ch: For future constructions of zpool's one should zero the first few sectors of a device. For your specific I would make a tested backup and then zero the first 1KB of da0. But beware that it's dangerous! Don't blame me if you lose data or hair! Hi Marius. I've already complained about this problem. When you've had GPT and want to remove it, you will always get endless pain, if you forget to remove the meta data (gpart destroy). And don't forget that when it is too late and you already have a file system, it's not enough to clear the first few blocks of GPT, but also the last(!) blocks on disk, because GPT has a backup table at the end of a disk that GEOM automatically tries to use. I tell you, you have a lot of fun with this! You have to be very cautious, not to lose any data when trying to dump zeroes on the raw disk device. The problem should be better documented, in my opinion. It took me hours of downtime (and some frustration) to find out how GEOM is tasting and detecting the disks. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Panic on 7.2-p1 i386
Hi, the custom kernel, I've built on my home router catched a panic today. I don't have any dump, because swap is encrypted. I've got some information written by hand... I hope it helps a bit. fault virtual address = 0xa fault code = supervisor read, page not present instruction pointer = 0x20:0xc07834 stack pointer = 0x28:0xc39aab50 frame pointer = 0x28:0xc39aab6c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 11 (idle: cpu0) Stopped at md_get_mem+0xf: mov 0x4(%eax),%ebx eax = 0x6 ebx = 0xc0714907 ds = sc_buffer.9247+0xe708 Stack trace: md_get_mem md_get_uint32 md_get_uint32le tc_ticktock hardlock uname -a: FreeBSD epona.local 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #1: Wed Jun 10 20:22:30 CEST 2009 r...@epona.local:/usr/obj/usr/src/sys/EPONA i386 -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[Solved] Re: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
Am Fri, 15 May 2009 12:05:47 -0400 schrieb John Baldwin j...@freebsd.org: On Friday 15 May 2009 11:38:00 am Martin wrote: Am Fri, 15 May 2009 11:09:20 -0400 schrieb John Baldwin j...@freebsd.org: x/i please. The /i decodes it as an instruction so I can see which registers it was attempting to dereference. Oh sorry... (kgdb) x/i 0x805bbc66 0x805bbc66 rt_maskedcopy+6: movzbl (%rdx),%edx Hmm, your %rdx is garbage. :( rdx0xef3fdf377db53afa -1207000745686779142 That should at least be 0xff.. Looks like r9 and r14 have the same odd value. Normally I would see a more obvious breakage such as one of the 'f' nibbles being set to '0' or 'e', etc. You could try looking for that odd pointer value in the route structure or as arguments to other functions in the stack trace to see if you can find a corrupted data structure. Hi John, I want to thank you once again. You have been right that the hardware was broken. I've contacted the hardware support and after replacing things like memory and mainboard (that haven't been the solution), I could finally find out that the CPU was broken. I think, this is why we haven't seen obvious memory failures, like single unflipped bits and broken patterns, but TOTALLY different memory contents. What I have learned from this: - FreeBSD 7.2R hasn't let me down :) - memtest or sometimes called memtester is a good utility when you want to test memory AND to have high load to heat up the components a bit. It is possible, because it runs within the OS. memtest86+ is first broken on FreeBSD/amd64 and it does not find anything in my case (tested on Linux), because it does not put enough load compared to 3 parallel memtest processes. - One thing I noticed on memtest is that it cannot mlock (lock memory) a big chunk of memory more than one time (just in one process). And mlock above 2GB is a problem. Perhaps, it might be interesting to look at this. Thanks John, you have been a great help for me, our web server is running stable again. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
Am Fri, 15 May 2009 08:15:19 -0400
schrieb John Baldwin j...@freebsd.org:
Hi John,
When I have seen this, it has often been due to a hardware failure
such as bad RAM.
hmmm... I will check this next week.
cpuid = 2; apic id = 02
instruction pointer = 0x8:0x805bbc66
Can you do 'x/i 0x805bbc66'? Also, can you walk up the stack
to the frame for this panic ('frame 7') and do 'info registers'?
(kgdb) x 0x805bbc66
0x805bbc66 rt_maskedcopy+6: 0x4912b60f
(kgdb) frame 7
#7 0x805bbc66 in rt_maskedcopy (src=0x51e2e6c8,
dst=0xff00525ebd80, netmask=0xef3fdf377db53afa)
at /usr/src/sys/net/route.c:1362
1362{
(kgdb) info registers
rax0xff00525ebd80 -1098129687168
rbx0xff0006b570f8 -1099399073544
rcx0x10 16
rdx0xef3fdf377db53afa -1207000745686779142
rsi0xff00525ebd80 -1098129687168
rdi0x51e2e6c8 -2921142584
rbp0x51e2e4c0 0x51e2e4c0
rsp0x51e2e428 0x51e2e428
r8 0x0 0
r9 0xef3fdf377db53afa -1207000745686779142
r100xff00016eba50 -1099487593904
r110x80b3eec0 -2135691584
r120xe22173e466d29aa0 -2152311722091570528
r130xff0006832c00 -1099402368000
r140xef3fdf377db53afa -1207000745686779142
r150x0 0
rip0x805bbc66 0x805bbc66 rt_maskedcopy+6
eflags 0x10286 66182
cs 0x8 8
ss 0x10 16
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
I hope it helps.
--
Martin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
Hi John, one more thing that I noticed. It seems that the netmask passed to the procedure rt_maskedcopy is invalid. Cannot dereference the pointer. I went one frame up and I've looked at the control flow of the parent routine rtrequest1_fib. This routine passes the netmask, but before it does that it went with req=11 (RTM_RESOLVE) through this piece of code: /usr/src/sys/net/route.c:985 case RTM_RESOLVE: if (ret_nrt == NULL || (rt = *ret_nrt) == NULL) senderr(EINVAL); ifa = rt-rt_ifa; /* XXX locking? */ flags = rt-rt_flags ~(RTF_CLONING | RTF_STATIC); flags |= RTF_WASCLONED; gateway = rt-rt_gateway; if ((netmask = rt-rt_genmask) == NULL) flags |= RTF_HOST; goto makeroute; Is this a locking problem? -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
Am Fri, 15 May 2009 11:09:20 -0400 schrieb John Baldwin j...@freebsd.org: x/i please. The /i decodes it as an instruction so I can see which registers it was attempting to dereference. Oh sorry... (kgdb) x/i 0x805bbc66 0x805bbc66 rt_maskedcopy+6: movzbl (%rdx),%edx -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
Am Fri, 15 May 2009 12:05:47 -0400 schrieb John Baldwin j...@freebsd.org: (kgdb) x/i 0x805bbc66 0x805bbc66 rt_maskedcopy+6: movzbl (%rdx),%edx Hmm, your %rdx is garbage. :( rdx0xef3fdf377db53afa -1207000745686779142 That should at least be 0xff.. Looks like r9 and r14 have the same odd value. Normally I would see a more obvious breakage such as one of the 'f' nibbles being set to '0' or 'e', etc. You could try looking for that odd pointer value in the route structure or as arguments to other functions in the stack trace to see if you can find a corrupted data structure. Hi John, I've been testing RAM for 2 hours in user space with 3 parallel processes of sysutils/memtest. What can I say? I just got this in second loop of memtest: Loop 2: Stuck Address : ok Random Value: ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential: ok Checkerboard: testing 59FAILURE: 0x != 0x40037007 at offset 0x007dc608. FAILURE: 0x != 0xf070ef7 at offset 0x007dc609. FAILURE: 0x != 0x4003 at offset 0x007dc60a. FAILURE: 0x != 0x4002 at offset 0x007dc60b. FAILURE: 0x != 0x807cb4e0 at offset 0x007dc60c. FAILURE: 0x != 0x at offset 0x007dc60d. FAILURE: 0x != 0x02fa at offset 0x007dc60e. FAILURE: 0x != 0x at offset 0x007dc60f. Bit Spread : ok Bit Flip: setting 35^C I think this is obvious enough. Thank you for your patience with me. This was a good hint. I would have never thought of a RAM defect. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FAILURE - zero length DMA transfer attempted
Hi, yesterday I was using my DVD drive (simply reading a DVD). I got lots of syslog entries that look like this: ata4: FAILURE - zero length DMA transfer attempted acd0: setting up DMA failed This happens on: FreeBSD kirby 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Wed May 6 09:40:10 CEST 2009 r...@kirby:/usr/obj/usr/src/sys/GENERIC amd64 Drive is Sony NEC Optiarc (SATA): acd0: DVDR Optiarc DVD RW AD-7203S/1.06 at ata4-master SATA150 SATA controller is from Intel: atapci1: Intel AHCI controller port 0xe600-0xe607,0xe700-0xe703,0xe800-0xe807, 0xe900-0xe903,0xea00-0xea1f mem 0xe9306000-0xe93067ff irq 19 at device 31.2 on p ci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.20 controller with 6 ports detected There are no problems during reading the DVD, but I thought I it might still be interesting. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
kernel trap 12 with interrupts disabled [bge0 on 7.2R]
] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: Intel 82801GB/R (ICH7) USB 2.0 controller on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb2 uhub2: 4 ports with 4 removable, self powered pcib5: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib5 vgapci0: VGA-compatible display port 0xdc00-0xdc7f mem 0xf800-0xfbff,0xfe8c-0xfe8f at device 4.0 on pci1 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH7 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] atapci1: Intel ICH7 SATA300 controller port 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc807,0xc480-0xc483,0xc400-0xc40f mem 0xfe7ffc00-0xfe7f irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: ATA channel 0 on atapci1 ata2: [ITHREAD] ata3: ATA channel 1 on atapci1 ata3: [ITHREAD] pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_button0: Power Button on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] cpu0: ACPI CPU on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - 77, should be 74 [20070320] est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 cpu2: ACPI CPU on acpi0 est2: Enhanced SpeedStep Frequency Control on cpu2 p4tcc2: CPU Frequency Thermal Control on cpu2 cpu3: ACPI CPU on acpi0 est3: Enhanced SpeedStep Frequency Control on cpu3 p4tcc3: CPU Frequency Thermal Control on cpu3 orm0: ISA Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xc9fff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ukbd0: vendor 0x046a product 0x0023, class 0/0, rev 2.00/0.32, addr 2 on uhub0 kbd2 at ukbd0 uhid0: vendor 0x046a product 0x0023, class 0/0, rev 2.00/0.32, addr 2 on uhub0 Timecounters tick every 1.000 msec acd0: DVDR ASUS DRW-1612BL/1.06 at ata0-slave UDMA66 da0 at twa0 bus 0 target 0 lun 0 da0: AMCC 9650SE-2LP DISK 4.06 Fixed Direct Access SCSI-5 device da0: 100.000MB/s transfers da0: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! GEOM_LABEL: Label for provider da0p2 is ufsid/4933dfd79a3e27cc. GEOM_LABEL: Label for provider da0p4 is ufsid/4933dfe53ca04410. GEOM_LABEL: Label for provider da0p5 is ufsid/4933dfedbb4398a4. GEOM_JOURNAL: Journal 326427402: da0p6 contains data. GEOM_JOURNAL: Journal 326427402: da0p6 contains journal. GEOM_JOURNAL: Journal da0p6 clean. GEOM_LABEL: Label for provider da0p6.journal is ufsid/4933e04607a73efa. Trying to mount root from ufs:/dev/da0p2 GEOM_LABEL: Label ufsid/4933dfd79a3e27cc removed. GEOM_LABEL: Label for provider da0p2 is ufsid/4933dfd79a3e27cc. GEOM_LABEL: Label ufsid/4933dfe53ca04410 removed. GEOM_LABEL: Label for provider da0p4 is ufsid/4933dfe53ca04410. GEOM_LABEL: Label ufsid/4933dfedbb4398a4 removed. GEOM_LABEL: Label for provider da0p5 is ufsid/4933dfedbb4398a4. GEOM_LABEL: Label ufsid/4933dfd79a3e27cc removed. GEOM_LABEL: Label ufsid/4933dfe53ca04410 removed. GEOM_LABEL: Label ufsid/4933dfedbb4398a4 removed. GEOM_LABEL: Label ufsid/4933e04607a73efa removed. bge0: promiscuous mode enabled -- Martin __ Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele ausländische Netze zum gleichen Preis! https://produkte.web.de/webde_sms/sms ___ 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: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
Am Thu, 14 May 2009 09:16:40 -0400 schrieb John Baldwin j...@freebsd.org: On Thursday 14 May 2009 7:47:23 am Martin Sugioarto wrote: [...] kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 0 fault virtual address = 0x800 Given that that is a single bit set, it could possibly be due to bad RAM. This is the second panic output that appeared on the screen. I could not read the first lines of the first panic. The last ones looked similar (same trap/process etc). Does your kernel have debug symbols? This is GENERIC kernel configuration. The kernel was totally frozen. I could not type anything. I just noticed, I've got a vmcore.0 of the crash. I can see some other panic output when loading the kernel in kgdb: Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x8:0x805bbc66 stack pointer = 0x10:0x51e2e410 frame pointer = 0x10:0x51e2e4c0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1311 (nfsiod 0) trap number = 9 panic: general protection fault cpuid = 2 Uptime: 1h5m39s Physical memory: 8179 MB Dumping 479 MB: 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 Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols from /boot/kernel/geom_journal.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_journal.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/pflog.ko...Reading symbols from /boot/kernel/pflog.ko.symbols...done. done. Loaded symbols for /boot/kernel/pflog.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko #0 doadump () at pcpu.h:195 195 __asm __volatile(movq %%gs:0,%0 : =r (td)); Here the backtrace: #0 doadump () at pcpu.h:195 #1 0x0004 in ?? () #2 0x8050df19 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0x8050e322 in panic (fmt=0x104 Address 0x104 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0x807d2193 in trap_fatal (frame=0xff0006abb000, eva=Variable eva is not available. ) at /usr/src/sys/amd64/amd64/trap.c:757 #5 0x807d2ce5 in trap (frame=0x51e2e360) at /usr/src/sys/amd64/amd64/trap.c:558 #6 0x807b700e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #7 0x805bbc66 in rt_maskedcopy (src=0x51e2e6c8, dst=0xff00525ebd80, netmask=0xef3fdf377db53afa) at /usr/src/sys/net/route.c:1362 #8 0x805bc4e5 in rtrequest1_fib (req=11, info=0x51e2e4c0, ret_nrt=0x51e2e5e8, fibnum=0) at /usr/src/sys/net/route.c:1036 #9 0x805bd09d in rtrequest_fib (req=11, dst=0x51e2e6c8, gateway=0x0, netmask=0x0, flags=0, ret_nrt=0x51e2e5e8, fibnum=0) at /usr/src/sys/net/route.c:738 #10 0x805bd531 in rtalloc1_fib (dst=0x51e2e6c8, report=1, ignflags=18446744073709551615, fibnum=0) at /usr/src/sys/net/route.c:315 #11 0x805be749 in rtalloc_ign_fib (ro=0x51e2e6c0, ignore=0, fibnum=0) at /usr/src/sys/net/route.c:252 #12 0x805f4cad in ip_output (m=0xff0006b04b00, opt=0x0, ro=0x51e2e6c0, flags=0, imo=0x0, inp=0xff0006c41120) at /usr/src/sys/netinet/ip_output.c:230 #13 0x806582fa in tcp_output (tp=0xff0006c65b60) at /usr/src/sys/netinet/tcp_output.c:1128 #14 0x80663774 in tcp_usr_send (so=0xff0006aa85a0, flags=0, m=0xff00526f3c00, nam=Variable nam is not available. ) at tcp_offload.h:269 #15 0x8056addb in sosend_generic (so=0xff0006aa85a0, addr=0x0, uio=0x0, top=0xff00526f3c00, control=0x0, flags=Variable flags is not available. ) at /usr/src/sys/kern/uipc_socket.c:1246 #16 0x8069f73f in nfs_send (so=0xff0006aa85a0, nam=Variable nam is not available. ) at /usr/src/sys/nfsclient/nfs_socket.c:664 #17 0x806a2ab9 in nfs_request (vp=0xff0052bd9bd0, mrest=Variable mrest is not available. ) at /usr/src/sys/nfsclient/nfs_socket.c:1217 #18 0x806aadfa in nfs_readrpc (vp=0xff0052bd9bd0, uiop=0x51e2eb30, cred=0xff0052899d00) at /usr/src/sys/nfsclient/nfs_vnops.c:1119 #19 0x8069a1c9 in nfs_doio (vp=0xff0052bd9bd0, bp=0x26332020, cr=0xff0052899d00, td=Variable td is not available. ) at /usr/src/sys/nfsclient/nfs_bio.c:1571 #20 0x806a5e48
RE: 7.1-STABLE Sun Mar 29 01:06:46 ADT 2009 Locks up ...
Hi Marc and List, i had similar issues with FreeBSD 7.2-PRERELEASE. Server (zfs,nfs) seems to hang in intervals of about 8 hours. kernel is still there but no connections can be made to nfs/ssh and login on local console doesn't seem to work due to incredible slowness. breaking to the debugger takes a moment but works. (compiling kernel with WITNESS didnt help) the server had been solid before with 7 stable kernel from around 19 October 2008. I now added these lines to /boot/loader.conf hw.pci.enable_msi=0 hw.pci.enable_msix=0 to disable Message Signaled Interrupts. Which are used by the 3ware twa driver and igb network driver on our server. With this the server had run 3 days with no hangs. I then enabled msi again and had a hang within 24 hours. Disabled again and now the server is online without an issue for 6 days. Im not 100% sure yet if this really is the sole source of the problems (e.g. workload might be another factor). But i guess its worth a try to check if it might help you too. If this is a known problem or there are any other hints to solve this problem or if the server configuration just seems wrong, i appreciate the feedback. regards, Martin pciconf (with msi): hos...@pci0:0:0:0: class=0x06 card=0xa28015d9 chip=0x40038086 rev=0x20 hdr=0x00 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[6c] = PCI-Express 2 root port pc...@pci0:0:1:0: class=0x060400 card=0xa28015d9 chip=0x40218086 rev=0x20 hdr=0x01 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[6c] = PCI-Express 2 root port cap 0d[b0] = PCI Bridge card=0xa28015d9 pc...@pci0:0:3:0: class=0x060400 card=0xa28015d9 chip=0x40238086 rev=0x20 hdr=0x01 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[6c] = PCI-Express 2 root port cap 0d[b0] = PCI Bridge card=0xa28015d9 pc...@pci0:0:5:0: class=0x060400 card=0xa28015d9 chip=0x40258086 rev=0x20 hdr=0x01 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[6c] = PCI-Express 2 root port cap 0d[b0] = PCI Bridge card=0xa28015d9 pc...@pci0:0:7:0: class=0x060400 card=0xa28015d9 chip=0x40278086 rev=0x20 hdr=0x01 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[6c] = PCI-Express 2 root port cap 0d[b0] = PCI Bridge card=0xa28015d9 pc...@pci0:0:9:0: class=0x060400 card=0xa28015d9 chip=0x40298086 rev=0x20 hdr=0x01 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[6c] = PCI-Express 2 root port cap 0d[b0] = PCI Bridge card=0xa28015d9 no...@pci0:0:15:0: class=0x088000 card=0xa28015d9 chip=0x402f8086 rev=0x20 hdr=0x00 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 11[58] = MSI-X supports 4 messages in map 0x10 cap 10[6c] = PCI-Express 2 type 0 hos...@pci0:0:16:0: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 hos...@pci0:0:16:1: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 hos...@pci0:0:16:2: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 hos...@pci0:0:16:3: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 hos...@pci0:0:16:4: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 hos...@pci0:0:17:0: class=0x06 card=0xa28015d9 chip=0x40318086 rev=0x20 hdr=0x00 hos...@pci0:0:21:0: class=0x06 card=0xa28015d9 chip=0x40358086 rev=0x20 hdr=0x00 hos...@pci0:0:21:1: class=0x06 card=0xa28015d9 chip=0x40358086 rev=0x20 hdr=0x00 hos...@pci0:0:22:0: class=0x06 card=0xa28015d9 chip=0x40368086 rev=0x20 hdr=0x00 host...@pci0:0:22:1:class=0x06 card=0xa28015d9 chip=0x40368086 rev=0x20 hdr=0x00 pc...@pci0:0:28:0: class=0x060400 card=0xa28015d9 chip=0x26908086 rev=0x09 hdr=0x01 cap 10[40] = PCI-Express 1 root port cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0xa28015d9 cap 01[a0] = powerspec 2 supports D0 D3 current D0 uh...@pci0:0:29:0: class=0x0c0300 card=0xa28015d9 chip=0x26888086 rev=0x09 hdr=0x00 uh...@pci0:0:29:1: class=0x0c0300 card=0xa28015d9 chip=0x26898086 rev=0x09 hdr=0x00 uh...@pci0:0:29:2: class=0x0c0300 card=0xa28015d9 chip=0x268a8086 rev=0x09 hdr=0x00 eh...@pci0:0:29:7: class=0x0c0320 card=0xa28015d9 chip=0x268c8086 rev=0x09 hdr=0x00 cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 pci...@pci0:0:30:0: class=0x060401 card=0xa28015d9 chip=0x244e8086 rev=0xd9 hdr=0x01 cap 0d[50] = PCI Bridge card=0xa28015d9 is...@pci0:0:31:0: class=0x060100 card=0xa28015d9 chip=0x26708086 rev=0x09 hdr=0x00 atap...@pci0:0:31:1:class=0x01018a card=0xa28015d9 chip=0x269e8086 rev=0x09 hdr=0x00 atap
Re: no USB mice detected on GA-MA74GM-S2
Am Wed, 8 Apr 2009 21:08:05 +0200 schrieb Piotr Smyrak piotr.smy...@heron.pl: First I started with my old build of 6.2, then upgraded to 6.4 STABLE, to finally upgrade to 7.2 PRERELEASE in hope of fixing the issue. None of versions gave me USB mouse support. I have tried connecting 3 various mice. No luck. The only effect I can achieve after connecting a mouse, is a somewhat delayed message on console: Hi, I have had also problems with recent Gigabyte Mainboards and USB mice. Something is really broken in this branch. Unlike you, I could always get my mouse to work by re-attaching it. You should perhaps take a look at the BIOS USB settings, so you could get at least the re-attaching work-around to work. BIOS settings that influence the behavior of USB mice are: - any legacy USB support settings - so-called BIOS support for USB mice Because -STABLE has been really frustrating, I migrated all my desktops to -CURRENT that has the new USB-v2 stack. The USB problems disappeared there. I'm overall satisfied with -CURRENT. I've always wanted to say that FreeBSD developers do a really great job on the -CURRENT branch. It's running very stable and has plenty of new features. I know I shouldn't recommend to migrate to -CURRENT, but I'm almost sure, it runs much better than every -CURRENT I've seen before and sometimes I have the impression that it's even nicer than the -STABLE branch. Everyone who does not like the buggy USB v1, could try to do a second installation on a free partition to get rid of the annoyances. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
AW: FreeBSD 7.2-BETA1 tcp retransmit crash
Hi,
(kgdb) frame 7
#7 0xc07c6cb0 in sbsndptr (sb=0xc342ede4, off=112, len=113, moff=0xc2f9ca04)
at /usr/src/sys/kern/uipc_sockbuf.c:939
This is also interesting. Is this an OffByOne somewhere ?
As I said it's just a workaround, and for now it didn't crash anymore :-)
I could modify this patch to see what happens exactly, dumpping the mbuf.
The workaround I currently use is just skipping and dropping this mbuf:
--- sys/kern/uipc_sockbuf.c.orig2009-04-05 18:01:35.0 +0200
+++ sys/kern/uipc_sockbuf.c 2009-04-05 18:01:46.0 +0200
@@ -930,6 +930,13 @@
return (sb-sb_mb);
}
+ /*
+* Try to avoid some retransmit panics
+*/
+ if (sb-sb_sndptr == NULL sb-sb_mb == NULL) {
+ return (NULL);
+ }
+
/* Return closest mbuf in chain for current offset. */
*moff = off - sb-sb_sndptroff;
m = ret = sb-sb_sndptr ? sb-sb_sndptr : sb-sb_mb;
--- sys/netinet/tcp_output.c.orig 2009-04-05 18:01:29.0 +0200
+++ sys/netinet/tcp_output.c2009-04-05 18:04:17.0 +0200
@@ -797,6 +797,17 @@
*/
mb = sbsndptr(so-so_snd, off, len, moff);
+
+ /*
+* Avoid panics. Mask the error with ENETDOWN
+*/
+ if (mb == NULL) {
+ SOCKBUF_UNLOCK(so-so_snd);
+ (void) m_free(m);
+ error = ENETDOWN;
+ goto out;
+ }
+
if (len = MHLEN - hdrlen - max_linkhdr) {
m_copydata(mb, moff, (int)len,
mtod(m, caddr_t) + hdrlen);
___
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 7.2-BETA1 tcp retransmit crash
Hi all,
Looks like the same problem as PR 129197 (FreeBSD 7 panic)
http://www.freebsd.org/cgi/query-pr.cgi?pr=129197
OS: FreeBSD 7.2 BETA1
PF: Enabled
SACK: net.inet.tcp.sack.enable: 1
Happens after some/many soabort calls ... I can reproduce it
after 3-4 hours running time. Currently I'm testing a workaround
but I guess the underlying problem should be fixed.
--
Martin
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0xc
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc07c6cb0
stack pointer = 0x28:0xc2f9c97c
frame pointer = 0x28:0xc2f9c984
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 = 25 (em0 taskq)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 4h12m47s
Physical memory: 499 MB
Dumping 104 MB: 89 73 57 41 25 9
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
/usr/local/lib/vmware-tools/modules/drivers/vmmemctl.ko...done.
Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmmemctl.ko
Reading symbols from
/usr/local/lib/vmware-tools/modules/drivers/vmxnet.ko...done.
Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmxnet.ko
Reading symbols from
/usr/local/lib/vmware-tools/modules/drivers/vmblock.ko...done.
Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmblock.ko
Reading symbols from
/usr/local/lib/vmware-tools/modules/drivers/vmhgfs.ko...done.
Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmhgfs.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols from
/boot/kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.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/modules/accf_smtp.ko...done.
Loaded symbols for /boot/modules/accf_smtp.ko
#0 doadump () at pcpu.h:196
#1 0xc0772d87 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2 0xc0773059 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0xc0a5062c in trap_fatal (frame=0xc2f9c93c, eva=12) at
/usr/src/sys/i386/i386/trap.c:939
#4 0xc0a508b0 in trap_pfault (frame=0xc2f9c93c, usermode=0, eva=12) at
/usr/src/sys/i386/i386/trap.c:852
#5 0xc0a5125c in trap (frame=0xc2f9c93c) at /usr/src/sys/i386/i386/trap.c:530
#6 0xc0a3593b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7 0xc07c6cb0 in sbsndptr (sb=0xc342ede4, off=112, len=113, moff=0xc2f9ca04)
at /usr/src/sys/kern/uipc_sockbuf.c:939
#8 0xc089cd64 in tcp_output (tp=0xc43311d0) at
/usr/src/sys/netinet/tcp_output.c:798
#9 0xc089974a in tcp_do_segment (m=0xc34a6600, th=0xc34c8024, so=0xc342ed00,
tp=0xc43311d0, drop_hdrlen=52, tlen=0)
at /usr/src/sys/netinet/tcp_input.c:1835
#10 0xc089b2ee in tcp_input (m=0xc34a6600, off0=20) at
/usr/src/sys/netinet/tcp_input.c:846
#11 0xc08340a0 in ip_input (m=0xc34a6600) at /usr/src/sys/netinet/ip_input.c:664
#12 0xc081ae15 in netisr_dispatch (num=2, m=0xc34a6600) at
/usr/src/sys/net/netisr.c:185
#13 0xc0810d81 in ether_demux (ifp=0xc31bb400, m=0xc34a6600) at
/usr/src/sys/net/if_ethersubr.c:834
#14 0xc0811173 in ether_input (ifp=0xc31bb400, m=0xc34a6600) at
/usr/src/sys/net/if_ethersubr.c:692
#15 0xc0561f2a in em_rxeof (adapter=0xc31bc000, count=99) at
/usr/src/sys/dev/e1000/if_em.c:4539
#16 0xc0562a57 in em_handle_rxtx (context=0xc31bc000, pending=1) at
/usr/src/sys/dev/e1000/if_em.c:1702
#17 0xc07a8015 in taskqueue_run (queue=0xc3181780) at
/usr/src/sys/kern/subr_taskqueue.c:282
#18 0xc07a8228 in taskqueue_thread_loop (arg=0xc31c035c) at
/usr/src/sys/kern/subr_taskqueue.c:401
#19 0xc074d839 in fork_exit (callout=0xc07a8160 taskqueue_thread_loop,
arg=0xc31c035c, frame=0xc2f9cd38) at /usr/src/sys/kern/kern_fork.c:810
#20 0xc0a359b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264
(kgdb) frame 7
#7 0xc07c6cb0 in sbsndptr (sb=0xc342ede4, off=112, len=113, moff=0xc2f9ca04)
at /usr/src/sys/kern/uipc_sockbuf.c:939
939 off 0 off = m-m_len;
(kgdb) list
934 *moff = off - sb-sb_sndptroff;
935 m = ret = sb-sb_sndptr ? sb-sb_sndptr : sb-sb_mb;
936
937 /* Advance by len to be as close as possible for the next
transmit. */
938 for (off = off - sb-sb_sndptroff + len - 1;
939 off 0 off = m-m_len;
940 m = m-m_next) {
941 sb-sb_sndptroff += m-m_len;
942 off -= m-m_len;
943 }
(kgdb) p sb-sb_sndptr
$1 = (struct mbuf *) 0x0
(kgdb) p sb-sb_mb
$2 = (struct mbuf *) 0x0
Kein Wunder gibts da nen Crash
IPv6 gif(4) MTU: manpage vs src inconsistency?
Hi, it seems I have trouble to reach some websites using IPv6 through a gif tunnel. Most websites work, except for these two: www.freebsd.org www.kame.net I've searched for problems and it seems, I cannot send ping packets larger than 1232 from the host behind my router. That's why I wanted to decrease the MTU on gif from 1280 to 1240, as the manpage gif(4) suggests: If the outer protocol is IPv6, path MTU discovery for encapsulated packets may affect communication over the interface. The first bigger-than- pmtu packet may be lost. To avoid the problem, you may want to set the interface MTU for gif to 1240 or smaller, when the outer header is IPv6 and the inner header is IPv4. And I tried it: # ifconfig gif0 mtu 1240 ifconfig: ioctl (set mtu): Invalid argument It does not work, because in source, you can find: if_gif.h: #define GIF_MTU (1280) /* Default MTU */ #define GIF_MTU_MIN (1280) /* Minimum MTU */ #define GIF_MTU_MAX (8192) /* Maximum MTU */ What now? One of the values is wrong, in my opinion. I still don't know the exact cause of the IPv6 website problems. Is there anyone who has a solution for this? I can access ALL WEBSITES from my router directly that has configured the gif tunnel. But all hosts that use the router for default route cannot access the two websites. I have also no issues with traffic to IRC server and so on. I've just found these two hosts that are different somehow. This is confusing. Router configuration: tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1492 inet xx.xx.xx.xx -- yy.yy.yy.yy netmask 0x Opened by PID 433 gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1280 tunnel inet xx.xx.xx.xx -- 192.88.99.1 inet6 2002::::1 prefixlen 64 Host behind the router that chokes on the two websites: re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=389bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC ether zz:zz:zz:zz:zz:zz inet6 fe80:::::%re0 prefixlen 64 scopeid 0x1 inet 192.168.0.12 netmask 0xff00 broadcast 192.168.0.255 inet6 fde2::::::: prefixlen 64 autoconf inet6 2002:::1:::: prefixlen 64 autoconf media: Ethernet autoselect (100baseTX full-duplex) status: active -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 7.1 Release and usb keyboard/mouse problems
Am Sat, 17 Jan 2009 21:23:09 +1100 schrieb Tony Maher tonyma...@optusnet.com.au: Hello, I have been running FreeBSD 7 from around 2008-10-20 and experienced the occasional problems with usb mouse and keyboard. The mouse pointer slowly drift to a corner of the screen and not respond, and the keyboard would become unresponsive. Unplugging and plugging back in fixed the problem. This would happen a few times per week. Hi, I've reported problems like this on -STABLE more than once already. Apparently it is a very uncommon problem for the developers. I have to say that all my new PCs and the new laptop has problems with USB keyboards and mice generally. The laptop (IBM Thinkpad T60p) has the most problems, -STABLE switches the USB devices off in intervals of about 2h. I have updated (flashed) my BIOS firmware on this mainboard here (Gigabyte GA-EP35C-DS3R rev 2.1) to the recent firmware F4a (it's a 6 month old beta release). The problem worsened now. I cannot get my USB mouse working until I reattach it physically. This is not a problem on other OSes, it seems. During device detection and initialization of uhci/ehci my USB-mouse is switched off and does not get power anymore. I get the same effect on -CURRENT as of yesterday. Mouse is Logitech G5, btw. I tried various USB settings in BIOS. USB mouse support on/off, USB legacy device support on/off. What else can I do? This is very annoying. (I wonder if it can be the source of many problems that people report here about umass devices.) -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 7.1 Release and usb keyboard/mouse problems
Am Wed, 21 Jan 2009 14:15:38 +0100 schrieb Pieter de Goeje pie...@degoeje.nl: I have a Gigabyte GA-P35-DS3R w/ a Logitech G5 mouse and usb keyboard. I had to switch to usb2 on freebsd 8-current for the keyboard to attach after boot. I have enabled usb keyboard support in the BIOS (otherwise the keyboard cannot be used during the boot process). Everything is working fine now. Hi Pieter. Thank you for the hint with usb2. I'll try it as soon as possible. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 7.1 Live Filesystem CD
Am Tue, 06 Jan 2009 03:48:56 -0500 schrieb Ken Smith kensm...@cse.buffalo.edu: On Mon, 2009-01-05 at 20:53 -0800, Doug Hardie wrote: Is the Live Filesystem CD supposed to be bootable? 7.0's was but I can't get the 7.1 disc to boot. It works fine if I boot from CD 1 and then switch. Yes, it's supposed to be bootable. Works for me. Which architecture? Hi Ken und Doug, I want to confirm this. I tested RC1, RC2 and RELEASE livefs CD i386. They don't boot on some PCs. I can still use 8.0 CURRENT snapshot livefs for i386 on the same problematic PC. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.1-RC2 Available...
Am Thu, 25 Dec 2008 09:37:55 -0500 schrieb Ken Smith kensm...@cse.buffalo.edu: FreeBSD 7.1-RC2 is now available, the second of the Release Candidates. Unless an as yet undiscovered show-stopper comes along the release itself will be anywhere from a week to two weeks from now. Hi, the RC2 livefs CD still does not boot on my P2-350 machine. It works on my laptop though. Did something essential change after BETA2 in the boot sector? I can still boot a 8.0-CURRENT (december snapshot) livefs CD on this old box. With RC1 and RC2 I only get Booting CD-ROM... failure. from my BIOS (Asus board P2B). Any ideas? -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.1-RC2 Available...
Am Sun, 28 Dec 2008 10:25:17 -0500 schrieb Glen Barber glen.j.bar...@gmail.com: With RC1 and RC2 I only get Booting CD-ROM... failure. from my BIOS (Asus board P2B). Any ideas? 1.) Try disabling ACPI 2.) Try hw.ata.ata_dma=0 at the boot prompt. Hi Glen, I think my PC doesn't even get to the point where it loads anything from the CD. The BIOS displays a message that the CD is not bootable. It might have something to do with the problem that old PCs use CD emulation boot and it was somehow disabled since RC1. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.1-RC2 Available...
Am Sun, 28 Dec 2008 10:33:25 -0500 schrieb SDH Admin ad...@stardothosting.com: Try burning new cd media and/or try another cd-rom drive if possible, if the acpi/dma doesn't work. Hi, I've tried that already with RC1. I've burned it multiple times and tried 3 drives. It seems someone removed CD emulation boot from the livefs CD. It won't work with older PCs anymore. I'm using 8.0-CURRENT now, but I wanted to give you people a notice. Sometimes a live CD is useful and perhaps you won't be able to boot it anymore. I just realized that the CD is not booting on older PCs only, that's why noone is really concerned about it here, perhaps thinking that I'm not able to burn an ISO or something like that. But I can definitely boot 8-CURRENT livefs without problems, so at least it's not a drive problem. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Very serious cooling issues CURRENT/STABLE
Am Sun, 21 Dec 2008 00:54:35 -0500 schrieb Nathan Lay ns...@comcast.net: Hi list(s) Early in the year I noticed CURRENT failed to cool my frankenstein Thinkpad T40 (built from T40/40p parts) under load. The system would shut down from critically high temperatures while building a port. I did nothing special with ACPI. I thought nothing of it since, after all, I rebuilt a broken T40 from T40p parts. Today, however, I noticed that a very recent STABLE build failed to keep my T43 cool while building ports. It reached temperatures of 97, 98, 99C. Hallo Nathan, I can confirm this on a T60p. My notebooks shuts down since I use 7.0 at 101°C. I have written a script that throttles the CPU if it gets above 75°C. I have to use it when I'm building world or ports. Btw, I have reported the problem here a some time ago [1]. I have received some feedback that IBM/Lenovo uses wrong cooling strategy placing the CPU and the VGA under one single cooled surface and using too much thermal grease. On the other hand I have also emphasized that the fan should be able to have about 800rpm more at the temperature of 80°C, but this has been ignored so far. This is why I have never had any problems running the other common operating systems and I have put them under heavy load. They don't exceed 85°C. It used to reach a max temperature of 80C while building a port (idling temperature is ~ 45C). It behaved normally from 5.3 all the way through 7.0. To remedy both issues, I had to underclock the processor (via dev.cpu) and force the fan to its highest (I'm running 533MHz shy of the processor's full potential, with a fan level of 7 to keep the temperature at ~75C). I have one further hint for you. The VGA is running very hot on FreeBSD (~75°C when idle), because it is not able to throttle the GPU and its voltage. Maybe you've had a working setup for your GPU before and you even did not notice? Did you change your Xorg drivers? I've always suspected FreeBSD's ACPI didn't work properly on Thinkpad T series laptops (I have T40, T41, T42 and T43) as it could never fully use the fan (Windows XP can rev the fan far higher than acpi_ibm's level 7). Between STABLE and CURRENT...something seems very wrong. These systems never had cooling issues with FreeBSD before. The fan is running definitely too slow. On my system, too. Thanks, Martin References: [1] http://lists.freebsd.org/pipermail/freebsd-stable/2008-June/042812.html ___ 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 7.1-RC1 Available...
Am Tue, 09 Dec 2008 21:39:26 -0500 schrieb Ken Smith kensm...@cse.buffalo.edu: FreeBSD 7.1-RC1 is now available, the first of the Release Candidates. There will be at least one more Release Candidate before the release so the release itself is likely around 3 weeks from now IF no new show-stoppers are uncovered during testing. Hi, I have just tried to use the RC1-livefs-CD (i386). It seems, I cannot boot it. I tried 3 different CD-R(W)s and three different drives (even one SCSI drive!). -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
nfs unreachable: can't get /dev/console for controlling terminal
Hi, besides the wrong order of initializing syslogd in rc system when IPv6 has been enabled, I have found a second similar problem with the rc system on my client desktops. When you physically detach your NIC or make wireless access point inaccessible on which you have an nfs mounted file system (in fstab). The system will prevent you to get access to /dev/console and won't even start in single user mode. This is extremely annoying. Nov 25 07:58:11 zelda init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Nov 25 07:58:11 zelda init: can't get /dev/console for controlling terminal: Operation not permitted Nov 25 07:58:42 zelda init: can't get /dev/console for controlling terminal: Operation not permitted Nov 25 08:00:13 zelda last message repeated 3 times Nov 25 08:01:15 zelda last message repeated 2 times -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: swap_pager: indefinite wait
Sossi Andrej schrieb: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 31, size: 4096 Can somebody help me understand why the system crashed this way or how to avoid future crash? This happens when it takes more than 20 seconds to swap out a page (http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#INDEFINITE-WAIT-BUFFER). I had the same problem some time ago with FreeBSD 6.0 when making Backups (so the disks were busy). For me it helped to increase the timeout from 20 to 40 seconds in vm/swap_pager.c (http://fxr.watson.org/fxr/source/vm/swap_pager.c?v=FREEBSD60#L1103) -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
syslogd starting earlier network scripts
Hi, I have a weird situation here on 7-PRERELEASE since a longer time. When I enable IPv6, syslogd tries to start before the network is being initialised and I get the following output: Mounting local file systems:. hw.snd.default_unit: 0 - 1 Setting hostname: zelda.local. Creating and/or trimming log files:. Starting syslogd. Nov 18 16:01:27 syslogd: bind: Can't assign requested address Nov 18 16:01:27 syslogd: bind: Can't assign requested address syslogd: child pid 226 exited with return code 1 Checking for core dump on /dev/ad0s1b.eli... savecore: error reading last dump header at offset 8589930496 in /dev/ad0s1b.eli : Invalid argument savecore: no dumps found Initial amd64 initialization:. Additional ABI support: linux. re0: link state changed to DOWN re0: no link re0: link state changed to UP got link re0: link state changed to DOWN DHCPREQUEST on re0 to 255.255.255.255 port 67 re0: link state changed to UP DHCPACK from 192.168.0.1 re0: link state changed to DOWN re0: link state changed to UP bound to 192.168.0.12 -- renewal in 18 seconds. lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff00 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=389bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST ,WOL_MCAST,WOL_MAGIC ether xx inet6 x%re0 prefixlen 64 scopeid 0x1 inet 192.168.0.12 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX full-duplex) status: active Starting pflog. pflog0: promiscuous mode enabled Enabling pf. [...] At the moment, I'm using a workaround and start syslogd once again in /etc/rc.local. Here my rc.conf: pf_enable=YES pflog_enable=YES pflog_logfile=/var/log/pflog hostname=xx defaultrouter=192.168.0.1 ipv6_enable=YES ipv6_defaultrouter=x ipv6_ifconfig_re0=xx nfs_client_enable=YES ifconfig_re0=DHCP amd_enable=YES amd_flags=-d xx -a /.amd_mnt -l syslog /net /etc/amd.map keymap=german.iso keyrate=fast font8x14=iso15-8x14 font8x16=iso15-8x16 font8x8=iso15-8x8 gdm_enable=YES hald_enable=YES cupsd_enable=YES dbus_enable=YES linux_enable=YES moused_ums0_enable=YES ntpd_enable=YES ntpd_config=/etc/ntp.conf polkitd_enable=YES smartd_enable=YES sshd_enable=YES hcsecd_enable=YES sdpd_enable=YES geli_devices=ad0s1g dumpdev=/dev/ad0s1b.eli bsdstats_enable=YES Is it a bug in the rc start script sequence or wrong configuration? -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
