Re: Strange network/socket anomalies since about a month
On Apr 22, 2024, at 3:26 AM, Alexander Leidinger
wrote:
> Hi,
>
> I see a higher failure rate of socket/network related stuff since a while.
> Those failures are transient. Directly executing the same thing again may or
> may not result in success/failure. I'm not able to reproduce this at will.
> Sometimes they show up.
>
> Examples:
> - poudriere runs with the sccache overlay (like ccache but also works for
> rust) sometimes fail to create the communication socket and as such the build
> fails. I have 3 different poudriere bulk runs after each other in my build
> script, and when the first one fails, the second and third still run. If the
> first fails due to the sccache issue, the second and 3rd may or may not fail.
> Sometimes the first fails and the rest is ok. Sometimes all fail, and if I
> then run one by hand it works (the script does the same as the manual run,
> the script is simply a "for type in A B C; do; poudriere bulk -O sccache -j
> $type -f ${type}.pkglist; done" which I execute from the same shell, and the
> script doesn't do env-sanityzing).
> - A webmail interface (inet / local net -> nginx (rev-proxy) -> nginx
> (webmail service) -> php -> imap) sees intermittent issues sometimes. Opening
> the same email directly again afterwards normally works. I've also seen
> transient issues with pgp signing (webmail interface -> gnupg / gpg-agent on
> the server), simply hitting send again after a failure works fine.
>
> Gleb, could this be related to the socket stuff you did 2 weeks ago? My world
> is from 2024-04-17-112537. I do notice this since at least then, but I'm not
> sure if they where there before that and I simply didn't notice them. They
> are surely "new recently", that amount of issues I haven's seen in January.
> The last two updates of current I did before the last one where on
> 2024-03-31-120210 and 2024-04-08-112551.
>
> I could also imagine that some memory related transient failure could cause
> this, but with >3 GB free I do not expect this. Important here may be that I
> have https://reviews.freebsd.org/D40575 in my tree, which is memory related,
> but it's only a metric to quantify memory fragmentation.
>
> Any ideas how to track this down more easily than running the entire
> poudriere in ktrace (e.g. a hint/script which dtrace probes to use)?
No answers, I'm afraid, just a "me too."
I have the same problem as you describe when using ports-mgmt/sccache-overlay
when building packages with Poudriere. In my case, I'm using FreeBSD 14-STABLE
(stable/14-13952fbca).
I actually stopped using ports-mgmt/sccache-overlay because it got to the point
where it didn't work more often than it did. Then, a few months ago, I decided
to start using it again on a whim and it worked reliably for me. Then,
starting a few weeks ago, it has reverted to the behaviour you describe above.
It is not as bad right now as it got when I quit using it. Now, sometimes it
will fail, but it will succeed when re-running a "poudriere bulk" run.
I'd love it to go back to when it was working 100% of the time.
Cheers,
Paul.
Re: CVE-2024-3094: malicious code in xz 5.6.0 and xz 5.6.1
On 04-04-24 05:49, FreeBSD User wrote: Hello, I just stumbled over this CVE regarding xz 5.6.0 and 5.6.1: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094 FreeBSD starting with 14-STABLE seems to use xz 5.6.0, but my limited skills do not allow me to judge whether the described exploit mechanism also works on FreeBSD. RedHat already sent out a warning, the workaround is to move back towards an older variant. I have to report to my superiors (we're using 14-STABLE and CURRENT and I do so in private), so I would like to welcome any comment on that. No it does not affect FreeBSD. The autoconf script checks that it is running in a RedHat or Debian package build environment before trying to proceed. There are also checks for GCC and binutils ld.bfd. And I'm not sure that the payload (a precompiled Linux object file) would work with FreeBSD and /lib/libelf.so.2. See https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 A+ Paul
Re: libc/libsys split coming soon
On 05-02-24 17:02, Brooks Davis wrote:
Could you do a quick test with an exe linked to libsys but not libc running
under Valgrind memcheck, please?
Could you suggest a more concrete example?
This little example seems to be OK
void _start(void)
{
_exit(0);
}
However I do see quite a few new testcase failures. Some are libsys
related and fairly unimportant. There are also a few more serious issues
that I'm still investigating, not necessarily anything to do with libsys.
A+
Paul
Re: libc/libsys split coming soon
Hi > On 5 Feb 2024, at 17:02, Brooks Davis wrote: > > >>> 2. It simplifies the implementation of restrictions on system calls such >>> as those implemented by OpenBSD's msyscall(2) >>> (https://man.openbsd.org/msyscall.2). >> >> That's one to ignore for tools that make syscalls outside of the libc memory >> mapping. > > Should someone implement msyscall(2) there will certainly be an opt out > mechanism along the usual lines that uses elfctl and procctl. I was thinking more of simply not passing on such syscalls. > >>> 3. It allows language runtimes to link with libsys for system call >>> implementations without requiring libc. >> >> I see that pagesize is on the list of functions that are moving. There are a >> couple of other functions that might cause me problems if libc isn't linked. >> >> Could you do a quick test with an exe linked to libsys but not libc running >> under Valgrind memcheck, please? > > Could you suggest a more concrete example? I don’t think that it really matters. Just an empty main(). The important thing would be linking to libsys and not libc. A+ Paul
Re: libc/libsys split coming soon
On 02/02/2024 23:31, Brooks Davis wrote: TL;DR: The implementation of system calls is moving to a seperate library (libsys). No changes are required to existing software (except to ensure that libsys is present when building custom disk images). Code:https://github.com/freebsd/freebsd-src/pull/908 After nearly a decade of intermittent work, I'm about to land a series of patches which moves system calls, vdso support, and libc's parsing of the ELF auxiliary argument vector into a separate library (libsys). I plan to do this early next week (February 5th). This change serves three primary purposes: 1. It's easier to completely replace system call implementations for tracing or compartmentalization purposes. Will that affect code that makes syscalls without currently linking to libc? 2. It simplifies the implementation of restrictions on system calls such as those implemented by OpenBSD's msyscall(2) (https://man.openbsd.org/msyscall.2). That's one to ignore for tools that make syscalls outside of the libc memory mapping. 3. It allows language runtimes to link with libsys for system call implementations without requiring libc. I see that pagesize is on the list of functions that are moving. There are a couple of other functions that might cause me problems if libc isn't linked. Could you do a quick test with an exe linked to libsys but not libc running under Valgrind memcheck, please? A+ Paul
Re: byteswap.h not found on 12 and 13
A modern and standard solution is std::byteswap. https://en.cppreference.com/w/cpp/numeric/byteswap According to this https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B23_library_features you will need llvm 14 for that. A+ Paul
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
On Feb 27, 2023, at 2:57 PM, Dimitry Andric wrote: > On 27 Feb 2023, at 19:19, FreeBSD User wrote: >> >> Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 >> main-n261147-b8bb73ab724b: Sun Feb 26 >> 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git stable/13). >> >> Building an appliance based on 13-STABLE sources, a customized kernel via >> nanoBSD, since a >> couple of weeks for now building the sources fails in kernel sources: >> >> [...] >> --- modules-all --- >> --- all_subdir_an --- >> /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1: >> error: a >> function definition without a prototype is deprecated in all versions of C >> and is not >> supported in C2x [-Werror,-Wdeprecated-non-prototype] >> [..] >> >> Disabling all wireless options in the kernel config starts dropping errors >> of a similar kind >> on other kernel places. >> >> Compiling on FBSD 13-STABLE seems to be all right. >> >> Can this be fixed. please? What causes the error and how can this be >> resolved if the subtree >> of FreeBSD's sources is a submodule? > > Not sure what you mean with "subtree is a submodule", but this is likely > caused by skipping the cross-tools stage somehow. Do you have any > specific make.conf or src.conf settings for that? I got bitten by this recently. In my case, it was Poudriere (running on 14-CURRENT) trying to build a 13-STABLE jail. The Poudriere jail's "src.conf" was taken from the actual system for which Poudriere builds packages. It had (amongst others) these two options: WITH_SYSTEM_COMPILER=yes WITHOUT_CROSS_COMPILER=yes When I commented these out in the jail-src.conf Poudriere file the jail built correctly. I figure the system built fine because its system compiler is LLVM 14.x. The Poudriere system compiler is LLVM 15.x, which has the breaking change wrt. old-style prototypes. Cheers, Paul.
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
On 27-02-23 19:19, FreeBSD User wrote: Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 main-n261147-b8bb73ab724b: Sun Feb 26 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git stable/13). Building an appliance based on 13-STABLE sources, a customized kernel via nanoBSD, since a couple of weeks for now building the sources fails in kernel sources: [...] --- modules-all --- --- all_subdir_an --- /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] [..] You need to either fix the C code or find someone else that can fix it.* This is code that ensures that function calls correctly match function definitions using the high tech method of "cross your fingers and hope that it works". This was "fixed" by ANSI C going on for 35 years ago. Ancient code like this is probably safe enough - the finger crossing seems to have worked for a long time. It's no wonder people are clamouring to only use safe languages like Rust for new projects. A+ Paul * well maybe there is a compiler switch like -Wno-sane-person-would-do-this
Re: 14.0-CURRENT panic on boot, i386 VirtualBox client
On 04-01-23 11:24, Konstantin Belousov wrote: On Tue, Jan 03, 2023 at 11:38:55AM +0100, Floyd, Paul wrote: On 30/12/2022 01:54, Konstantin Belousov wrote: The backtrace is needed to make a further analysis. Any suggestions for getting a backtrace? I get the panic booting either the installer ISO or the VM image, both in VirtualBox. It should be there right after the panic message. No idea how to take the virtual screen snapshot under VB. Also it might be easier if you configure serial console and catch its output outside VB, but again I have no idea how to do that. You can connect the vbox vm serial output to a hist pipe. Here is the start of the panics smist: found supported isa bridge Intel PIIX4 ISA bridge panic: td 0x1d94840 stack 0x2424ee8 not in kstack VA 0x242 4 cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self_wrapper(0,1d94840,4,2424000,9,...) at db_trace_self_wrapper+0x28/frame 0x2424e9c vpanic(1491c57,2424ed8,2424ed8,2424f9c,1415b35,...) at vpanic+0xf4/frame 0x2424eb8 panic(1491c57,1d94840,2424ee8,242,4,...) at panic+0x14/frame 0x2424ecc trap(2424fa8,0,0,0,0,...) at trap+0x975/frame 0x2424f9c calltrap() at 0xffc0321f/frame 0x2424f9c --- trap 0x9, eip = 0xa02, esp = 0xffe, ebp = 0 --- KDB: enter: panic panic: td 0x1d94840 stack 0x2424d90 not in kstack VA 0x242 4 cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self_wrapper(0,1d94840,4,2424000,3,...) at db_trace_self_wrapper+0x28/frame 0x2424d44 vpanic(1491c57,2424d80,2424d80,2424e48,1415b35,...) at vpanic+0xf4/frame 0x2424d60 panic(1491c57,1d94840,2424d90,242,4,...) at panic+0x14/frame 0x2424d74 trap(2424e54,8,28,28,100,...) at trap+0x975/frame 0x2424e48 calltrap() at 0xffc0321f/frame 0x2424e48 --- trap 0x3, eip = 0x1042444, esp = 0x2424e94, ebp = 0x2424e94 --- kdb_enter(1527748,1527748) at kdb_enter+0x34/frame 0x2424e94 vpanic(1491c57,2424ed8,2424ed8,2424f9c,1415b35,...) at vpanic+0x11f/frame 0x2424eb8 panic(1491c57,1d94840,2424ee8,242,4,...) at panic+0x14/frame 0x2424ecc trap(2424fa8,0,0,0,0,...) at trap+0x975/frame 0x2424f9c calltrap() at 0xffc0321f/frame 0x2424f9c
Re: 14.0-CURRENT panic on boot, i386 VirtualBox client
On 30/12/2022 01:54, Konstantin Belousov wrote: The backtrace is needed to make a further analysis. Any suggestions for getting a backtrace? I get the panic booting either the installer ISO or the VM image, both in VirtualBox. A+ Paul
Re: 14.0-CURRENT panic on boot, i386 VirtualBox client
On 28-12-22 18:12, Ronald Klop wrote: I've had success to capture errors by recording the screen with my phone and playing back on slow speed. Another option might be to enable serial port for the console of the guest and capture the output. But I don't know if the default ISO uses that and how hard it is to configure VirtualBox to do that properly. Hi I have used my phone before, and I tried that. The last message with verbose turned on is isa_probe_children: probing PnP devices smist: found supported isa bridge Intel PIX4 ISA bridge panic: td 0x1d94840 stack 0x2424ee8 not in kstack VA 0x242 4 A+ Paul
Re: 14.0-CURRENT panic on boot, i386 VirtualBox client
On 28-12-22 18:05, Graham Perrin wrote: If the guest has more than CPU, try reducing to one. A step further: try booting the guest in safe mode. Neither of those changed anything (I was using 2 CPUs) A+ Paul
14.0-CURRENT panic on boot, i386 VirtualBox client
Hi For quite a few weeks I've been unable to boot 14.0-CURRENT i386 in a VirtualBox VM. I've tried both booting from iso image and the vmdk image. I get a kernel panic The host is running 13.1-RELEASE-p3 amd64 No problems with 14.0-CURRENT amd64 guests. I haven't been able to see the last message before the panic as it scrolls past too quickly. Any suggestions for a working either how to get more info or what vbox settings to use? A+ Paul
Re: SAMBA 416-4.16.6 ad GNOME together is impossible :(
On Nov 6, 2022, at 9:20 AM, wrote: > I try to get FreeBSD14 current running with both > - GNOME > - SAMBA > That seems to be impossible ☹ GNOME and SAMBA416 seems to be conflicting ! > I need SAMBA416 since SAMBA413 is simply not working :( > > Installing SAMBA does remove GNOME components and vice versa. > > How to work around this !!?? > So, that is a squeeze which urgently need repair IMHO > > Louis > > > pkg install samba416-4.16.6 > Message from samba416-4.16.6 > [1/4] Deinstalling gnome-shell-42.4_1... > [1/4] Deleting files for gnome-shell-42.4_1: 100% > [2/4] Deinstalling gnome-control-center-43.0... > [2/4] Deleting files for gnome-control-center-43.0: 100% > [3/4] Deinstalling samba413-4.13.17_4... > [3/4] Deleting files for samba413-4.13.17_4: 100% > [4/4] Installing samba416-4.16.6... > [4/4] Extracting samba416-4.16.6: 100% > > And then I have a fatal GNOME problem, and I have to install GNOME shell > Nov 6 12:29:20 SENIOR pkg[1897]: samba416-4.16.6 deinstalled > Nov 6 12:29:21 SENIOR pkg[1897]: samba413-4.13.17_4 installed > Nov 6 12:29:21 SENIOR pkg[1897]: gnome-control-center-43.0 installed > Nov 6 12:29:21 SENIOR pkg[1897]: gnome-shell-42.4_1 installed > > SAMBA and GNOME are both working ….. apart from each other. > Where SAMBA is not yet 100% ok e.g. it indicates that the config is not ok > where testparm says it is ok I am not using GNOME, but I am using Samba 4.16 and it coexists with other ports for me. I suspect the problem is that GNOME is being built against the current default for Samba (4.13) and so GNOME has the 4.13 version as a dependency. Samba 4.16 and 4.13 conflict against each other, so when you try and install Samba 4.16 it will uninstall Samba 4.13 (and GNOME, which depends upon it). Conversely, if you install GNOME it will uninstall Samba 4.16 to make way for its Samba 4.13 dependency. The way to fix this is to have your ports build against a common default version of Samba. In my case, I build ports locally using Poudriere and added "samba=4.16" to the "DEFAULT_VERSIONS" definition in make.conf for that Poudriere ports jail. So, any ports that build against Samba will use Samba 4.16 as a dependency, not 4.13. If you are using FreeBSD repositories, you might have to wait for Samba to switch to 4.16 in /usr/ports/Mk/bsd.default-versions.mk before GNOME/Samba ports shake out the way you like. Cheers, Paul.
Re: Good practices with bectl
On Sep 20, 2022, at 6:19 PM, Alan Somers wrote:
> On Tue, Sep 20, 2022 at 4:14 PM Nuno Teixeira wrote:
>>
>> Hello to all,
>>
>> I will use becl for the first time for current upgrades.
>> Just to check that I'm thinking correctly:
>>
>> Create a test environment for upgrade:
>>> bectl create -r test (should I use '-r'?)
>> Activate test:
>>> bectl activate test
>>> reboot
>> ...
>>> upgrade OS on test
>>> reboot
>> ...
>> if a problem happens, reboot default from BE loader
>> ---
>> if everything fine destroy default and rename test to default
>>> bectl destroy -o default
>>> bectl rename test default
>> repeat on next upgrade
>>
>> Don't know if a faster way exists with chroot or bectl jail...
>>
>> Any hints appreciated.
>>
>> Thanks,
>> --
>> Nuno Teixeira
>> FreeBSD Committer (ports)
>
> I don't think you need to use "-r". Also, you're forgetting one of
> the best things about boot environments: you can upgrade them even
> when not booted into them. That's faster than upgrading the running
> BE. Here is the procedure I use:
>
> RELEASE=Whatever
> sudo bectl create ${RELEASE}
> sudo bectl mount ${RELEASE}
> BASEDIR=/tmp/be_mount.# Use mount point returned by bectl mount
> sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update
> upgrade -r ${RELEASE}
> sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
> # Ignore admonitions to reboot, since we're using a boot environment
> sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
> sudo bectl activate ${RELEASE}
> sudo reboot
>
> This general procedure works just as well if you're upgrading from source,
> too.
>
> sudo make DESTDIR=${BASEDIR} installworld
> sudo mergemaster -m $PWD -D $BASEDIR -U
There's even a handy tool in /usr/src/tools/build that can be used as a wrapper
to install a SRC build into a new boot environment. It's
/usr/src/tools/build/beinstall.sh (see man beinstall(8) for details). It will
create a new boot environment from a source build, run etcupdate and so forth,
and even mark the new boot environment as the one to be active on reboot. All
you need to do is reboot. I've been using it for source upgrades for a while
now without problems. The best thing, for me, is it cuts out all that time
doing "make installworld" and etcupdate in single user mode, thus minimising
downtime.
Cheers,
Paul.
Re: Cross-compile worked, cross-install not so much ...
On Apr 25, 2022, at 3:26 PM, Patrick M. Hausen wrote: > Hi, > >> Am 25.04.2022 um 21:18 schrieb Brooks Davis : >> Cross install is not supported. As you have seen, certain tools are >> bootstrapped on the build host and used during the install process. You >> might be able to get away with nuking >> /usr/obj/usr/src/arm64.aarch64/tmp/legacy (or maybe tmp) and then >> running `make toolchain` to build native versions of those tools. > > that comes as a big surprise and disappointment. What is the point of > cross-compiling, then? > How to update a small slow embedded platform? At least as far back as July 2016 I kept my FreeBSD/arm systems updated by cross-building on a FreeBSD/amd64 system and using PkgBase to update the OS on the FreeBSD/arm systems: https://lists.freebsd.org/pipermail/freebsd-arm/2016-July/01.html This worked well for me, at least until I stopped running FreeBSD on my ARM systems. I don't know whether it still works. Cheers, Paul.
Re: advice sought: workflow with -CURRENT and amd GPU [Re: -CURRENT hangs since at least 2022-04-04]
On Apr 19, 2022, at 4:49 AM, Michael Schuster wrote: > Hi, > > I'm highjacking and re-purposing the previous thread, I hope that's OK > (I did change the subject ;-)) - I'm keeping some of the previous > contents for reference. > > I have similar HW to OP (Ryzen 7 4700 w. Renoir Graphics), and have > been using a similar approach to keep the machine up to date - or so I > suspect. Still, after a while (several months), I end up with one or > more of these: > - I get some sort of panic in DRM (at startup or, currently, at shutdown) > - when I boot into to a previous BE to attempt a fix and then again > reboot into the current one, I get tons of messages like this > "... kernel: KLD iic.ko: depends on kernel - not available or > version mismatch > ... kernel: linker_load_file: /boot/kernel/iic.ko - unsupported file > type" > and computer refuses to accept input (let alone start X) > > and some others I don't recall right now. > > Before I ask for advice (see below), let me explain the approaches > I've taken so far. I install with ZFS from the beginning, current boot > env is "N". These are outlines, not exact commands: > > I) never touch the current BE, always update a new one: > 1) given current BE N, I create a new BE N+1 and mount it on /mnt, > 2) 'cd /usr/src; git pull; sudo make DESTDIR=/mnt ... (build, install, etc)' > 3) 'cd usr/ports/graphics/drm-devel-kmod; sudo make DESTDIR=/mnt install' > 4) beadm activate BE N+1; reboot > > II) keep a "new" BE as backup/fallback, update current BE: > 1) given current BE N, I create a new BE N+1 (mounting not required) > (this is the intended 'fallback') > 2) 'cd /usr/src; git pull"; then "make" as described in the Handbook > "24.6. Updating FreeBSD from Source" > 3) 'cd usr/ports/graphics/drm-devel-kmod; sudo make install' > 4) reboot > > in both scenarios(sp?), I do "pkg update; pkg upgrade" from time to > time (also following the resp. approach shown above). > > I suspect that I'm missing something fundamental in my approaches - > does anyone have a (for them) foolproof approach along these lines, or > can someone show me what I'm missing in either of mine (in private, if > you prefer)? I don't know whether you're missing anything, but I wanted to mention I recently found a tool useful in helping my own BE-based source upgrades: /usr/src/tools/build/beinstall.sh I've found it helps with the build/upgrade steps. See man beinstall(8) for details. Cheers, Paul.
Re: /etc/rc: ERROR: /etc/rc: no interface specified
On Feb 24, 2021, at 11:18 AM, Jung-uk Kim wrote: > On 21. 2. 24., Paul Mather wrote: >> I have two systems on which I run -CURRENT. I updated them yesterday to the >> following: FreeBSD 14.0-CURRENT #1 main-n245033-6ab923cbca87: Tue Feb 23 >> 21:29:31 EST 2021. Both use the stock GENERIC-NODEBUG kernel. >> >> Since the update, the systems do not boot up correctly. I get this late in >> the boot sequence: >> >> = >> Enabling pf. >> Updating /var/run/os-release done. >> Creating and/or trimming log files. >> Clearing /tmp (X related). >> Updating motd:. >> Starting syslogd. >> Security policy loaded: MAC/ntpd (mac_ntpd) >> Starting ntpd. >> Starting powerd. >> Mounting late filesystems:. >> Configuring vt: blanktime. >> Performing sanity check on sshd configuration. >> Starting sshd. >> Starting cron. >> Starting background file system checks in 60 seconds. >> /etc/rc: ERROR: /etc/rc: no interface specified >> Usage: /etc/rc [0x00|0x01] >> WARNING: attempt to domain_add(bluetooth) after domainfinalize() >> /etc/rc: ERROR: Unsupported device: >> = >> >> The last line is the final console output prior to the console login prompt. >> >> As well as the error during boot, none of the local services (installed via >> pkg with startup scripts under /usr/local/etc/rc.d) start up. >> >> Also, I can't be certain this is new, but I just noticed it: I get a bunch >> of extra KLDs loaded: >> >> = >> 324 0x82e95000 25a8 ng_bluetooth.ko >> 331 0x82e98000 a238 ng_hci.ko >> 343 0x82ea3000 aac8 netgraph.ko >> 351 0x82eae000 e250 ng_l2cap.ko >> 361 0x82ebd0001be48 ng_btsocket.ko >> = >> >> I don't know why it's loading bluetooth-related kernel modules as both >> systems are rack-mounted servers with no bluetooth hardware in them to my >> knowledge. >> >> I've looked in /usr/src/UPDATING for any recent note related to this but >> can't find anything. My last update (circa 5th February 2021) worked fine. > > The following commit fixed the problem for me. > > https://cgit.freebsd.org/src/commit/?id=6e822e99570fdf4c564be04840a054bccc070222 > > Jung-uk Kim Thank you. That fixed the problem for me, too. Cheers, Paul. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
/etc/rc: ERROR: /etc/rc: no interface specified
I have two systems on which I run -CURRENT. I updated them yesterday to the following: FreeBSD 14.0-CURRENT #1 main-n245033-6ab923cbca87: Tue Feb 23 21:29:31 EST 2021. Both use the stock GENERIC-NODEBUG kernel. Since the update, the systems do not boot up correctly. I get this late in the boot sequence: = Enabling pf. Updating /var/run/os-release done. Creating and/or trimming log files. Clearing /tmp (X related). Updating motd:. Starting syslogd. Security policy loaded: MAC/ntpd (mac_ntpd) Starting ntpd. Starting powerd. Mounting late filesystems:. Configuring vt: blanktime. Performing sanity check on sshd configuration. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. /etc/rc: ERROR: /etc/rc: no interface specified Usage: /etc/rc [0x00|0x01] WARNING: attempt to domain_add(bluetooth) after domainfinalize() /etc/rc: ERROR: Unsupported device: = The last line is the final console output prior to the console login prompt. As well as the error during boot, none of the local services (installed via pkg with startup scripts under /usr/local/etc/rc.d) start up. Also, I can't be certain this is new, but I just noticed it: I get a bunch of extra KLDs loaded: = 324 0x82e95000 25a8 ng_bluetooth.ko 331 0x82e98000 a238 ng_hci.ko 343 0x82ea3000 aac8 netgraph.ko 351 0x82eae000 e250 ng_l2cap.ko 361 0x82ebd0001be48 ng_btsocket.ko = I don't know why it's loading bluetooth-related kernel modules as both systems are rack-mounted servers with no bluetooth hardware in them to my knowledge. I've looked in /usr/src/UPDATING for any recent note related to this but can't find anything. My last update (circa 5th February 2021) worked fine. Cheers, Paul. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Dec 22, 2020, at 1:39 PM, bob prohaska wrote: > On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote: >> >> The FreeBSD project will be moving it's source repo from subversion to git >> starting this this weekend. The docs repo was moved 2 weeks ago. The ports >> repo will move at the end of March, 2021 due to timing issues. >> > > Is there some way to obtain git on a Pi2B running > 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365692 > without installing the ports tree? I expected > to find git in base, but it isn't there. > > Can it be found under another package name? > > Thanks for reading, and any guidance! Git (and git-lite) are available only in ports/packages at the moment. For those wanting to track src via git, you need to install it from there. I believe any plans for a git-compatible tool in base would be derived from Got (devel/got) due to licensing. But, unless I'm mistaken, there is no need to install git to be able to continue to get copies of src. It's only developers who need to commit changes to src that need to switch over to git in the near future. Just as FreeBSD's src has been made available as a Git repository from the canonical Subversion repo (e.g., on GitHub), I'm sure the reverse will be true for some time and you'll be able to continue to get src updates via Subversion. That would surely be the case for existing releases (otherwise it would be a huge POLA violation). I track NetBSD src via Git, even though that project currently officially uses CVS. Cheers, Paul. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm / drm2 removal in 12
I think you can pay XinuOS to support FreeBSD in a LTS situation. It is just like linux where you have to pay Red Hat, Suse, etc. They break things even with point releases. Suse majorly screwed with video drivers back in the 9.x series. Totally broke major release. Their answer then was pay us or re-install bare metal and figure it out on your own. Other wise linux has always been, you get what you get for free. BSD is the same. If you are lucky some one like red hat, suse, XinuOS will be supporting and make their notes public, otherwise the OSS model doesn't include anything more than community support for what ever that is worth. I just upgraded a system from FreeBSD 9.x to 12.x, it took 2 weeks and several incremental upgrades sometimes to multiple point releases with in a major release. There is nothing really for free. On 8/25/2018 7:47 PM, blubee blubeeme wrote: On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg wrote: On Sun, Aug 26, 2018 at 00:25 blubee blubeeme wrote: On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav wrote: blubee blubeeme writes: True on both points my tone is just a reflection of attitudes of the individuals that I am currently addressing. Well, congratulations on alienating absolutely everybody you have interacted with on this topic. Some people enjoy making contributions w/o waving a banner constantly wanting acknowledgement, a pat on the head and good job from everyone. The only person I see constantly craving attention and validation from others here is you. How far will core FreeBSD bend over backwards to accommodate these devs. The core team does not decide what goes into the tree or not. The developers do. This is the beauty of an open source project, we bring the best to the table, [...] Who exactly is “we” here? You are not a member of the project, you do not speak for the project, and after seeing how you treat our fellow developers, our friends, most of us want nothing to do with you. If can't live with that, I'm sure you can figure out how to install Linux. DES -- Dag-Erling Smørgrav - d...@des.no Some on here want to attack my personality because they think that I am abrasive, fine but that's not the issue. Some claim that they run the code and it works wonderful for them with no issues, again that's lovely keep on running the code. Nevertheless let me restate the point that you guys are all seeming to miss; If you can go out and build custom kernels with custom options and out of mainline tree that's fine, keep doing that until you have something that's production ready and as easy to install as the rest of FreeBSD system. The graphics stack on FreeBSD is pretty bad as it stands but all the documentation currently out there is about using it as it stands now. Why do you need to rip out the current graphics drivers which will break systems for the vast majority of silent users who will not complain and just leave? A little background Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update their phones to the latest android version? It's because the Linux kernel is such a mess they know it's a waste of resources to try. You should not have to ask how or why I know this but if it's unclear I was in the field. --- Now you guys who claim to only be hobbyist doing this in their free time expect to maintain this when those companies with all their resources cannot? Those 30,000 ports many of them bring bugs with them because of this Linuxkpi stuff. Just recently there was a user who said google earth doesn't work the answer was it doesn't work and that's that. They get ported and then get dropped so while the ports tree is large, if you actually try to use some of those programs they are broken, maintenance hell for the developers and confusion for the users. Johannes Lundberg I know that you are one of the main working on this linuxkpi stuff but anyone else is free to answer as well. Let's have an open discussion why do you need to remove the current graphics stack to continue with your work? This has been discussed over and over on the mailing list and I don’t think anyone wants to do it over again so please feel free to search the archives. You’re misinformed. We are not removing anything for anyone. We are moving it to ports. “pkg install drm-legacy-kmod” will install those drivers for you that were earlier in base. I thought we have been clear about this but maybe we haven’t been clear enough. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org " Have you or anyone working on this drm-legacy-kmod stuff done any testings of how this will affect current users? 1) Take a [test] system with the current graphics stack installed and working. 2) Apply your patches to remove the drm from base
Re: BBB (cpsw(4)) seems to be broken in the latest 11-current
On Jun 20, 2016, at 6:33 PM, Keith White <kwh...@site.uottawa.ca> wrote: > On Mon, 20 Jun 2016, Luiz Otavio O Souza wrote: > >> On Sun, Jun 19, 2016 at 1:11 AM, Maxim Sobolev wrote: >>> Jim, some update from here. Running r283287 of the driver, I still see the >>> same "watchdog timeout" messages, but they do not lead to the interface >>> lockout. The traffic resumes momentarily. Which is probably why I never paid >>> much attention to those warnings before. Therefore, I suspect that the new >>> MAC code does not deal with watchdog-triggered interface reset as good as >>> the old code. Does it give you any ideas about what could be wrong there by >>> any chance? >> >> >> Hi Maxim, >> >> My recent changes contributed somehow to expose the bug more frequently. >> >> There was a condition in tx packet reclamation where we aren't >> restarting the tx queue in one of the possible stall conditions. >> >> Please try the attached patch and let me know if it works for you. >> >> Luiz > > Your patch fixes the problem for me. Thanks! > > FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302028M: Mon Jun 20 > 18:19:55 EDT 2016 > kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE-LOCAL arm armv6 > > ...keith The patch also fixes the problem for me. FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #2 r302030M: Tue Jun 21 10:20:59 EDT 2016 pmather@beaglebone:/usr/obj/usr/src/sys/BEAGLEBONE-NO_WITNESS arm Cheers, Paul. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: BBB (cpsw(4)) seems to be broken in the latest 11-current
On Jun 18, 2016, at 2:50 AM, Maxim Sobolev <sobo...@freebsd.org> wrote: > Updated my BBB to the latest -current, immediately got this while trying to > make world over ssh console: > > 06:02:17 CPSW watchdog cpswss0: watchdog timeout > cpswss0: Unable to cleanly shutdown transmitter > > Interface seems to be locked after that, no traffic comes in or out. > > This is: > > FreeBSD 11.0-ALPHA3 #1 ba7edef(tps65217x)-dirty: Fri Jun 17 16:22:07 PDT > 2016, svn revision 301898 > > The previous version that was rock-solid was: > > FreeBSD 11.0-CURRENT #0 9d390ee(tps65217x)-dirty: Mon Jul 6 19:31:30 PDT > 2015, svn revision 284878 > > I've been running buildworlds for literally days on that board, because > it's how long it takes to build on that hardware. :) > > I'll run it again and see if the issue re-appears. > > If anyone seen this or if it's known issue please let me know. I have experienced this problem recently, too, after updating to 11.0-ALPHA3. I get the watchdog timeout messages you give above when trying to buildworld with /usr/src and /usr/obj mounted via NFS. My last successful build that did not have this problem is this one: FreeBSD beaglebone 11.0-ALPHA2 FreeBSD 11.0-ALPHA2 #0 r301779: Mon Jun 13 01:30:05 EDT 2016 pmather@beaglebone:/usr/obj/usr/src/sys/BEAGLEBONE-NO_WITNESS arm The build where this started happening for me is this one: FreeBSD 11.0-ALPHA3 #0 r301876: Wed Jun 15 14:23:28 EDT 2016 That's just two days apart. Maybe that might help track down the potential revision that caused the problem. I've not been able to buildworld via NFS since the problem began, so I've reverted back to the r301779 kernel for now. Cheers, Paul. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Apr 20, 2016, at 10:54 AM, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote: >> A packaged base is just another way of describing the state of the >> system. People on mailing lists will still be able to help people >> fix their problems, but they'll just use different information to >> pinpoint the precise components affected. > > How identify this systems? By 800-line lists of package versions? In my experience, troubleshooting usually proceeds from the description of the symptoms. So, if someone says, "I just updated and Sendmail has stopped sending e-mails," or "I just updated and I can no longer SSH into my system," then the logical question is to ask what versions of the packages they're running that pertain to those binaries. In other words, you start at the symptom and work outwards from there. In my experience, it's not necessary to have an exact inventory of a system to be able to solve a problem with it. A tool like pkg makes it easy to know which package is associated with a given file and also which packages that package depends upon and which are dependencies of it. So, pkg makes it relatively painless to zoom in or out from a given symptom (i.e., binary or library that might have changed). I don't believe this is possible in the current FreeBSD setup. This is a huge gain in functionality. Cheers, Paul. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
> Message: 20 > Date: Wed, 20 Apr 2016 12:48:06 +0300 > From: Slawa Olhovchenkov <s...@zxy.spb.ru> > To: Dan Partelly <dan_parte...@rdsor.ro> > Cc: David Chisnall <thera...@freebsd.org>, Julian Elischer > <jul...@freebsd.org>, Nathan Whitehorn <nwhiteh...@freebsd.org>, > freebsd-current@freebsd.org > Subject: Re: [CFT] packaging the base system with pkg(8) > Message-ID: <20160420094806.gj6...@zxy.spb.ru> > Content-Type: text/plain; charset=utf-8 > > On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote: > >> IMO, the number of packages per-se is not a problem as long as you >> can manage them without arcane commands, aliases, pipe - filters, >> or scripts. (they all have their place, but less , the better) My >> point is that I don't really want to keep on my head a Unix hacker >> hat. I (and presumably many other humans ) like simple things,which >> allow me to type a short command (preferably the whole system should >> be simple enough to be explained in one-two pages in handbook) , >> wait for completion, and get on with my life. > > Yes and no. > While number of packages don't see outside internal -- this is > irrelevant. > After possibility of update individual package -- nuber of packages is > impotant. > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > 11.0? 11.1-RC3? How you name it? How identify it for take support on > forum or mail list? > > How name system, updated all w/o compiler? or only some services? > Currently we have simple naming: > > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > This is shortly and clearly identify system to anyone. Superficially, it does, but in reality it doesn't. I can grab the source for 10.3-RELEASE and then add a lot of WITH_* and WITHOUT_* settings in /etc/src.conf and build a kernel and world and end up with a system that is missing a lot of functionality that is ordinarily present with an empty /etc/src.conf. That missing functionality could be the reason for a problem I am having with my "10.3-RELEASE" system. That is the reality of FreeBSD *now* and I still am able to get help on FreeBSD mailing lists when I have problems. The case of a moving target is truer of those who choose to run -STABLE or -CURRENT. If I say I'm running 10.3-STABLE three months from now, what version of the code base am I actually running? Sure, now we have the SVN revision number to help pinpoint the version of the code being run (setting aside the effects of /etc/src.conf), but back in the days when FreeBSD was in CVS we didn't have that nicety and yet people were still able to get help with problems running -STABLE or -CURRENT on the mailing lists. A packaged base is just another way of describing the state of the system. People on mailing lists will still be able to help people fix their problems, but they'll just use different information to pinpoint the precise components affected. Arguably, a packaged base will make it easier to help people, because it makes more explicit the dependencies of different parts of the system. It's been my experience that the interactions and impact of the various /etc/src.conf settings are not entirely well known, at least to end-users. Cheers, Paul. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: Kernel trap when booting inside VirtualBox
On Wed, Apr 12, 2016 at 11:01PM, Paul Wootton wrote: >On Tue, Apr 12, 2016 at 02:02PM, Paul Wootton wrote: > >With the help of Konstantin, I have got a proper disassembly. > >I have recompiled a few times so my new panic is >instruction pointer = 0x20:0x80fed2d9 >stack pointer = 0x28:0x824d89c0 >frame pointer = 0x28:0x824d8a40 >code segment= base 0x0, Limit 0xf, type 0x1b >= DPL 0, pres 1, long 1, def32 0, gran 1 >Processor eflags= resume, IOPL = 0 >Current process = 0 (swapper) >[ thread pid 0 tid 10 ] >Stopped at native_lapic_setup+0x99: lesl%edx,%esp > >and a disassembly gives >0x80fed2d9 <native_lapic_setup+153>:(bad) 0x99 == 153 > >Now to figure out why I am making bad binaries. >Ive not seen any issues yet with the world, so its not as if every >binary I >make is bad I have found that having CPUTYPE?=native in /etc/make.conf was my issue. Commenting that line out (the only other line I have is KERNCONF) and now I can build a good kernel --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: Kernel trap when booting inside VirtualBox
On Tue, Apr 12, 2016 at 02:02PM, Paul Wootton wrote: >On Tue, Apr 12, 2016 at 08:56AM, Konstantin Belousov wrote: >>Anyway, please do 'kgdb kernel.debug' for your HEAD kernel, and >>send me the disassemble of the native_lapic_setup function. > >" >Dump of assembler code for function native_lapic_setup: >0x80fd1320 <native_lapic_setup+0>: add%al,(%rax) >0x80fd1322 <native_lapic_setup+2>: add%al,(%rax) >0x80fd1324 <native_lapic_setup+4>: add%al,(%rax) >0x80fd1326 <native_lapic_setup+6>: add%al,(%rax) >0x80fd1328 <native_lapic_setup+8>: add%al,(%rax) >... >... >0x80fd1880 <native_lapic_setup+1376>: add%al,(%rax) >0x80fd1882 <native_lapic_setup+1378>: add%al,(%rax) >0x80fd1884 <native_lapic_setup+1380>: add%al,(%rax) >0x80fd1886 <native_lapic_setup+1382>: add%al,(%rax) >End of assembler dump >" >Every line is the same instruction, add %al,(%rax) > >I downloaded an ISO of r294499 and that booted correctly inside VBox. >I SVNed down to r294499, compiled and that did not boot. Did a disassembley and it's the same as above. >I downloaded an ISO of r297692 and that booted correctly. > >So it's got to be either my kernel conf or my enviroment > >Im going to try and compile a generic kernel and see if that works With the help of Konstantin, I have got a proper disassembly. I have recompiled a few times so my new panic is instruction pointer = 0x20:0x80fed2d9 stack pointer = 0x28:0x824d89c0 frame pointer = 0x28:0x824d8a40 code segment= base 0x0, Limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 Processor eflags= resume, IOPL = 0 Current process = 0 (swapper) [ thread pid 0 tid 10 ] Stopped at native_lapic_setup+0x99: lesl%edx,%esp and a disassembly gives 0x80fed2d9 <native_lapic_setup+153>:(bad) 0x99 == 153 Now to figure out why I am making bad binaries. Ive not seen any issues yet with the world, so its not as if every binary I make is bad --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: Kernel trap when booting inside VirtualBox
On Tue, Apr 12, 2016 at 08:56AM, Konstantin Belousov wrote: >On Tue, Apr 12, 2016 at 07:14:47AM +0100, pa...@fisheyehq.com wrote: >> Hi, >> >> Has anyone else got an issue with running FreeBSD SVN r297810 inside a >> VirtualBox session? >> >> I installed 10.3, booting under EFI on my second harddrive (Windows in >> on the first drive). FreeBSD would boot correctly from UEFI boot or from >> inside VirtualBox. I SVNed up to head (r297810), compiled and installed >> it. >> It will now boot correctly from UEFI boot, but kernel traps very early >> on when booted from VirtualBox. >> >> As a side note, I am using booting from zfs. >> I am starting FreeBSD by calling boot1.efi from inside EFIShell (from >> both UEFI boot and VirtualBox) >> >> Has anyone else seen this? Is it my setup? >> >> real memory = 4831838208 (4608 MB) >> avail memory = 4096802816 (3907 MB) >> Event timer "LAPIC" quality 400 >> APIC APIC Table: >> Random: unblocking device. >> Loapic0 irqs 0-23 on motherboard Kernel trap 1 with >> interrupts disabled >> >> >> Fatal trap 1: privileged instruction fault while in kernel mode cpuid = >> 0: apic id = 00 >> instruction pointer = 0x20:0x80fed419 >> stack pointer = 0x28:0x824d9c00 >> frame pointer = 0x28:0x824d9c80 >> code segment= base 0x0, Limit 0xf, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> Processor eflags= resume, IOPL = 0 >> Current process = 0 (swapper) >> [ thread pid 0 tid 10 ] >> Stopped as native_lapic_setup+0x99: lesl%edx,%esp >> db>bt >> Tracing pis 0 tid 10 td 0x81d351b0 >> native_lapic_setup() at native_lapic_setup+0x99/frame 0x8249c80 >> apic_setup_io() at apic_setup_io+0x53/frame 0x824d9c90 >> mi_startup() at mi_startup+0x118/frame 0x824d9cb0 >> btext() at btext+0x2c >> db> >> >Was the panic text above trascribed from the screen manually ? > >Anyway, please do 'kgdb kernel.debug' for your HEAD kernel, and >send me the disassemble of the native_lapic_setup function. Yeah, I typed the panic out by hand " Dump of assembler code for function native_lapic_setup: 0x80fd1320 <native_lapic_setup+0>: add%al,(%rax) 0x80fd1322 <native_lapic_setup+2>: add%al,(%rax) 0x80fd1324 <native_lapic_setup+4>: add%al,(%rax) 0x80fd1326 <native_lapic_setup+6>: add%al,(%rax) 0x80fd1328 <native_lapic_setup+8>: add%al,(%rax) ... ... 0x80fd1880 <native_lapic_setup+1376>: add%al,(%rax) 0x80fd1882 <native_lapic_setup+1378>: add%al,(%rax) 0x80fd1884 <native_lapic_setup+1380>: add%al,(%rax) 0x80fd1886 <native_lapic_setup+1382>: add%al,(%rax) End of assembler dump " Every line is the same instruction, add %al,(%rax) I downloaded an ISO of r294499 and that booted correctly inside VBox. I SVNed down to r294499, compiled and that did not boot. Did a disassembley and it's the same as above. I downloaded an ISO of r297692 and that booted correctly. So it's got to be either my kernel conf or my enviroment Im going to try and compile a generic kernel and see if that works Paul --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
tzsetup - UTC user question
Since the default option for Select local or UTC clock changed from No to Yes, we are seeing many customers who incorrectly answer this question! This screws up things in our app because we store all data in UTC. A few observations... Most people don't know what CMOS clock is. Maybe change the wording to BIOS clock or Hardware Clock ?? The person doing the install may not know what the clock is currently set to, especially when installing in a VM. Perhaps the screen should display the current machine time so they can correctly answer the question. Why was the default changed from No to Yes ? Paul. -- Paul Koch | Founder, CEO AKIPS Network Monitor http://www.akips.com Brisbane, Australia ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
$DISPLAY not set
I have installed freeBSD have it running. I was trying to install MATE KDE4, but I'm getting an error. everytime I try to run exec startkde it logs me out with this message: $DISPLAY is not set or cannot connect to xserver echo $DISPLAY says DISPLAY: undefined variable I was using this guide to set everything up: https://cooltrainer.org/a-freebsd-desktop-howto/#with-radeon-intel-or-otherwise am I missing something? I do have an /etc/X11/xorg.conf, I did do the X -configure. -- Paul Cartwright Registered Linux User #367800 and new counter #561587 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: $DISPLAY not set
On 12/01/2014 01:41 PM, Lowell Gilbert wrote: am I missing something? Well, you're missing the FreeBSD documentation, which is a lot better than a random Google result. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11.html right, I should have followed that first.. Or you might want to try PCBSD (www.pcbsd.org) which will require a lot less understanding of what is going on (at the cost, as usual, of giving you a lot less choice, at least initially). no,no, I've used UNIX in the past, but it has been linux for the last 10 years.. just a little rusty.. The exec startkde is supposed to go in your .xinitrc file, in which case you would start X with the startx command. right, I understand the .xinitrc, but I wanted it to work first.. I do have an /etc/X11/xorg.conf, I did do the X -configure. Usually unnecessary, and not a great idea unless it is necessary. ok, I'll check out the freebsd pages, and I'll let you know. thanks! -- Paul Cartwright Registered Linux User #367800 and new counter #561587 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Aug 1, 2014, at 8:46, Mark Felder f...@freebsd.org wrote: I personally use pf for many reasons, spamd included. I don't think anyone out there is interested in forking spamd to play ball with ipfw so we would also be alienating these users who can't just change packet filters. Is there even an equivalent to pfsync for ipfw? I didn't think so, but I could be wrong... In the world of firewalls pf has been put on a quite a pedestal. OpenBSD pushed it hard and it marketed it well; people found it both powerful and easy to use which created a cult following and lots of word of mouth advertising. I find it hard to agree with removing pf from FreeBSD because of the existing userbase. If there was an experimental label on it I would find its removal easier to swallow. I have remained silent on this for two reasons: 1. I am a consumer of FreeBSD. I am a sysadmin, I am NOT a coder and *I* would not want any code that *I* wrote in the kernel of an OS that I was running. I know my limitations. So I could not contribute to the development of pf in FreeBSD 2. Where I use packet filters on a host, and that is not very much, I tend to use ipfilter because in those case my needs are simple. For heavy duty (read: gateway) filtering I use commercial firewalls like the Checkpoint 600 series. So the inclusion or exclusion of pf has no direct effect on me. Having said all that, the reason I use FreeBSD over other open source OSes right now is that it is, in my opinion, the most “grown up” option. I have never seen Linux as an Enterprise tier OS due to a number of basic design decisions made by Linus and those around him. Illumos is very good, but fairly narrow in both it’s hardware support and feature set. I never took a long hard look at the other BSDs as FreeBSD was recommended by a friend and I liked what I found, ESPECIALLY the documentation in the Handbook. I have read a lot of arguments on both sides of the pf in FreeBSD debate over the past weeks. Realistically I think what it comes down to is whether there is someone, a person, an individual with the necessary skill set and drive and desire (and that can be motivated by funding) to take ownership of it and run with it. If there is not, then I think pf in FreeBSD dies. No matter how many people want it to continue, no matter if it is best for FreeBSD for it to continue. Without someone to take ownership of it, then even if it continues it will not be top quality, and having something in FreeBSD that is not top quality would be a mistake (IMHO). -- Paul Kraus p...@kraus-haus.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH RFC] Disable save-entropy in jails
On Dec 24, 2013, at 12:44 PM, Xin Li delp...@delphij.net wrote: I think we shouldn't save entropy inside jails, as the data is not going to be used by rc script (pjd@126744). If there is no objections, I will commit this changeset on January 1, 2014. Even if it is not used by an rc script, it might be used by some userland program (running as root, of course) that knows about the directory and wants some fresh entropy for its own use. Is there a problem with saving the directory in jails? It certainly isn't taking up much space. --Paul Hoffman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Kernel build fail for generic on r256122 (if_cxgbe)
Details on pastebin: http://pastebin.com/raw.php?i=dNzL3yXR ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
9.1 - current migration problem
I have a newly installed 9.1 amd64 VM that I would like to update to
-current. I have pulled down head via svn:
svn co svn://svn.freebsd.org/base/head /usr/src
and am attempting to buildworld:
cd /usr/src
make buildworld
This build is failing during bootstrap-tools when building makewhatis or
mklocale. It seems that something is trying to use the '-l' option to
install, which is only present in FreeBSD 10.
Any ideas how to get around this issue?
Thanks,
Paul
# cd /usr/src
# make buildworld
.
.
.
=== bin/cat (obj,depend,all,install)
/usr/obj/usr/src/tmp/usr/src/bin/cat created for /usr/src/bin/cat
rm -f .depend
mkdep -f .depend -a-I/usr/obj/usr/src/tmp/legacy/usr/include
-std=gnu99 /usr/src/bin/cat/cat.c
echo cat: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a
.depend
cc -O2 -fno-strict-aliasing -pipe -std=gnu99
-I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/bin/cat/cat.c
${CTFCONVERT_CMD} expands to empty string
cc -O2 -fno-strict-aliasing -pipe -std=gnu99
-I/usr/obj/usr/src/tmp/legacy/usr/include -static
-L/usr/obj/usr/src/tmp/legacy/usr/lib -o cat cat.o -legacy
install -C -s -o root -g wheel -m 555 cat
/usr/obj/usr/src/tmp/legacy/bin/cat
=== usr.bin/lorder (obj,depend,all,install)
/usr/obj/usr/src/tmp/usr/src/usr.bin/lorder created for
/usr/src/usr.bin/lorder
install -C -o root -g wheel -m 555 /usr/src/usr.bin/lorder/lorder.sh
/usr/obj/usr/src/tmp/legacy/usr/bin/lorder
=== usr.bin/makewhatis (obj,depend,all,install)
/usr/obj/usr/src/tmp/usr/src/usr.bin/makewhatis created for
/usr/src/usr.bin/makewhatis
rm -f .depend
mkdep -f .depend -a-I/usr/obj/usr/src/tmp/legacy/usr/include
-std=gnu99 /usr/src/usr.bin/makewhatis/makewhatis.c
echo makewhatis: /usr/lib/libc.a /usr/lib/libz.a
/usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a .depend
cc -O2 -fno-strict-aliasing -pipe -std=gnu99
-I/usr/obj/usr/src/tmp/legacy/usr/include -c
/usr/src/usr.bin/makewhatis/makewhatis.c
${CTFCONVERT_CMD} expands to empty string
cc -O2 -fno-strict-aliasing -pipe -std=gnu99
-I/usr/obj/usr/src/tmp/legacy/usr/include -static
-L/usr/obj/usr/src/tmp/legacy/usr/lib -o makewhatis makewhatis.o -lz -legacy
install -C -s -o root -g wheel -m 555 makewhatis
/usr/obj/usr/src/tmp/legacy/usr/bin/makewhatis
install -C -o root -g wheel -m 555
/usr/src/usr.bin/makewhatis/makewhatis.local.sh
/usr/obj/usr/src/tmp/legacy/usr/libexec/makewhatis.local
/usr/obj/usr/src/tmp/legacy/usr/libexec/catman.local -
/usr/obj/usr/src/tmp/legacy/usr/libexec/makewhatis.local
install: illegal option -- l
usage: install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
[-o owner] file1 file2
install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
[-o owner] file1 ... fileN directory
install -d [-v] [-g group] [-m mode] [-o owner] directory ...
*** [_installlinks] Error code 64
Stop in /usr/src/usr.bin/makewhatis.
*** [bootstrap-tools] Error code 1
Stop in /usr/src.
*** [_bootstrap-tools] Error code 1
Stop in /usr/src.
*** [buildworld] Error code 1
Stop in /usr/src.
--
Paul Dokas dokas at dokas.name
==
Don Juan Matus: an enigma wrapped in mystery wrapped in a tortilla.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.1 - current migration problem
Thanks Dan! I was hoping that this would be something simple like this.
The entry in UPDATING that you are referring to is:
20130121:
Due to the use of the new -l option to install(1) during build
and install, you must take care not to directly set the INSTALL
make variable in your /etc/make.conf, /etc/src.conf, or on the
command line. If you with to use the -C flag for all installs
you may be able to add INSTALL+=-C to /etc/make.conf or
/etc/src.conf.
And I was setting INSTALL in /etc/make.conf
INSTALL= install -C
I've commented this out and am rebuilding again.
Thanks again!
Paul
On 05/12/13 09:35, Dan Mack wrote:
It's sound familiar; in /usr/src/UPDATING there is mention of this '-l'
issue. Search for 'install' in UPDATING and I think there is a
work-around.
Dan
On Sun, 12 May 2013, Paul Dokas wrote:
I have a newly installed 9.1 amd64 VM that I would like to update to
-current. I have pulled down head via svn:
svn co svn://svn.freebsd.org/base/head /usr/src
and am attempting to buildworld:
cd /usr/src
make buildworld
This build is failing during bootstrap-tools when building makewhatis or
mklocale. It seems that something is trying to use the '-l' option to
install, which is only present in FreeBSD 10.
Any ideas how to get around this issue?
Thanks,
Paul
# cd /usr/src
# make buildworld
.
.
.
=== bin/cat (obj,depend,all,install)
/usr/obj/usr/src/tmp/usr/src/bin/cat created for /usr/src/bin/cat
rm -f .depend
mkdep -f .depend -a-I/usr/obj/usr/src/tmp/legacy/usr/include
-std=gnu99 /usr/src/bin/cat/cat.c
echo cat: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a
.depend
cc -O2 -fno-strict-aliasing -pipe -std=gnu99
-I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/bin/cat/cat.c
${CTFCONVERT_CMD} expands to empty string
cc -O2 -fno-strict-aliasing -pipe -std=gnu99
-I/usr/obj/usr/src/tmp/legacy/usr/include -static
-L/usr/obj/usr/src/tmp/legacy/usr/lib -o cat cat.o -legacy
install -C -s -o root -g wheel -m 555 cat
/usr/obj/usr/src/tmp/legacy/bin/cat
=== usr.bin/lorder (obj,depend,all,install)
/usr/obj/usr/src/tmp/usr/src/usr.bin/lorder created for
/usr/src/usr.bin/lorder
install -C -o root -g wheel -m 555 /usr/src/usr.bin/lorder/lorder.sh
/usr/obj/usr/src/tmp/legacy/usr/bin/lorder
=== usr.bin/makewhatis (obj,depend,all,install)
/usr/obj/usr/src/tmp/usr/src/usr.bin/makewhatis created for
/usr/src/usr.bin/makewhatis
rm -f .depend
mkdep -f .depend -a-I/usr/obj/usr/src/tmp/legacy/usr/include
-std=gnu99 /usr/src/usr.bin/makewhatis/makewhatis.c
echo makewhatis: /usr/lib/libc.a /usr/lib/libz.a
/usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a .depend
cc -O2 -fno-strict-aliasing -pipe -std=gnu99
-I/usr/obj/usr/src/tmp/legacy/usr/include -c
/usr/src/usr.bin/makewhatis/makewhatis.c
${CTFCONVERT_CMD} expands to empty string
cc -O2 -fno-strict-aliasing -pipe -std=gnu99
-I/usr/obj/usr/src/tmp/legacy/usr/include -static
-L/usr/obj/usr/src/tmp/legacy/usr/lib -o makewhatis makewhatis.o -lz
-legacy
install -C -s -o root -g wheel -m 555 makewhatis
/usr/obj/usr/src/tmp/legacy/usr/bin/makewhatis
install -C -o root -g wheel -m 555
/usr/src/usr.bin/makewhatis/makewhatis.local.sh
/usr/obj/usr/src/tmp/legacy/usr/libexec/makewhatis.local
/usr/obj/usr/src/tmp/legacy/usr/libexec/catman.local -
/usr/obj/usr/src/tmp/legacy/usr/libexec/makewhatis.local
install: illegal option -- l
usage: install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
[-o owner] file1 file2
install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
[-o owner] file1 ... fileN directory
install -d [-v] [-g group] [-m mode] [-o owner] directory ...
*** [_installlinks] Error code 64
Stop in /usr/src/usr.bin/makewhatis.
*** [bootstrap-tools] Error code 1
Stop in /usr/src.
*** [_bootstrap-tools] Error code 1
Stop in /usr/src.
*** [buildworld] Error code 1
Stop in /usr/src.
--
Paul Dokas dokas at dokas.name
==
Don Juan Matus: an enigma wrapped in mystery wrapped in a tortilla.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
--
Paul Dokas dokas at dokas.name
==
Don Juan Matus: an enigma wrapped in mystery wrapped in a tortilla.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Tell me how to increase the virtual disk with ZFS?
On May 11, 2013, at 10:03 AM, Alexander Yerenkow yeren...@gmail.com wrote:
There's no mature (or flexible, or can do what I want ) way to
increase/decrease disk sizes in FreeBSD for now {ZFS,UFS}.
Best and quickest way - to have twice spare space, copy data, create new
sufficient disk and copy back.
Is this a statement or a question ? If a statement, then it is factually FALSE.
If it is supposed to be a question, it does not ask anything.
--
Paul Kraus
Deputy Technical Director, LoneStarCon 3
Sound Coordinator, Schenectady Light Opera Company
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Tell me how to increase the virtual disk with ZFS?
On May 11, 2013, at 11:13 AM, Alexander Yerenkow yeren...@gmail.com wrote:
2013/5/11 Paul Kraus p...@kraus-haus.org
On May 11, 2013, at 10:03 AM, Alexander Yerenkow yeren...@gmail.com wrote:
There's no mature (or flexible, or can do what I want ) way to
increase/decrease disk sizes in FreeBSD for now {ZFS,UFS}.
Best and quickest way - to have twice spare space, copy data, create new
sufficient disk and copy back.
Is this a statement or a question ? If a statement, then it is factually
FALSE. If it is supposed to be a question, it does not ask anything.
It was a statement, and luckily I was partially wrong, as Vladislav did made
what he wanted to.
However, last time I checked there were no such easy ways to decrease zpools
Correct, there is currently no way to decrease the size of a zpool. That would
require a defragmentation utility, which is on the roadmap as part of the
bp_rewrite code enhancement (and has been for many, many years :-)
or increase/decrease UFS partitions.
Or grow mirrored ZFS as easily as single zpool.
This one I do not understand. I have grown mirrored zpools many times. Let's
say you have a 2-way mirror of 1 TB drives. You can do one of two things to
grow the zpool:
1) add another pair of drives (of any size) as another top level vdev mirror
device (you *can* use a different type of top level vdev, raidZ, simple, etc,
but that is not recommended for both redundancy and performance predictability
reasons).
2) swap out one of the 1 TB drives for a 2 TB (zpool replace), you can even
offline one of the halves of the mirror to do this (but remember that you are
vulnerable to a failure of the remaining drive during the resolver period), let
the zpool resolver, then swap out the other 1 TB drive for a 2 TB. If the auto
expand property is set, then once the resolver finishes you have doubled your
net capacity.
Or (killer one) remove added by mistake vdev from zpool ;)
Don't make that mistake. Seriously. If you are managing storage you need to be
double checking every single command you issue if you care about your data
integrity. You could easily make the same complaint about issuing an 'rm -rf'
in the wrong directory (I know people who have done that). If you are using
snapshots you may be safe, if not your data is probably gone.
On the other hand, depending on where in the tree you added the vdev, you may
be able to remove it. If it is a top level vdev, then you have just changed the
configuration of the zpool. While very not supported, you just might be able,
using zdb and rolling back to a TXG before you added the device, remove the
vdev. A good place to ask that question and have the discussion would be the
ZFS discuss list at illumos (the list discussion is not limited to illumos, but
covers all aspects of ZFS on all platforms). Archives here:
http://www.listbox.com/member/archive/182191/sort/time_rev/
Of course I'm not talking about real hw, rather virtual one.
Doesn't matter to ZFS, whether a drive is a physical, a partition, or a virtual
disk you perform the same operations.
If you happen to point me somewhere to have such task solved I'd be much
appreciated.
See above :-) Some of your issues I addressed above, others are not there (and
may never be).
--
Paul Kraus
Deputy Technical Director, LoneStarCon 3
Sound Coordinator, Schenectady Light Opera Company
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Light humour
it was not really meant to be trolling I am sorry if you see it that way; I just thought it was as my original posts state quite funny, never thought it would would raise so many follow up posts though :) On 02/05/2013, Eitan Adler li...@eitanadler.com wrote: On 2 May 2013 08:21, David Demelier demelier.da...@gmail.com wrote: 2013/4/28 Paul Webster paul.g.webs...@googlemail.com: Just got this link on IRC, (freenode/##freebsd) was so funny I thought I would see if I could get any of you guys to spit out you're coffee :) http://antibsd.wordpress.com/ Do not post any comment on that website ! The user will replace any content you write by something like You're article is excellent, pointing exactly the facts. All of the comments are probably edited by the maintainer https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/tumblr_lmpcbtar6f1qafrh6.jpg -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Light humour
ah my miss interpretation sorry :) On 03/05/2013, Eitan Adler li...@eitanadler.com wrote: On 3 May 2013 08:31, Paul Webster paul.g.webs...@googlemail.com wrote: it was not really meant to be trolling I am sorry if you see it that way; I just thought it was as my original posts state quite funny, never thought it would would raise so many follow up posts though :) antibsd is the troll, not you. -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Light humour
Just got this link on IRC, (freenode/##freebsd) was so funny I thought I would see if I could get any of you guys to spit out you're coffee :) http://antibsd.wordpress.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: announcing mdoc.su, short manual page URLs
On Tue, Feb 19, 2013 at 12:27:01AM -0800, Constantine A. Murenin wrote:
Dear freebsd-{chat,current,doc}@,
I would like to announce and introduce URL:http://mdoc.su/,
a deterministic URL shortener for BSD manual pages,
written entirely in nginx.conf.
It supports several address schemes, for example:
http://mdoc.su/f/zfs
http://mdoc.su/f/zfs.8
http://mdoc.su/f/8/zfs
http://mdoc.su/freebsd/zfs
http://mdoc.su/FreeBSD/zfs
http://mdoc.su/d/hammer.5
http://mdoc.su/d/hammer.8
etc.
Very col!
One question: is the os version accessible comewhere, i.e. can I ask for
a manpage from a specific version of FreeBSD?
I have to disagree with Darren Pilgrim however, this is not slight abuse
of rewrite rules but putting rewrite rules to better use :-)
Kind regards,
Paul Schenkeveld
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Expanding ZFS RAIDZ on the fly?
On Fri, Jan 11, 2013 at 10:39:10AM +, Tom Evans wrote: On Fri, Jan 11, 2013 at 7:10 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: My question may sound naiv, sorry. I have already set up a RAIDZ (on FreeBSD 10.0-CUR), comprised with three 3 TB disks. I'd like to expand the array with an additional disk - on the fly. oh It's not possible to expand by just 1 disk. Expanding with another 3 disks is possible though, or backup, destroy, create, restore. Expanding or reducing the number of disks in a raidz is the mythical block pointer rewrite functionality, google will tell more. Another growth path is replacing each of the existing disks by larger ones and resilvering the data with 'zpool replace ...'. Having a spare drive bay is really a help so if you wanted to add just a 4th drive because you've only one bay left you should consider leaving that one unoccupied so you can easily grow to bigger disks now or in the future. HTH Paul Schenkeveld ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: looking for help from ppp users
Hey there gary, this works for talktalk/UK ADSL modem in PPPoE mode, or did beore my house move ill double cobnfirm in 6 days when my new line is active. #talktalk: set reconnect 999 1 set device PPPoE:xl0 # replace xl1 with your Ethernet device set authname my-house-phone-num...@talktalk.net set authkey myAdsl password set dial set login add default HISADDR set speed sync set mru 1492 set mtu 1492 set ctsrts off enable echo set echoperiod 15 enable lqr set lqrperiod 15 enable ipcp disable ipv6cp disable dns set server /tmp/pppoe-adsl0 .. 0177 add! default HISADDR add! default HISADDR6 On Sat, 15 Dec 2012 06:14:10 -, Eitan Adler li...@eitanadler.com wrote: On 3 December 2012 10:41, Gary Palmer gpal...@freebsd.org wrote: While not commenting on the correctness of the current contents, the userland PPP section of the FAQ appears to mostly deal with dialup modems. I suspect more people use it now to do PPPoA or PPPoE for some form of DSL link and there probably needs to be some effort to address the differences. I've never used PPP in any sense. Any chance I could enlist you to help write some content? I could turn it into docbook, edit it, etc. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Request for merge into 9.x
Hello I was recently reading about your work on the Ralink 2860, I run an EEEPC 1000 at the moment and have always wanted to run freebsd on it; however due to the wireless not being supported and a hatred for hanging usb dongles handing everywhere; I had to run linux. I am no driver developer, but I would love to give your driver a trial run on 9.1-RELEASE or -STABLE if easier, I am quite sure once everyone with an eeepc realizes we finally have a working wifi card; they will be most impressed :) as an aside, if you could leave me some simplish instructions on howto actually generate the kernel module in 9.0/9.1 -RELEASE I would happily report how well it works -- paul ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Upgrading FreeBSD to use the NEW pf syntax.
I only really need one question answered in honesty; I personally think that by forking our own version of PF we have essentially made something totally different to what everyone wants to use. Which is fine, but because of that development of new features have dropped behind. If we had kept up with OpenBSD's version even if we trailed it by one MAJOR release; at least part of the development would have been done. So now we end up in a situation where we have these firewalls, IPFW2,ipf,pf(modded) and users wanting the newer features of OpenBSD's pf. So timewise the fork of pf may have actually cost more in time rather than less. I don't however think the 'solution' to the problem is just to say no to the userbase by not even trying to port across the newer pf. I think we should look at bringing it across, slowly and seeing what the uptake is like; in a few MAJOR releases we can start to look at which of the firewalls realistically are not used that much and should be deprecated. On Wed, 21 Nov 2012 15:20:19 -, Ermal Luçi e...@freebsd.org wrote: On Wed, Nov 21, 2012 at 3:52 PM, Gleb Smirnoff gleb...@freebsd.org wrote: On Wed, Nov 21, 2012 at 03:44:13PM +0100, Ermal Lu?i wrote: E Cherry-picking would be when tehre is reasonable similarities. E Also another argument to do this would be simplicity on locking as well as E i told you when you started the changes. You were wrong. OpenBSD doesn't move towards SMP model. Locking more recent pf is not simplier, but the opposite. I am sorry but you are asking arguments i already have given you. You didn;t listen once and i do not expect this time as well. E Though i am open to work together on this to merge the new syntax thorugh a E whole bulk merge rather than cherry-pick. How many bugs have you closed after the previous bulk import? Why should we expect anything good from new import if the previous one was a PITA? Well you have used it for your work so it was not so PITA. Most of the ones you closed had message 'This is to old to be true'; 'I have re-written PF and this should be fixed'. And still I don't see any answer on the question: what exact features or perfomance improvements are we going to obtain from the new pf? See above. E You already have 'broken' some functionality as if-bound in FreeBSD 10.x so Is there any PR filed on that? I didn't even receive a mail about that. I really do not think you do the right approach or the right communication on this. Sorry for replying to you ;). -- Totus tuus, Glebius. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Upgrading FreeBSD to use the NEW pf syntax. (Copied from freebsd-pf)
Forward notice: I sent this to freebsd-pf originally and did not CC -current, but as the issue would affect current and the more opinions the better... I have sent it here too. -- Cheers, daemon -- original message Good day all, I am aware this is a much discussed subject since the upgrade of PF, I believe the final decision was that to many users are used to the old style pf and an upgrade to the new syntax would cause to much confusion. There was a recent debate on ##freebsd about this issue and I was inclined to mail in and get your opinions; basically it boiled down to the majority of users wanting either: 1) To move to the newer pf and just add to releases notes what had happened, and 2) my own personal opinion: creating 'pf2-*' as a kernel option tree, basically using the newer pf syntax and allowing users to choose. I would be interested to know the feedback from you guys as to be honest there seems to be quite a few users who actually DO want the new style format and functionality that comes with. I Attached the log of the conversation just for reference. -- Thank you for your time -- Paul G Webster 'daemon' Using Opera's revolutionary email client: http://www.opera.com/mail/* daemonik (~ad...@mail.originate.com) has joined ##freebsd daemonik Is the implementation of PF on FreeBSD up to date yet? blakkheim no * stormcrow (~phyde...@c-24-126-183-121.hsd1.ga.comcast.net) has left ##freebsd blakkheim and it won't ever be, we (retardedly) forked it with some random guy's patches rather than updating it wallshot it's rare that that question asked about *any* part of the base OS will be answered with yes wallshot doh. booo @ random patches illuminated blakkheim that was truly a stupid move blakkheim i agree illuminated any chance of getting them to 'take it back' blakkheim they think freebsd users are too stupid to adapt to the newer pf syntax and thousands will upgrade without knowing and be left with an unreachable system or some bs like that daemon is there anything that pf can do that ipfw cannot do blakkheim check the freebsd-pf mailing list illuminated (or feel free to post and complain) daemonik blakkheim: That's pretty damn . . wow daemon might be worth a few emails to all the lists asking for other users to post into the pf list to support moving to the correct pf daemon maybe we can implement the newer pf as 'pf2' daemonik FreeBSD presently doesn't have ALTQ support included in the generic kernel, correct? Is there an alternative to ALTQ? blakkheim daemon: i think so too daemonik daemon: Is it really that hard to shout in the appropriate places to properly inform users? What about release notes? Anybody who doesn't read release notes deserves what's coming to them. blakkheim that's what i said! * chrisb has learned to read MOVED and UPDATING closely daemonik Huh . . that kind of behavior is why no one respects anyone/thing associated with GNOME anymore . . daemon daemonik, I dont see it being that hard to use both the 'ramdon guys patches' version of pf as the default for a few releases putting the newer version of pf as 'pf2' daemon therefor satisfying both channels of thought daemon there certainly should be A WAY of using the newer version blakkheim posting these thoughts to freebsd-pf@ is much more likely to invoke a change (or at least a poll or something) than on irc daemonik daemon: No . . the noobs are the ones who should have to use a pf-something. I bother to read the release notes, I want to use the correct version of the software. Why should I have to suffer? Why should I change when they're the ones who suck? * nightwalk has quit (Ping timeout: 276 seconds) daemonik I'll make a post later tonight. I hope that others see these messages and also articulate their thoughts on the mailing list. FreeBSD should hold a high standard for something as important as PF. daemon daemonik, if you did read release notes you would see 'ad the new version of pf is pf2' there is no need to upset users without cause; as the 'patched' pf is the default for the tag 'pf' at the moment making the new version 'pf2' is literally much more sane daemon and certainly a huge degree less antagonistic SlitazMint How do I find the size of a folder? SlitazMint And for that matter how do I search a man page? blakkheim du -sh dirname and use /string to search SlitazMint Thanks blakkheim daemonik I would rather read the release notes seeing that the WRONG version of PF gets deprecated to pf-legacy as it ought to be knowing that those who don't read the release notes will have a bad day. daemonik Referring to the CORRECT and latest stable version of PF as PF2 would make FreeBSD . . well, look about as incompetent as certain Linux distros sometimes do to say the least. daemon daemonik, transistion time should always be taken into account on any system; if we did was I was suggesting then 'pf' would be the new version in -CURRENT but for later 9.x releases it would still
ZFS RaidZ-2 problems
I've already posted this to freebsd-fs@ but still have no idea as to why the below has happened. On 10/30/12 09:08, Paul Wootton wrote: Hi, I have had lots of bad luck with SATA drives and have had them fail on me far too often. Started with a 3 drive RAIDZ and lost 2 drives at the same time. Upgraded to a 6 drive RAIDZ and lost 2 drives with in hours of each other and finally had a 9 drive RAIDZ (1 parity) and lost another 2 drives (as luck would happen, this time I had a 90% backup on another machine so did not loose everything). I finally decided that I should switch to a RAIDZ2 (my current setup). Now I have lost 1 drive and the pack is showing as faulted. I have tried exporting and reimporting, but that did not help either. Is this normal? Has any one got any ideas as to what has happened and why? The fault this time might be cabling so I might not have lost the data, but my understanding was that with RAIDZ-2, you could loose 2 drives and still have a working pack. I do know the fault could also be the power supply, controller etc. I can take care of all the hardware. The issue I have is, I have a 9 RAIDZ-2 pack with only 1 disk showing as offline and the pack is showing as faulted. If the power supply was bouncing and a drive was giving bad data, I would expect ZFS to report that 2 drives were faulted (1 offline and 1 corrupt) Is there a way with ZDB that I can see why the pool is showing as faulted? Can it tell me which drives it thinks are bad, or has bad data? I do still have the 90% backup of the pool and nothing has really changed since that backup, so if someone wants me to try something and it blows the pack away, it's not the end of the world. Cheers Paul pool: storage state: FAULTED status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://illumos.org/msg/ZFS-8000-3C scan: resilvered 30K in 0h0m with 0 errors on Sun Oct 14 12:52:45 2012 config: NAME STATE READ WRITE CKSUM storage FAULTED 0 0 1 raidz2-0FAULTED 0 0 6 ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 1811927559723424 UNAVAIL 0 0 0 was /dev/ada3 ada4 ONLINE 0 0 0 ada5 ONLINE 0 0 0 ada6 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada8 ONLINE 0 0 0 ada10p4 ONLINE 0 0 0 root@filekeeper:/storage # zpool export storage root@filekeeper:/storage # zpool import storage cannot import 'storage': I/O error Destroy and re-create the pool from a backup source. root@filekeeper:/usr/home/paul # uname -a FreeBSD filekeeper.caspersworld.co.uk 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r240967: Thu Sep 27 08:01:24 UTC 2012 r...@filekeeper.caspersworld.co.uk:/usr/obj/usr/src/sys/GENERIC amd64 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS RaidZ-2 problems
On 11/05/12 10:49, Steven Hartland wrote: Yes RAIDZ2 should enable a 2 drive failure without the array faulting so something strange is going on there somewhere. That was my thought, but I dont know what or why. Silly question, what size drives and what driver are you using? See below Regards Steve - Original Message - From: Paul Wootton paul-free...@fletchermoorland.co.uk To: freeBSD-CURRENT Mailing List freebsd-current@freebsd.org Sent: Monday, November 05, 2012 10:25 AM Subject: ZFS RaidZ-2 problems state: FAULTED status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://illumos.org/msg/ZFS-8000-3C scan: resilvered 30K in 0h0m with 0 errors on Sun Oct 14 12:52:45 2012 config: NAME STATE READ WRITE CKSUM storage FAULTED 0 0 1 raidz2-0FAULTED 0 0 6 ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 1811927559723424 UNAVAIL 0 0 0 was /dev/ada3 ada4 ONLINE 0 0 0 ada5 ONLINE 0 0 0 ada6 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada8 ONLINE 0 0 0 ada10p4 ONLINE 0 0 0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ST3500418AS CC37 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: WDC WD5000AACS-00D0B0 01.01B01 ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: MAXTOR STM3500320AS MX15 ATA-8 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad10 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ST3500410AS CC34 ATA-8 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad12 ada4 at ahcich5 bus 0 scbus7 target 0 lun 0 ada4: WDC WD5000AADS-00S9B0 01.00A01 ATA-8 SATA 2.x device ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: Command Queueing enabled ada4: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada4: Previously was known as ad18 ada5 at ahcich6 bus 0 scbus9 target 0 lun 0 ada5: WDC WD5000AADS-00S9B0 01.00A01 ATA-8 SATA 2.x device ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: Command Queueing enabled ada5: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada5: Previously was known as ad22 ada6 at ahcich7 bus 0 scbus10 target 0 lun 0 ada6: WDC WD5000AADS-00M2B0 01.00A01 ATA-8 SATA 2.x device ada6: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada6: Command Queueing enabled ada6: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada6: Previously was known as ad24 ada7 at ahcich8 bus 0 scbus11 target 0 lun 0 ada7: WDC WD5000AADS-00M2B0 01.00A01 ATA-8 SATA 2.x device ada7: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada7: Command Queueing enabled ada7: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada7: Previously was known as ad26 ada8 at ahcich9 bus 0 scbus12 target 0 lun 0 ada8: WDC WD5000AADS-00M2B0 01.00A01 ATA-8 SATA 2.x device ada8: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada8: Command Queueing enabled ada8: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada8: Previously was known as ad28 ada9 at ahcich10 bus 0 scbus13 target 0 lun 0 ada9: MAXTOR STM3160215AS 4.AAB ATA-7 SATA 2.x device ada9: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada9: Command Queueing enabled ada9: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) ada9: Previously was known as ad30 ada10 at ahcich11 bus 0 scbus14 target 0 lun 0 ada10: ST31000528AS CC38 ATA-8 SATA 2.x device ada10: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada10: Command Queueing enabled ada10: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada10: Previously was known as ad32 root@filekeeper:/dev # gpart show ada10 =34 1953525101 ada10 GPT (931G) 34 256 1 freebsd-boot (128k
Re: Clang as default compiler November 4th
--On September 11, 2012 2:44:03 AM -0700 Doug Barton do...@freebsd.org wrote: Doug, as you can already use CLANG instead of GCC now, you will be able to use GCC instead of CLANG after November 4th. There's lots of things I _can_ do, what we're discussing is what the defaults should be. At the moment the ports maintainers don't give much about if their ports build with CLANG or not Do you follow ports development? At all? There have been extensive efforts over the last several years to get more ports compiling with clang. The problem is that things like the c89 issue don't percolate down, and we don't have a concerted effort from all of the relevant parties to improve the issue. Fixing the problem of getting the right eyeballs on the things that need fixing won't be improved by switching the default before they are fixed. In fact, it's likely to make the people who are src-centric now even less likely to help because their work will be done. Those who don't run CURRENT won't notice, but those who do will have to get their butts up and fix the ports, so 10.0 can have 99% of all ports build with CLANG and even 8.x and 9.x can already profit from having the broken ports fixed now. Yeah, and I'm going to get a pony out of this deal, right? :) You completely misunderstand the nature of the problem, therefore your proposed solution isn't going to solve it. Perhaps a port maintainer's input would help? I'd never even heard of clang until recently. I'm not a programmer. If I can't get my ports to compile with clang without a knowledge of programming, I'll abandon them. I'm too old and too tired to try learning a brand new system. I doubt I'm alone. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson There are some ideas so wrong that only a very intelligent person could believe in them. George Orwell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Soekris net4801 sees no disk devices with -CURRENT
On Mon, Aug 13, 2012 at 11:30:06PM +0200, Pierre DAVID wrote: On Sun, Aug 12, 2012 at 05:49:24PM +0200, Paul Schenkeveld wrote: Hi, I am trying to build a NanoBSD image for Soekris net4801 with a recent -CURRENT. The kernel boots fine but when it comes to mounting the root filesystem, it cannot find the flash disk anymore. Bios is up to date (1.33). Hello, I'm trying to resurrect my old net4801 and update it with -CURRENT (old version was a 8-CURRENT), and I do not succeed to get kernel output via the RS-232 port. Kernel goes mute just after being loaded. Could you send me your NanoBSD kernel configuration file? Pierre Below is my kernel config. You also have to use boot0sio and create a file called /boot.config containing -h so the boot loader knows that you want to use a serial console. Usually NanoBSD does that for you if you include customize_cmd cust_comconsole in your NanoBSD config file and leave NANO_BOOTLOADER set to its default of boot/boot0sio. # from GENERIC cpu I586_CPU ident NET4801 options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. options INCLUDE_CONFIG_FILE # Include this file in kernel device apic# I/O APIC device cpufreq device acpi device pci device ahci# AHCI-compatible SATA controllers device ata # Legacy ATA/SATA controllers options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering device mvs # Marvell 88SX50XX/88SX60XX/88SX70XX/SoC SATA device siis# SiliconImage SiI3124/SiI3132/SiI3531 SATA device scbus # SCSI bus (required for ATA/SCSI) device da # Direct Access (disks) device pass# Passthrough device (direct ATA/SCSI access) device ctl # CAM Target Layer device pmtimer device uart# Generic UART driver device miibus # MII bus support device sis # Silicon Integrated Systems SiS 900/SiS 7016 device loop# Network loopback device random # Entropy device device ether # Ethernet support device vlan# 802.1Q VLAN support device tun # Packet tunnel. device md # Memory disks device gif # IPv6 and IPv4 tunneling device bpf # Berkeley packet filter options USB_DEBUG # enable debug msgs device uhci# UHCI PCI-USB interface device ohci# OHCI PCI-USB interface device usb # USB Bus (required) device umass # Disks/Mass storage - Requires scbus and da # local additions makeoptions MODULES_OVERRIDE= options CPU_GEODE options CPU_SOEKRIS device atadisk # ATA disk drives I have tried with and without the device atadisk line but my compact flash is never seen by the kernel. Kind regards, Paul Schenkeveld ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
make package fails in chroot: tar: getvfsbyname failed: No such file or directory
Hi, I have a wrapper script that builds packages in a chroot environment which happily runs on release 6 thru 9 and earlier 10 but fails with: tar: getvfsbyname failed: No such file or directory on a recent -CURRENT. What I could dig up so far is that make package-recursive calls pkg_create(1) which in turn calls tar -c -f portname.tbz -j -T - and then starts feeding filenames that should go into the tarball. Something has changed in libarchive when src/contrib/libarchive/libarchive/archive_read_disk_posix.c was introduced (libarchive 3.0.3, svn rev 232153 I think) where setup_current_filesystem() calls getvfsbyname(). Now it's getting too hairy for me so I hope someone with more insight in this kind of stuff can help me out. My chroot environment has a root directory which is a subdir of my build environment, so not a mountpoint by itself. /usr/src and /usr/ports are NFS mounted from a fileserver and I have devfs mounted on /dev. Thanks for any help! With kind regards, Paul Schenkeveld ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Soekris net4801 sees no disk devices with -CURRENT
Hi, I am trying to build a NanoBSD image for Soekris net4801 with a recent -CURRENT. The kernel boots fine but when it comes to mounting the root filesystem, it cannot find the flash disk anymore. Bios is up to date (1.33). The full boot -v log is below, here are the lines related to the ATA subsystem: atapci0: National Geode SC1100 ATA33 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 18.2 on pci0 ata0: ATA channel at channel 0 on atapci0 ata1: ATA channel at channel 1 on atapci0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 (aprobe0:ata0:0:0:0): SIGNATURE: (aprobe0:ata0:0:0:0): ATA status error (aprobe0:ata0:0:0:0): SETFEATURES SET TRANSFER MODE. ACB: ef 03 00 00 00 40 00 00 00 00 0c 00 (aprobe0:ata0:0:0:0): CAM status: ATA Status Error (aprobe0:ata0:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (aprobe0:ata0:0:0:0): RES: 51 04 00 00 00 00 00 00 00 0c 00 (aprobe0:ata0:0:0:0): Retrying command (aprobe0:ata0:0:0:0): ATA status error (aprobe0:ata0:0:0:0): SETFEATURES SET TRANSFER MODE. ACB: ef 03 00 00 00 40 00 00 00 00 0c 00 (aprobe0:ata0:0:0:0): CAM status: ATA Status Error (aprobe0:ata0:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (aprobe0:ata0:0:0:0): RES: 51 04 00 00 00 00 00 00 00 0c 00 (aprobe0:ata0:0:0:0): Error 5, Retries exhausted ata1: reset tp1 mask=00 ostat0=ff ostat1=ff (probe0:ctl2cam0:0:1:0): Error 6, Unretryable error Kernels up to FreeBSD 9 run fine on this box. Hope this can be solved, I have many of these devices in use and would really like to use the new carp(4) stuff in -CURRENT. Any ideas? With kind regards, Paul Schenkeveld [boot -v log] Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #1 r232152: Sun Aug 12 17:20:11 CEST 2012 paul@localhost:/usr/obj/nanobsd.NET4801_10/i386.i386/FreeBSD/src-10/sys/NET4801_10_GEN i386 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel /boot/kernel/kernel at 0xc14fd000. Calibrating TSC clock ... TSC clock: 266677901 Hz CPU: Geode(TM) Integrated Processor by National Semi (586-class CPU) Origin = Geode by NSC Id = 0x540 Family = 5 Model = 4 Stepping = 0 Features=0x808131FPU,TSC,MSR,CX8,CMOV,MMX real memory = 268435456 (256 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x01826000 - 0x0fb24fff, 238022656 bytes (58111 pages) avail memory = 239140864 (228 MB) bios32: Found BIOS32 Service Directory header at 0xc00f7800 bios32: Entry = 0xf7840 (c00f7840) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0x7861 Other BIOS signatures found: random device not loaded; using insecure entropy ULE: setup cpu 0 snd_unit_init() u=0x00ff8000 [512] d=0x7c00 [32] c=0x03ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 wlan: 802.11 Link Layer kbd: new array size 4 kbd1 at kbdmux0 mem: memory nfslock: pseudo-device null: null device, zero device io: I/O random: entropy source, Software, Yarrow hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 ACPI Error: A valid RSDP was not found (20120215/tbxfroot-237) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=00011078) pcibios: BIOS version 2.01 pcib0: Host to PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 pci0: domain=0, physical bus=0 found- vendor=0x1078, dev=0x0001, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found- vendor=0x100b, dev=0x0020, revid=0x00 domain=0, bus=0, slot=6, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x3f (1890 ns), mingnt=0x0b (2750 ns), maxlat=0x34 (13000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xe100, size 8, enabled map[14]: type Memory, range 32, base 0xa000, size 12, enabled found- vendor=0x100b, dev=0x0020
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
在 2012年1月31日 下午11:28，Konstantin Belousov kostik...@gmail.com 写道： On Tue, Jan 31, 2012 at 09:23:50AM +0800, Paul Ambrose wrote: ?? 2012??1??31?? 12:43??Kostik Belousov kostik...@gmail.com ?? On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: ?? 2012??1??30?? 2:36??Kostik Belousov kostik...@gmail.com ?? On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote: I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current patched with pcid.2.patch? It works well without other issue and it seem the pcid patch does not affect other part of the kernel. The other one is Sandy Athlons do not have PCID and probably will never implement it. They use other tricks to get similar optimizations, transparently to the OS. Just curious, is this AMD similar optimizations Address Space Number (ASN) and Global flag US Patent 6,604,187. http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html This and the same-important next item 'The TLB Flush Filter' is what I referred to. I did not found anything about ASN in the AMD manual It is a transparent optimization, which does not require any OS support. Intel PCID is completely different, it shall be explicitely handled by OS. It is some consequence of the nested pages support, AFAIU. Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the pcid.2.patch seems dependent on AVX and XSAVE stuffs which is available on -current). But it hangs up just in a few minutes. I doubt the nvidia-driver which is not recompiled with patched kernel is the root, I will check this out later, but does anyone meet similar problem? There are two many variations compared to the config I did tested. I do not see anything obvious in the changes between HEAD and stable/9 which could be blamed. Nvidia driver might be bigger suspect, but again, I am not aware of anything wrong with it. I have two question about the pcid.2.patch Item 2 is clean, I fixed it. For the item 1, I was only able to decipher the proposal to optimize the global shootdown handler to restore the %cr3 with bit 64 set to not invalidate current PCID. Is there some more changes ? yes, that is what I meant. I was wondering using another way that each process has different pcid in each active processor, just as the freebsd mips and powerpc uses. But obviously this way is more friendly to non-pcid x86 processor. Each vmspace (or pmap) has unique PCID with the patch, at least until PCID space (12bit) is not exhausted. To really exhaust it, you need 4095 processes, so it is unlikely but possible event with the current settings. Thank you for your explanation. I just disabled nvidia-driver( not load it) , and use buildworld buildkernel to test the pcid.1.patch with 9-release, it seems the box reset before completing the buildkernel, the attachment is my kernel config, would you mind try it on 9-release with pcid.1.patch? I will git 10-current a try to see if there is something wrong with my hardware I just did checkout + buildworld + buildkernel with -j 10 on UFS with PCID turned on, everything finished fine. It is up to date HEAD. sandy% sysctl vm.stats.sys.v_swtch vm.pmap.pcid_save_cnt vm.stats.sys.v_swtch: 13743519 vm.pmap.pcid_save_cnt: 7853519 I.e. the TLB was not flushed one each second context switch. Trying the HEAD with the patch is probably easiest way forward. Unfortunately, I try 10-current(HEAD) with pcid.3.patch in my i5-2300 box, system panic ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
在 2012年1月30日 下午2:36，Kostik Belousov kostik...@gmail.com 写道： On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote: I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current patched with pcid.2.patch? It works well without other issue and it seem the pcid patch does not affect other part of the kernel. The other one is Sandy Athlons do not have PCID and probably will never implement it. They use other tricks to get similar optimizations, transparently to the OS. Just curious, is this AMD similar optimizations Address Space Number (ASN) and Global flag US Patent 6,604,187. http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html I did not found anything about ASN in the AMD manual Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the pcid.2.patch seems dependent on AVX and XSAVE stuffs which is available on -current). But it hangs up just in a few minutes. I doubt the nvidia-driver which is not recompiled with patched kernel is the root, I will check this out later, but does anyone meet similar problem? There are two many variations compared to the config I did tested. I do not see anything obvious in the changes between HEAD and stable/9 which could be blamed. Nvidia driver might be bigger suspect, but again, I am not aware of anything wrong with it. I have two question about the pcid.2.patch Item 2 is clean, I fixed it. For the item 1, I was only able to decipher the proposal to optimize the global shootdown handler to restore the %cr3 with bit 64 set to not invalidate current PCID. Is there some more changes ? yes, that is what I meant. I was wondering using another way that each process has different pcid in each active processor, just as the freebsd mips and powerpc uses. But obviously this way is more friendly to non-pcid x86 processor. Thank you for looking at the patch. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
在 2012年1月31日 上午12:43，Kostik Belousov kostik...@gmail.com 写道： On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: ?? 2012??1??30?? 2:36??Kostik Belousov kostik...@gmail.com ?? On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote: I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current patched with pcid.2.patch? It works well without other issue and it seem the pcid patch does not affect other part of the kernel. The other one is Sandy Athlons do not have PCID and probably will never implement it. They use other tricks to get similar optimizations, transparently to the OS. Just curious, is this AMD similar optimizations Address Space Number (ASN) and Global flag US Patent 6,604,187. http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html This and the same-important next item 'The TLB Flush Filter' is what I referred to. I did not found anything about ASN in the AMD manual It is a transparent optimization, which does not require any OS support. Intel PCID is completely different, it shall be explicitely handled by OS. It is some consequence of the nested pages support, AFAIU. Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the pcid.2.patch seems dependent on AVX and XSAVE stuffs which is available on -current). But it hangs up just in a few minutes. I doubt the nvidia-driver which is not recompiled with patched kernel is the root, I will check this out later, but does anyone meet similar problem? There are two many variations compared to the config I did tested. I do not see anything obvious in the changes between HEAD and stable/9 which could be blamed. Nvidia driver might be bigger suspect, but again, I am not aware of anything wrong with it. I have two question about the pcid.2.patch Item 2 is clean, I fixed it. For the item 1, I was only able to decipher the proposal to optimize the global shootdown handler to restore the %cr3 with bit 64 set to not invalidate current PCID. Is there some more changes ? yes, that is what I meant. I was wondering using another way that each process has different pcid in each active processor, just as the freebsd mips and powerpc uses. But obviously this way is more friendly to non-pcid x86 processor. Each vmspace (or pmap) has unique PCID with the patch, at least until PCID space (12bit) is not exhausted. To really exhaust it, you need 4095 processes, so it is unlikely but possible event with the current settings. Thank you for your explanation. I just disabled nvidia-driver( not load it) , and use buildworld buildkernel to test the pcid.1.patch with 9-release, it seems the box reset before completing the buildkernel, the attachment is my kernel config, would you mind try it on 9-release with pcid.1.patch? I will git 10-current a try to see if there is something wrong with my hardware MYKERNEL Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current patched with pcid.2.patch? It works well without other issue and it seem the pcid patch does not affect other part of the kernel. The other one is Sandy Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the pcid.2.patch seems dependent on AVX and XSAVE stuffs which is available on -current). But it hangs up just in a few minutes. I doubt the nvidia-driver which is not recompiled with patched kernel is the root, I will check this out later, but does anyone meet similar problem? I have two question about the pcid.2.patch 1. iff --git a/sys/amd64/amd64/apic_vector.S b/sys/amd64/amd64/apic_vector.S index 96c778d..5b7b759 100644 --- a/sys/amd64/amd64/apic_vector.S +++ b/sys/amd64/amd64/apic_vector.S @@ -149,17 +149,40 @@ IDTVEC(invltlb) #endif pushq %rax + pushq %rdx - movq%cr3, %rax /* invalidate the TLB */ - movq%rax, %cr3 - + cmpl$0,pmap_pcid_enabled + je 1f + + cmpq$0,smp_tlb_invpcid + je 1f + + /* +* For PCID-enabled pmap, set bit 63 of loaded %cr3 to zero. +*/ + movq%cr3,%rax + movq$pcid_cr3,%rdx + cmpq%rax,%rdx + je 1f + movq%rdx,%cr3 + btsq $63, %rax //set bit 63. not flush the tlb when recovering + jmp 2f + + /* +* Invalidate the TLB. +*/ +1: + movq%cr3,%rax +2: // if pcid is available, can we recover the old pcid with 63 bit set？ + movq%rax,%cr3 movqlapic, %rax movl$0, LA_EOI(%rax)/* End Of Interrupt to APIC */ 2. amd64/amd64/pmap.c @@ -5098,15 +5168,20 @@ pmap_activate(struct thread *td) critical_enter(); pmap = vmspace_pmap(td-td_proc-p_vmspace); oldpmap = PCPU_GET(curpmap); + CPU_ZERO(pmap-pm_save); cpuid = PCPU_GET(cpuid); #ifdef SMP CPU_CLR_ATOMIC(cpuid, oldpmap-pm_active); CPU_SET_ATOMIC(cpuid, pmap-pm_active); + CPU_SET_ATOMIC(cpuid, pmap-pm_save); #else CPU_CLR(cpuid, oldpmap-pm_active); CPU_SET(cpuid, pmap-pm_active); + CPU_SET(cpuid, pmap-pm_active); // this should be pm_save not pm_active #endif cr3 = DMAP_TO_PHYS((vm_offset_t)pmap-pm_pml4); + if (pmap-pm_pcid != -1) + cr3 |= pmap-pm_pcid; td-td_pcb-pcb_cr3 = cr3; load_cr3(cr3); PCPU_SET(curpmap, pmap); ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Hi, Well, I don't chime in, usually. However, enough is enough. There are many merits to both *BSD and Linux. I don't agree with benchmarks that slant either way, as I'm sure people in both camps will agree. Please be adult and just agree to disagree. Technology applicable to the problem at hand is the only useful thing that we should all agree on. Personally, I don't care if it's BSD, a Linux-variant or even Windoze if it solves the problem. So, if you would all look at all the time spent venting on this idiocy as time that could have been spent coding, debugging, etc, think how much time was wasted from people just reading these e-mails. (Yes, I do and this was an absolute waste of my time.) So, if the communication on the thread was nearly as much going to development and finding issues or the causes of the issues, maybe a scheduler problem would be tracked down, maybe a benchmark issue would be tracked down. Maybe people will stop using RC's versus releases, I don't know. I really don't care. Just please stop with finger pointing and being disgruntled and indignant. FOCUS!! I'd love to say something like Can't we all just get along but we are just so polar in our beliefs, I don't see it happening. Just drop it. If you have something constructive to say, spin off this thread and let the primary thread just die. (It should have a week ago.) Solve the benchmarking issue, solve the scheduler issue, just focus. Paul P. CTO/Owner Atlantis Services Civilized Computing From: O. Hartmann ohart...@mail.zedat.fu-berlin.de To: Daniel Kalchev dan...@digsys.bg Cc: Martin Sugioarto mar...@sugioarto.com; freebsd-current@FreeBSD.ORG; Igor Mozolevsky i...@hybrid-lab.co.uk; freebsd-performa...@freebsd.org; O. Hartmann ohart...@zedat.fu-berlin.de; dan...@freebsd.org Sent: Saturday, December 24, 2011 9:49 AM Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server On 12/23/11 12:38, Daniel Kalchev wrote: On 23.12.11 12:48, O. Hartmann wrote: Look at Steve Kargls problem. He investigated a SCHED_ULE problem in a way that is far beyond enough! He gave tests, insights of his setup, bad performance compared to SCHED_4BSD and what happend? We are still stuck with this problem and more and more people realise, that FreeBSD does have somewhere a problem and this seems to be a nasty problem not easy to find or investigate. This has made me to realize, that I was having a problem with SCHED_ULE that I was not aware of until now. WOW! :) Every scheduler has some problem, some fail here some fail there. I am confident, that the case that Steve Kargls has reported will be resolved. Another problem is this very elite-feeling closed club. Once you managed it getting into the club of committers or core team members, you'll probably fight for your seat ... I dont propose for that socialists crap Linux people tend to be like, [..] You never heard of the People's Republic of Berkeley? :) As for commiter access, this sort of comments trigger the system administrator in me. I have seen enough people, who for the lack of other excuses always use but I don't have enough RIGHTS!. I am evil, I know But I follow the illusion that if people can see what benchmarks reveal, they start thinking and if the facts are starting to give a heavy load load on those rejecting the facts, they migght change their opinion or get hopefully replaced by more openminded people. Here is now it works: If you see an problem and have a solution: go fix it. Many will be grateful. If you can't fix it, but have an idea how to fix it, share it. May will be grateful. If you can't fix it and don't have any idea, just say there is a problem and stop there. There are many, many, many like you who just hold their breath. We all learn, every day. Daniel Sorry, but your crap is simply breathtaking. oh ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITHOUT_PROFILE=yes by default
I think dtrace for freebsd userland is close to complete( after r227290, at least no more kernel panic). but is not suitable for a daily use now. 在 2011年11月30日 上午5:42，Sevan / Venture37 ventur...@gmail.com 写道： I assume every who responded so far doesn't use dtrace? Sevan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Intel Sandy Bridge support for hwpmc
sorry, I'm late. the -current has the same problem. here is coredump
capoor-daemon dumped core - see /var/crash/vmcore.2
Thu Nov 24 15:46:46 CST 2011
FreeBSD capoor-daemon 10.0-CURRENT FreeBSD 10.0-CURRENT #1
r+8692e3b-dirty: Thu Nov 24 15:34:53 CST 2011
root@capoor-daemon:/usr/obj/usr/src/sys/MYKERNEL amd64
panic:
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
Unread portion of the kernel message buffer:
118Nov 24 15:44:10 capoor-daemon syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...Syncing
disks, vnodes remaining...6 3 1 1 1 0 0 done
All buffers synced.
Uptime: 50s
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x8075e19b
stack pointer = 0x28:0xff811c0e29b0
frame pointer = 0x28:0xff811c0e29c0
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 = 1555 (reboot)
Reading symbols from /boot/kernel/uplcom.ko...Reading symbols from
/boot/kernel/uplcom.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/uplcom.ko
Reading symbols from /boot/kernel/ucom.ko...Reading symbols from
/boot/kernel/ucom.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ucom.ko
#0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:261
261 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:261
#1 0x802d0fd0 in db_dump (dummy=Variable dummy is not available.
)
at /usr/src/sys/ddb/db_command.c:537
#2 0x802d0901 in db_command (last_cmdp=0x80b08340,
cmd_table=Variable cmd_table is not available.
) at /usr/src/sys/ddb/db_command.c:448
#3 0x802d0b50 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:501
#4 0x802d2c84 in db_trap (type=Variable type is not available.
#5 0x804e4fb1 in kdb_trap (type=9, code=0, tf=0xff811c0e2900)
at /usr/src/sys/kern/subr_kdb.c:625
#6 0x80744072 in trap_fatal (frame=0xff811c0e2900, eva=0)
at /usr/src/sys/amd64/amd64/trap.c:814
#7 0x8074467b in trap (frame=0xff811c0e2900)
at /usr/src/sys/amd64/amd64/trap.c:617
#8 0x8072e7d3 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#9 0x8075e19b in uncore_pcpu_fini (md=0xfe0004b03c00,
cpu=Variable cpu is not available.
)
at cpufunc.h:353
#10 0x802fc5ea in load (module=Variable module is not available.
)
at /usr/src/sys/dev/hwpmc/hwpmc_mod.c:4885
#11 0x804b803a in syscall_module_handler (mod=0xfe00017b9b00,
what=Variable what is not available.
) at /usr/src/sys/kern/kern_syscalls.c:185
#12 0x8049b30f in module_shutdown (arg1=Variable arg1 is not
available.
)
at /usr/src/sys/kern/kern_module.c:104
#13 0x804adc36 in kern_reboot (howto=0)
at /usr/src/sys/kern/kern_shutdown.c:446
#14 0x804ae3dc in sys_reboot (td=0xfe00b219b460,
uap=0xff811c0e2bc0) at /usr/src/sys/kern/kern_shutdown.c:188
#15 0x80743887 in amd64_syscall (td=0xfe00b219b460, traced=0)
at subr_syscall.c:131
#16 0x8072eab7 in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:387
#17 0x000800882bbc in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
在 2011年11月18日 上午2:52，Davide Italiano davide.itali...@gmail.com 写道：
On Tue, Nov 15, 2011 at 3:44 AM, Paul Ambrose ambrose...@gmail.com wrote:
hi, I apply your patch on this
[root@capoor-daemon /usr/src]# git show
commit 4ec1d958bad5e78bcd3cc61a0da6b5a1302f8ec2
Author: kensmith kensm...@freebsd.org
Date: Mon Nov 14 00:45:25 2011 +
The releng/9.0 release branch has been created so convert stable/9 over
to our standard Politically Correct name for the balance of the
9.0-RELEASE
release cycle.
Approved by:re (implicit)
when my machine shutdown in my absence yesterday evening, I find a
kernel oops this morning,(sorry, just printf, I can not get a kernel
dump)
the kernel says it is at uncore_pcpu_fini+0x5b
I check the source, and it is at
static int
uncore_pcpu_fini(struct pmc_mdep *md, int cpu)
{
.
for (n = 0; n npmc; n++)
wrmsr(UCP_EVSEL0 + n, 0); //here
.
here is my cpu type, and build hwpmc into kernel
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986
Re: Reprobing of devices after module load?
On 11/21/11, John Baldwin j...@freebsd.org wrote: On Friday, November 18, 2011 11:48:20 am Paul B. Mahol wrote: Hi, Is there nice way in FreeBSD to force reprobe of devices for specific driver like it is done when kernel module is loaded (via DRIVER_MODULE(...) stuff)? Note that those probes happen for specific buses rather than for specific drivers. The routine that does this currently is static (devclass_driver_added() in sys/kern/subr_bus.c). What specific problem are you trying to solve? You might be able to use BUS_DRIVER_ADDED() or device_probe_and_attach() to achieve what you are trying to do. I have changed NDISulator to load 3rd party *.SYS from userspace via ioctl on /dev/ndis. For now i can do reprobe by reloading if_ndis.ko module. Loading if_ndis.ko ideally should not cause reprobe but reprobe should be done after ioctl on /dev/ndis. Perhaps devclass_add_driver from sys/kern/subr_bus can do this? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Reprobing of devices after module load?
Hi, Is there nice way in FreeBSD to force reprobe of devices for specific driver like it is done when kernel module is loaded (via DRIVER_MODULE(...) stuff)? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Intel Sandy Bridge support for hwpmc
hi, I apply your patch on this
[root@capoor-daemon /usr/src]# git show
commit 4ec1d958bad5e78bcd3cc61a0da6b5a1302f8ec2
Author: kensmith kensm...@freebsd.org
Date: Mon Nov 14 00:45:25 2011 +
The releng/9.0 release branch has been created so convert stable/9 over
to our standard Politically Correct name for the balance of the
9.0-RELEASE
release cycle.
Approved by:re (implicit)
when my machine shutdown in my absence yesterday evening, I find a
kernel oops this morning,(sorry, just printf, I can not get a kernel
dump)
the kernel says it is at uncore_pcpu_fini+0x5b
I check the source, and it is at
static int
uncore_pcpu_fini(struct pmc_mdep *md, int cpu)
{
.
for (n = 0; n npmc; n++)
wrmsr(UCP_EVSEL0 + n, 0); //here
.
here is my cpu type, and build hwpmc into kernel
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-PRERELEASE #0 r+4ec1d95-dirty: Mon Nov 14 15:31:45 CST 2011
root@capoor-daemon:/usr/obj/usr/src/sys/MYKERNEL amd64
CPU: Intel(R) Core(TM) i5-2300 CPU @ 2.80GHz (2793.02-MHz K8-class CPU)
I will try to apply this to current to see if this is reproduced.
2011/11/14 Attilio Rao atti...@freebsd.org:
2011/11/13 Davide Italiano davide.itali...@gmail.com:
On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano
davide.itali...@gmail.com wrote:
Good evening folks.
During last days I've written a patch to add sandy bridge support to
hwpmc. Until now, the most recent Intel processor microarchitecture
supported was Westmere.
Testing is appreciated, in order to see if there's something that have
to be fixed.
You can find the diff here:
http://davit.altervista.rg/hwpmc_sandy_bridge.diff
I'd like to thanks a lot attilio@ that helped me to fix a bug and gnn@
and fabient@ for the useful suggestions.
Best
Davide
Sorry, bad link. It should be:
http://davit.altervista.org/hwpmc_sandy_bridge.diff
I can perform some small cleanups and likely test it too.
If Fabien or George can review it I'm fine with committing as long as
all that is settled.
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Fix types of arguments to dtrace syscall return probes
If there is anything I can do for kern/160307 or other Dtrace issue ,
please let me know
2011/11/8 Ryan Stone ryst...@gmail.com:
On Mon, Nov 7, 2011 at 9:16 AM, Paul Ambrose ambrose...@gmail.com wrote:
diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c
index bdff96e..2737860 100644
--- a/sys/kern/kern_ctf.c
+++ b/sys/kern/kern_ctf.c
@@ -90,7 +90,7 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
* ctfcnt to -1. See below.
*/
if (ef-ctfcnt 0)
- return (0);
+ return (EFTYPE);
/* Now check if we've already loaded the CTF data.. */
if (ef-ctfcnt 0) {
---
I have committed this as r227342. Thanks for the fix.
And I post another fix for the ${NORMAL_CTFCONVERT} issue, could you
check it for me?
Yes, I can take a look.
kern/160307, I check the /boot/kernel/kernel with ctfdump, and found
the kernel image has right ctf information, do you
have any idea?
Offhand, no. I'll try to find some time to look at your PRs.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Fix types of arguments to dtrace syscall return probes
Thank you for your work. I will give it a try in stable/9. I have
another two PR:
kern/160307 and bin/160275 that maybe you can help;
the reason of bin/160275 is complicated, but the fix for kernel crash
caused by module without ctf section(for example, nvidia.ko) missed
somthing
(my mistake)
in kern/kern_ctf.c
int link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
struct nameidata nd;
struct thread *td = curthread;
uint8_t ctf_hdr[CTF_HDR_SIZE];
#endif
int error = 0;
if (lf == NULL || lc == NULL)
return (EINVAL);
/* Set the defaults for no CTF present. That's not a crime! */
bzero(lc, sizeof(*lc));
#ifdef DDB_CTF
/*
* First check if we've tried to load CTF data previously and the
* CTF ELF section wasn't found. We flag that condition by setting
* ctfcnt to -1. See below.
*/
if (ef-ctfcnt 0)//second
time with same module,
return (0);
/* Now check if we've already loaded the CTF data.. */
if (ef-ctfcnt 0) {
/* We only need to load once. */
lc-ctftab = ef-ctftab;
lc-ctfcnt = ef-ctfcnt;
lc-symtab = ef-ddbsymtab;
lc-strtab = ef-ddbstrtab;
lc-strcnt = ef-ddbstrcnt;
lc-nsym = ef-ddbsymcnt;
lc-ctfoffp = (uint32_t **) ef-ctfoff;
lc-typoffp = (uint32_t **) ef-typoff;
lc-typlenp = ef-typlen;
return (0);
}
/*
* We need to try reading the CTF data. Flag no CTF data present
* by default and if we actually succeed in reading it, we'll
* update ctfcnt to the number of bytes read.
*/
ef-ctfcnt = -1;
-
fisrt time, set ctfcnt to -1, if module does not has ctf section, and
ef-ctfcnt does NOT update with a valid value(0) later,
then second time enter this function with same module(ef), previous
if (ef-ctfcnt 0)
return (0);// should not be 0 here
pass over first time ctf section check, I think we need another fix .
diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c
index bdff96e..2737860 100644
--- a/sys/kern/kern_ctf.c
+++ b/sys/kern/kern_ctf.c
@@ -90,7 +90,7 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
* ctfcnt to -1. See below.
*/
if (ef-ctfcnt 0)
- return (0);
+ return (EFTYPE);
/* Now check if we've already loaded the CTF data.. */
if (ef-ctfcnt 0) {
---
And I post another fix for the ${NORMAL_CTFCONVERT} issue, could you
check it for me?
kern/160307, I check the /boot/kernel/kernel with ctfdump, and found
the kernel image has right ctf information, do you
have any idea?
And thank you again for your work!
--
[PATCH] Fix kernel panics when using dtrace fbt return probes on i386
[PATCH] Fix types of arguments to dtrace syscall return probes
walltimestamp curpsinfo-pr_psargs has no args from Shawn Webb
latt...@gmail.com.
commit ec734d4fb07fec8d1b5fb8d1d4c8caa0fada4eea
Author: rstone rst...@freebsd.org
Replace fasttrap_copyout() with uwrite(). FreeBSD copyout() is not able to
write to the .text section of a process.
commit 83b04575eb8f73e557f245bb2814ac6db0a89696
Author: rstone rst...@freebsd.org
Fix the DTrace pid return trap interrupt vector. Previously we were using
31, but that vector is reserved.
2011/11/6 Ryan Stone ryst...@gmail.com:
Currently if you try to use the args[] array passed to a syscall
return probe, you get variables with the wrong type. This is because
the systrace implementation is currently using the same function to
provide the same argument types for both the entry and return probes,
which is completely wrong. For example:
# dtrace -v -l -n syscall::mmap:return
ID PROVIDER MODULE FUNCTION NAME
32159 syscall mmap return
Probe Description Attributes
Identifier Names: Private
Data Semantics: Private
Dependency Class: ISA
Argument Attributes
Identifier Names: Private
Data Semantics: Private
Dependency Class: ISA
Argument Types
args[0]: caddr_t
args[1]: size_t
args[2]: int
args[3]: int
args[4]: int
Re: config(8) does not add post-processing for source file with compile-with command in sys/conf/files
There are many other compile-with not started with ${NORMAL_C}, your
patch adds
${NORMAL_CTFCONVERT} to them too, which could not be suitable for this.
2011/10/19 Ryan Stone ryst...@gmail.com:
I have run into the same issue recently. I have been testing the
following patch(on 8.2-RELEASE) and it seems to have worked for me:
--- mkmakefile.c 11:09:30.0 -0400
+++ mkmakefile.c 2011-10-06 11:13:31.0 -0400
@@ -742,15 +742,16 @@
break;
}
snprintf(cmd, sizeof(cmd),
- ${%s_%c%s}\n.if defined(NORMAL_CTFCONVERT)
- !empty(NORMAL_CTFCONVERT)\n
- \t${NORMAL_CTFCONVERT}\n.endif, ftype,
+ ${%s_%c%s}\n, ftype,
toupper(och),
ftp-f_flags NOWERROR ? _NOWERROR : );
compilewith = cmd;
}
*cp = och;
- fprintf(f, \t%s\n\n, compilewith);
+ fprintf(f, \t%s\n, compilewith);
+ fprintf(f, .if defined(NORMAL_CTFCONVERT)
+ !empty(NORMAL_CTFCONVERT)\n
+ \t${NORMAL_CTFCONVERT}\n.endif\n\n);
}
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
config(8) does not add post-processing for source file with compile-with command in sys/conf/files
when I digged the a PR(bin/160275), I found in_proto.c and
if_ethersubr.c ( see sys/conf/files ) does not get
${NORMAL_CTFCONVERT} post-processing in Makefile
(/usr/obj/usr/src/sys/MYKERNEL/Makefile) generated by config(8), so
the objs does not contain ctf section
In /usr/src/usr.sbin/config/mkmakefile.c, line 746
}
compilewith = ftp-f_compilewith;
if (compilewith == 0) { // no compile-with
const char *ftype = NULL;
switch (ftp-f_type) {
case NORMAL:
ftype = NORMAL;
break;
case PROFILING:
if (!profiling)
continue;
ftype = PROFILE;
break;
default:
fprintf(stderr,
config: don't know rules for %s\n, np);
break;
}
// only add post-processing for source file without compile-with
snprintf(cmd, sizeof(cmd),
${%s_%c%s}\n\t@${NORMAL_CTFCONVERT}, ftype,
toupper(och),
ftp-f_flags NOWERROR ? _NOWERROR : );
compilewith = cmd;
}
*cp = och;
if (strlen(ftp-f_objprefix))
fprintf(f, \t%s $S/%s\n\n, compilewith, np);
else
fprintf(f, \t%s\n\n, compilewith);
}
}
I wonder whether it was NOT allowed to add post-processing to files
with compile-with, license or other issues?
if not a license issue, then I wonder if this fix is OK( I test it on
8-stable with gcc, and 9-stable with both gcc and clang)
diff --git a/usr.sbin/config/mkmakefile.c b/usr.sbin/config/mkmakefile.c
index 2372839..25a85de 100644
--- a/usr.sbin/config/mkmakefile.c
+++ b/usr.sbin/config/mkmakefile.c
@@ -767,6 +767,14 @@ do_rules(FILE *f)
ftp-f_flags NOWERROR ? _NOWERROR : );
compilewith = cmd;
}
+ //handle CTF issule with NORMAL_C and NORMAL_C_NOERROR
+ else if (!strncmp(compilewith, ${NORMAL_C,sizeof(${NORMAL_C))) {
+ snprintf(cmd, sizeof(cmd),
+%s\n\t@${NORMAL_CTFCONVERT}, compilewith);
+ compilewith = cmd;
+ }
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Strange ZFS filesystem corruption
On Oct 4, 2011, at 12:09 PM, Olivier Smedts wrote: 2011/10/3 Paul Mather p...@gromit.dlib.vt.edu: I know ZFS does not have a fsck utility (because it doesn't need one:), but does anyone know of any way of fixing this corruption short of destroying the pool, creating a new one, and restoring from backup? Is there some way of exporting and re-importing the pool that has the side-effect of doing some kind of fsck-like repairing of subtle corruption like this? But there is the ZFS debugger, zdb ! I can't really help you with that because I never had a corrupted zpool, but if you search on the lists for up to a year or so, you'll find some useful commands to inspect and destroy corrupted objects. Usage: zdb [-CumdibcsDvhL] poolname [object...] zdb [-div] dataset [object...] zdb -m [-L] poolname [vdev [metaslab...]] zdb -R poolname vdev:offset:size[:flags] zdb -S poolname zdb -l [-u] device zdb -C Dataset name must include at least one separator character '/' or '@' If dataset name is specified, only that dataset is dumped If object numbers are specified, only those objects are dumped Options to control amount of output: -u uberblock -d dataset(s) -i intent logs -C config (or cachefile if alone) -h pool history -b block statistics -m metaslabs -c checksum all metadata (twice for all data) blocks -s report stats on zdb's I/O -D dedup statistics -S simulate dedup to measure effect -v verbose (applies to all others) -l dump label contents -L disable leak tracking (do not load spacemaps) -R read and display block from a device Below options are intended for use with other options (except -l): -A ignore assertions (-A), enable panic recovery (-AA) or both (-AAA) -F attempt automatic rewind within safe range of transaction groups -U cachefile_path -- use alternate cachefile -X attempt extreme rewind (does not work with dataset) -e pool is exported/destroyed/has altroot/not in a cachefile -p path -- use one or more with -e to specify path to vdev dir -P print numbers parsable -t txg -- highest txg to use when searching for uberblocks Specify an option more than once (e.g. -bb) to make only that option verbose Default is to dump everything non-verbosely I tried your suggestion and ran the command zdb -ccv backups to try and check the consistency of the troublesome backups pool. This is what I ended up with: = Traversing all blocks to verify checksums and verify nothing leaked ... [[...]] leaked space: vdev 0, offset 0x900b5557600, size 82944 leaked space: vdev 0, offset 0x900b556e400, size 23040 leaked space: vdev 0, offset 0x900b5553a00, size 9216 leaked space: vdev 0, offset 0x900b5540800, size 23040 leaked space: vdev 0, offset 0x900b550ea00, size 16896 leaked space: vdev 0, offset 0x900b54e2c00, size 9216 leaked space: vdev 0, offset 0x900b50f5600, size 6144 leaked space: vdev 0, offset 0x900b558dc00, size 70656 leaked space: vdev 0, offset 0x900b5580400, size 44544 leaked space: vdev 0, offset 0x900b55bd000, size 82944 leaked space: vdev 0, offset 0x900b55d6200, size 15360 leaked space: vdev 0, offset 0x900b55dd400, size 33792 leaked space: vdev 0, offset 0x900b55d2c00, size 6144 leaked space: vdev 0, offset 0x900b55a0800, size 95232 leaked space: vdev 0, offset 0x900b55f5400, size 6144 leaked space: vdev 0, offset 0x900b5716c00, size 6144 leaked space: vdev 0, offset 0x900b56e8400, size 6144 leaked space: vdev 0, offset 0x900b573b800, size 6144 leaked space: vdev 0, offset 0x900b5748a00, size 10752 leaked space: vdev 0, offset 0x900b58b5e00, size 3072 leaked space: vdev 0, offset 0x900b589de00, size 6144 leaked space: vdev 0, offset 0x900b575fe00, size 7680 leaked space: vdev 0, offset 0x900b5734600, size 15360 leaked space: vdev 0, offset 0x900b55e8200, size 43008 leaked space: vdev 0, offset 0x900b58ca200, size 27648 leaked space: vdev 0, offset 0x900b591d600, size 3072 leaked space: vdev 0, offset 0x900b591fa00, size 12288 leaked space: vdev 0, offset 0x900b5904a00, size 6144 leaked space: vdev 0, offset 0x900b594f400, size 53760 leaked space: vdev 0, offset 0x900b5939200, size 3072 leaked space: vdev 0, offset 0x900b5960800, size 4608 leaked space: vdev 0, offset 0x900b5966e00, size 3072 leaked space: vdev 0, offset 0x900b5963200, size 9216 leaked space: vdev 0, offset 0x900b595de00, size 4608 leaked space: vdev 0, offset 0x900b5928400, size 3072 leaked space: vdev 0, offset 0x900c9a93200, size 4608 leaked space: vdev 0, offset 0x900c9a8d800, size 21504 leaked space: vdev 0, offset 0x900c9afa400, size 3072 leaked space: vdev 0, offset 0x900c9af4a00, size 21504 leaked space: vdev 0, offset 0x900b5977000, size 9216 leaked space: vdev 0, offset 0x900b58b7000, size 75264 leaked space: vdev 0, offset 0x900b5575600, size 38400
Re: Is there a step by step howto for dtrace on 9.0 ?
the wiki DTrace (http://wiki.freebsd.org/DTrace) is available and enough for being a HOWTO. 2011/10/9 Adrian Chadd adr...@freebsd.org Hi, the subject says it all - does anyone have a step by step howto for doing userland and kernel dtrace on 9.0? Thanks, Adrian ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Strange ZFS filesystem corruption
On Oct 5, 2011, at 9:03 AM, krad wrote: Have you dont the simple thing and checked to see if you have any weird whitespace in the dir names. Try using bash tab completion for the dir name. Also drop all non bash completion rules as these might be messing things up. I have seen odd characters in dirs cause much confusion in the past. I don't believe that is the problem in this case. An ls will list the file but ls -l reports no such file or directory: tape# ls 05DLAAdmin 07DLAAdmin tape# ls -l ls: 05DLAAdmin: No such file or directory total 3 drwxrws--- 4 500 501 4 Oct 3 11:53 07DLAAdmin tape# Plus, the rm -rf I tried (that failed) ought not to fall foul of such weird whitespace problems. Cheers, Paul. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Strange ZFS filesystem corruption
On Oct 3, 2011, at 6:19 PM, Artem Belevich wrote: On Mon, Oct 3, 2011 at 11:21 AM, Paul Mather p...@gromit.dlib.vt.edu wrote: = The pool itself reports no errors. I performed a scrub on the pool yet this bizarre filesystem corruption persists: = tape# zpool status backups pool: backups state: ONLINE scan: scrub repaired 15K in 7h33m with 0 errors on Sat Oct 1 19:22:35 2011 The pool *did* report 15K errors that it was able to repair. I'd start with testing your RAM with memtest86 or memtest86+. ZFS errors without reported checksum errors may be the sign of bad memory. I.e. data gets corrupted before ZFS gets to calculate checksum and later invalid data with valid checksum gets written to disk. Because this machine has ECC RAM, I checked the BIOS logs for ECC errors (the BIOS is set to log them) and there are no ECC errors logged. If the RAM were going bad, I would expect it to leave some kind of trace in the BIOS log. Do uncorrectable ECC errors get logged as MCEs under FreeBSD 9? I've never noticed any problems when doing a make -j8 buildworld on this machine, either. Cheers, Paul.___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Strange ZFS filesystem corruption
default backups/storage recordsize128K default backups/storage mountpoint/backups/storage default backups/storage sharenfs offdefault backups/storage checksum fletcher4 local backups/storage compression gzip-9 local backups/storage atime on default backups/storage devices on default backups/storage exec offlocal backups/storage setuidon default backups/storage readonly offdefault backups/storage jailedoffdefault backups/storage snapdir hidden default backups/storage aclmode discarddefault backups/storage aclinheritrestricted default backups/storage canmount on default backups/storage xattr offtemporary backups/storage copies1 default backups/storage version 5 - backups/storage utf8only off- backups/storage normalization none - backups/storage casesensitivity sensitive - backups/storage vscan offdefault backups/storage nbmandoffdefault backups/storage sharesmb offdefault backups/storage refquota none default backups/storage refreservationnone default backups/storage primarycache alldefault backups/storage secondarycachealldefault backups/storage usedbysnapshots 0 - backups/storage usedbydataset 4.26T - backups/storage usedbychildren0 - backups/storage usedbyrefreservation 0 - backups/storage logbias latencydefault backups/storage dedup offdefault backups/storage mlslabel - backups/storage sync standard default backups/storage refcompressratio 1.51x - = I know ZFS does not have a fsck utility (because it doesn't need one:), but does anyone know of any way of fixing this corruption short of destroying the pool, creating a new one, and restoring from backup? Is there some way of exporting and re-importing the pool that has the side-effect of doing some kind of fsck-like repairing of subtle corruption like this? Cheers, Paul. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] dtrace crashes when trying to trace fbt probes
);
VFS_UNLOCK_GIANT(vfslocked);
if (hdr != NULL)
free(hdr, M_LINKER);
if (shdr != NULL)
free(shdr, M_LINKER);
if (shstrtab != NULL)
free(shstrtab, M_LINKER);
if (ctftab != NULL)
free(ctftab, M_LINKER);
if (raw != NULL)
free(raw, M_LINKER);
#else
error = EOPNOTSUPP;
#endif
return (error);
}
Here is patch to fix the missing check
..
diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c
index 758ad81..b78e474 100644
--- a/sys/kern/kern_ctf.c
+++ b/sys/kern/kern_ctf.c
@@ -164,8 +164,12 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
* section names aren't present, then we can't locate the
* .SUNW_ctf section containing the CTF data.
*/
-if (hdr-e_shstrndx == 0 || shdr[hdr-e_shstrndx].sh_type !=
SHT_STRTAB)
+if (hdr-e_shstrndx == 0 || shdr[hdr-e_shstrndx].sh_type !=
SHT_STRTAB) {
+
+printf(%s(%d):e_shstrndx is %d, sh_type is %d\n, lf-pathname,
__LINE__,
+hdr-e_shstrndx, shdr[hdr-e_shstrndx].sh_type);
goto out;
+}
/* Allocate memory to buffer the section header strings. */
if ((shstrtab = malloc(shdr[hdr-e_shstrndx].sh_size, M_LINKER,
@@ -187,8 +191,12 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
break;
/* Check if the CTF section wasn't found. */
-if (i = hdr-e_shnum)
+if (i = hdr-e_shnum) {
+error = EFTYPE;
+printf(%s(%d): module %s has no .SUNW_ctf section\n, __func__,
+__LINE__, lf-pathname);
goto out;
+}
/* Read the CTF header. */
if ((error = vn_rdwr(UIO_READ, nd.ni_vp, ctf_hdr, sizeof(ctf_hdr),
@@ -197,12 +205,20 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
goto out;
/* Check the CTF magic number. (XXX check for big endian!) */
-if (ctf_hdr[0] != 0xf1 || ctf_hdr[1] != 0xcf)
+if (ctf_hdr[0] != 0xf1 || ctf_hdr[1] != 0xcf) {
+error = EFTYPE;
+printf(%s(%d): module %s has wrong format\n, __func__, __LINE__,
+lf-pathname);
goto out;
+}
/* Check if version 2. */
-if (ctf_hdr[2] != 2)
+if (ctf_hdr[2] != 2) {
+error = EFTYPE;
+printf(%s(%d): module %s CTF format version is %d\n, __func__,
__LINE__,
+lf-pathname, ctf_hdr[2]);
goto out;
+}
/* Check if the data is compressed. */
if ((ctf_hdr[3] 0x1) != 0) {
.
2011/9/26 Paul Ambrose ambrose...@gmail.com
Hi, Ryan, I came across the similar problem on 8-stable when I run
# dtrace -lv
the panic message says:
page fault just happened at fbt.c
if (*lc.ctfoffp == NULL) { // page fault
/*
* Initialise the CTF object and function symindx to
* byte offset array.
*/
if (fbt_ctfoff_init(ctl, lc) != 0)
return;
/* Initialise the CTF type to byte offset array. */
if (fbt_typoff_init(lc) != 0)
return;
}
And I came across the similar problem on 9-current only once, but when I
recompile the kernel,
it does not reproduce. I will try your patch on 8-stable, but could you
tell me where did you meet
the problem, and what is your module without CTF data?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] dtrace crashes when trying to trace fbt probes
sorry, I miss a check, here is the patch
.
diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c
index 758ad81..6beefcc 100644
--- a/sys/kern/kern_ctf.c
+++ b/sys/kern/kern_ctf.c
@@ -164,8 +164,14 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
* section names aren't present, then we can't locate the
* .SUNW_ctf section containing the CTF data.
*/
-if (hdr-e_shstrndx == 0 || shdr[hdr-e_shstrndx].sh_type !=
SHT_STRTAB)
+if (hdr-e_shstrndx == 0 || shdr[hdr-e_shstrndx].sh_type !=
SHT_STRTAB) {
+
+error = EFTYPE;
+printf(%s(%d): module %s e_shstrndx is %d, sh_type is %d\n,
__func__,
+__LINE__, lf-pathname, hdr-e_shstrndx,
+shdr[hdr-e_shstrndx].sh_type);
goto out;
+}
/* Allocate memory to buffer the section header strings. */
if ((shstrtab = malloc(shdr[hdr-e_shstrndx].sh_size, M_LINKER,
@@ -187,8 +193,12 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
break;
/* Check if the CTF section wasn't found. */
-if (i = hdr-e_shnum)
+if (i = hdr-e_shnum) {
+error = EFTYPE;
+printf(%s(%d): module %s has no .SUNW_ctf section\n, __func__,
+__LINE__, lf-pathname);
goto out;
+}
/* Read the CTF header. */
if ((error = vn_rdwr(UIO_READ, nd.ni_vp, ctf_hdr, sizeof(ctf_hdr),
@@ -197,12 +207,20 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
goto out;
/* Check the CTF magic number. (XXX check for big endian!) */
-if (ctf_hdr[0] != 0xf1 || ctf_hdr[1] != 0xcf)
+if (ctf_hdr[0] != 0xf1 || ctf_hdr[1] != 0xcf) {
+error = EFTYPE;
+printf(%s(%d): module %s has wrong format\n, __func__, __LINE__,
+lf-pathname);
goto out;
+}
/* Check if version 2. */
-if (ctf_hdr[2] != 2)
+if (ctf_hdr[2] != 2) {
+error = EFTYPE;
+printf(%s(%d): module %s CTF format version is %d\n, __func__,
__LINE__,
+lf-pathname, ctf_hdr[2]);
goto out;
+}
/* Check if the data is compressed. */
if ((ctf_hdr[3] 0x1) != 0) {
2011/9/29 Paul Ambrose ambrose...@gmail.com
In 8-stable, WITH_CTF=1 configure item is enabled in command line, not in
make.conf, so when I build kernel module out of /usr/src source tree, such
as x11/nvidia-driver, I forgot to use WITH_CTF=1 and nvidia.ko was built
without .SUNW_ctf section. However, when I run:
#dtrace -lv
trigger the NULL pointer dereference at: /usr/src/sys/cddl/dev/fbt/fbt.c
..
if (*lc.ctfoffp == NULL) { // page fault here
/*
* Initialise the CTF object and function symindx to
* byte offset array.
*/
if (fbt_ctfoff_init(ctl, lc) != 0)
return;
/* Initialise the CTF type to byte offset array. */
if (fbt_typoff_init(lc) != 0)
return;
}
the reason is at /usr/src/sys/kern/kern_ctf.c:
..
/* Search for the section containing the CTF data. */
for (i = 0; i hdr-e_shnum; i++)
if (strcmp(.SUNW_ctf, shstrtab + shdr[i].sh_name) == 0)
break;
/* Check if the CTF section wasn't found. */
if (i = hdr-e_shnum) //here we found no ctf data, but NOT
update the varible error
goto out; // see label out
/* Read the CTF header. */
if ((error = vn_rdwr(UIO_READ, nd.ni_vp, ctf_hdr, sizeof(ctf_hdr),
shdr[i].sh_offset, UIO_SYSSPACE, IO_NODELOCKED, td-td_ucred,
NOCRED, resid, td)) != 0)
goto out;
/* Check the CTF magic number. (XXX check for big endian!) */
if (ctf_hdr[0] != 0xf1 || ctf_hdr[1] != 0xcf)
goto out;
/* Check if version 2. */
if (ctf_hdr[2] != 2)
goto out;
/* Check if the data is compressed. */
if ((ctf_hdr[3] 0x1) != 0) {
uint32_t *u32 = (uint32_t *) ctf_hdr;
/*
* The last two fields in the CTF header are the offset
* from the end of the header to the start of the string
* data and the length of that string data. se this
* information to determine the decompressed CTF data
* buffer required.
*/
sz = u32[CTF_HDR_STRTAB_U32] + u32[CTF_HDR_STRLEN_U32] +
sizeof(ctf_hdr);
/*
* Allocate memory for the compressed CTF data, including
* the header (which isn't compressed).
*/
if ((raw = malloc(shdr[i].sh_size, M_LINKER, M_WAITOK)) == NULL) {
error = ENOMEM
[PATCH] dtrace crashes when trying to trace fbt probes
Hi, Ryan, I came across the similar problem on 8-stable when I run
# dtrace -lv
the panic message says:
page fault just happened at fbt.c
if (*lc.ctfoffp == NULL) { // page fault
/*
* Initialise the CTF object and function symindx to
* byte offset array.
*/
if (fbt_ctfoff_init(ctl, lc) != 0)
return;
/* Initialise the CTF type to byte offset array. */
if (fbt_typoff_init(lc) != 0)
return;
}
And I came across the similar problem on 9-current only once, but when I
recompile the kernel,
it does not reproduce. I will try your patch on 8-stable, but could you tell
me where did you meet
the problem, and what is your module without CTF data?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: http://www.freebsd.org/marketing/os-comparison.html
I heard of that news, but I didn't realize that web site was managed by John Birrell. Now, DTrace is not feature-complete and stable, I don't think it is suitable to http://www.freebsd.org/doc/handbook/dtrace.html, but to http://wiki.freebsd.org/DTrace, and people can easily update it 2011/8/31 Craig Rodrigues rodr...@crodrigues.org Hi, http://dtrace.what-creek.com no longer exists, because sadly, the author of that web page (John Birrell) is no longer with us: http://lists.freebsd.org/pipermail/freebsd-announce/2009-November/001284.html There are some other documentation pages available for DTrace on FreeBSD: http://wiki.freebsd.org/DTrace http://www.freebsd.org/doc/handbook/dtrace.html If you have ideas for how to enhance this documentation, you should submit your ideas. The freebsd-...@freebsd.org mailing list is a good place to start. -- Craig Rodrigues rodr...@crodrigues.org On Tue, Aug 30, 2011 at 9:21 PM, Paul Ambrose ambrose...@gmail.com wrote: BTW, I am a Chinese and live in Chengdu, China, I can't have access to dtrace.what-creek.com because of GFW, so maybe I miss something. I started to use FreeBSD about 2.5 year ago, and learn FreeBSD kernel recently because of DTrace. I like it and I hope I can do something more ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: http://www.freebsd.org/marketing/os-comparison.html
I do not believe the current status of DTrace is appropriate for promoting 1. DTrace is an experimental function or Semi-finished products. The kernel dtrace support is ok, but the userland support is far from completion(at least the pid provider has many bugs) 2 the FreeBSD implementation is different from Solaris/Mac OS X. The DTraceToolkit, which has many amazing feature, can not 100% works on FreeBSD, and there is no doc to identify the difference. 3 There is a missing feature list about DTrace, but no schedule list about when to fix it. 2011/8/30 Sergey Kandaurov pluk...@gmail.com On 30 August 2011 13:13, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: On 08/30/11 09:29, Hans Petter Selasky wrote: On Monday 29 August 2011 21:58:29 Volodymyr Kostyrko wrote: 27.08.2011 22:13, Hartmann, O. wrote: This website should be brushed up or taken offline! It seems full of vintage stuff from glory days. http://www.freebsd.org/marketing/os-comparison.html I think this one would better look like list of major features with os comparison, like: = Networking = * IPv6: major support, best stack around. * SCTP: full kernel implementation, still no userland support (i.e. ssh doesn't work over sctp by default yet). = Data storage = * ZFS: full support, datasets, compression, dedup, other stuff. Linux has LVM (?features...) and btrfs (?unstable.. ?features..), Windows has dynamic disks since XP (?features). = SMP = * (?something about comparing other shedulers with SCHED_ULE), (?some rt stuff), (?some comparison with other interesting shedulers, like DragonflyBSD and QNX). And USB. I believe there are significant changes in the USB subsystems which those who are making performance benchmarks completely fail to mention. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org What's about DTrace? = Development/System Profiling = * DTrace: Some notes of the Kernel Gurus what this could mean for performance profiling and development = Licensing Model = * Some striking comments on the advantage for companies or interested people of the BSD-like licensing model over the GPLv3 on which Linux is based now and which has serious implications for those who wants to develop and sell software developed on/with GNU stuff. it would be very honest, if we do not only emphasize only the pros. BSD came from the academic environment, that was where I met it the first time and I appreciated the way things were developed and 'sloppyness' was a nogo. So we should keep it up and a serious and honest set of contraru points for all compared OS should be appreciable. Does the VM of FreeBSD still have advantges (measurable) over Linux? [Taking random email.] I think we could merge the $subj web page with this one (which is more actual, as of 7.0): http://www.freebsd.org/features.html -- wbr, pluknet ___ freebsd-performa...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to freebsd-performance-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: http://www.freebsd.org/marketing/os-comparison.html
I can help, I just changed my job and get more spare time. Currently I can help write doc and test. There is much documentation about DTrace ( thanks Sun), but none of these describes the technical details of FreeBSD DTrace implementation, so I think we can start with this. 1 write doc about what we have done. The kernel DTrace is quite stable, but compared to Solaris, what else do we miss, what Solaris has but we do not, whether we implement all the builtin var and function, if not, do we have other alternative?. I come across problems with DTrace, but I don't know whether it is a bug or has not been supported 2 write more examples about how to debug kernel with DTrace on FreeBSD, I think these example can let others know what we can do with DTrace. BTW, I am a Chinese and live in Chengdu, China, I can't have access to dtrace.what-creek.com because of GFW, so maybe I miss something. I started to use FreeBSD about 2.5 year ago, and learn FreeBSD kernel recently because of DTrace. I like it and I hope I can do something more 2011/8/31 Andriy Gapon a...@freebsd.org on 30/08/2011 18:39 Andriy Gapon said the following: 4. There is a missing developer/maintainer for DTrace on FreeBSD. I probably should clarify this point: it doesn't have to be *the* maintainer, a collective maintainer is also perfect. Thus, contributions are very welcome. Nevertheless the kernel DTrace is quite usable and useful for kernel debugging. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Request for review/testing: switching the default installer
On Wed, Mar 02, 2011 at 09:36:58AM -0600, Nathan Whitehorn wrote: On 02/28/11 09:20, John Baldwin wrote: On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote: There are some changes to the distribution format involved in this patch, which are outlined below, and about which I would also appreciate feedback: - The src tree is not split up into pieces (e.g. ssbin) as with sysinstall I would at least like to have src split up into two pieces: 1) would be equivalent of sbase and ssys of old distributions, so you could choose to just install kernel sources along with the top-level Makefile bits to build kernels. I commonly install this subset on production machines so I can install a custom kernel in a pinch. 2) would be everything else in the source tree. This is a little bit tricky, since it involves inter-distribution dependencies which don't currently exist (e.g. you need sbase for ssys to be useful, and for severythingelse to be useful). I suppose that the top-level Makefile bits are small and could end up in both archives, where one can overwrite the other with the same thing. Would that solve your problem? -Nathan Why not put the toplevel Makefiles, README and perhaps COPYRIGHT and MAINTAINERS file into base? This way there are no inter-dependencies between src parts, /usr/src will consume only a modest bit of space in base but documents wat ont would be able to do is sbase/ssys were installed. Regards, Paul Schenkeveld ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cardbus and kldunload issue
On Sat, Feb 26, 2011 at 4:25 PM, Bernhard Schmidt bschm...@freebsd.org wrote: Hi, while working on a wireless driver for a Cardbus card I stumbled over an issue which bugs me quite a bit. The device: % none3@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814 rev=0x01 hdr=0x00 Loading the module attaches nicely to the device: # kldload if_ral % ral0: Ralink Technology RT2560 mem 0xf480-0xf4801fff irq 16 at device 0.0 on cardbus0 % ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 % ral0: [ITHREAD] # pciconf -l % ral0@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814 rev=0x01 hdr=0x00 Though, kldunload doesn't detach the device, it doesn't even call the module's detach function. # kldunload if_ral # pciconf -l % ral0@pci0:22:0:0: class=0x028000 card=0x107f1043 chip=0x02011814 rev=0x01 hdr=0x00 # kldstat % Id Refs Address Size Name % 1 27 0x8010 e640a0 kernel # ifconfig ral0 % ral0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 2290 % ether 00:0e:a6:a6:1b:70 % media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) % status: no carrier And of course trying to use the device at that point will result in instant panics. Playing around a bit I've noticed that changing the bus name in: % DRIVER_MODULE(ral, pci, ral_pci_driver, ral_devclass, 0, 0); from pci to cardbus makes a big difference. On module unload the detach function is then called as expected. So, question is, are we doing some too strict checks on module unload while matching the bus? Or is this expected behavior and the drivers are supposed to indiciated that they support both pci and cardbus? I don't see the later anywhere in tree. There is MODULE_DEPEND(), if_ndis depends on pccard, pci and usb modules and use both MODULE_DEPEND() and DRIVER_MODULE() with them. If I'm not mistaken pccard depends on cardbus. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFR] a small change of ifconfig(8)
On 11/25/10, Weongyo Jeong weongyo.je...@gmail.com wrote: Hello all, I'm sending this email to check whether my approach is reasonable that I added 2 line into ifconfig(8) to skip IFT_USB interfaces as follows: + if (sdl != NULL sdl-sdl_type == IFT_USB) + continue; And as additionally I added two changes of USB pf to call if_up(ifp) / if_down(ifp) explicitly to UP usbus interfaces though normally it always should be called through user ioctl calls. The reason why I make this patch is that I encountered a side-effect output from ifconfig(8) after USB packet filter is committed. Yes usbus interfaces are printed. Please give me some hints whether the patch is reasonable. If it's reasonable, is there other tools which I should make patches? Currently ifconfig will with special rc.conf configuration hang after boot making multiuser mode impossible to happen. Perhaps ifconfig tries to do something fancy with usbus interfaces. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Broadcom BCM4310 USB Controller (Wifi)
On 11/22/10, Alberto Villa avi...@freebsd.org wrote: On Wednesday 17 November 2010 10:57:34 Paul B Mahol wrote: Please use ndis5 branch. master branch is in heavy development. CURRENT branch just blindly (and badly) track code on FreeBSD CURRENT. ok. unfortunately in this test i made an error and just saw that... `-- git status # On branch ndis5 # Your branch is ahead of 'origin/ndis5' by 13 commits. i hope it's ok for this time Git status should be empty. Just pull again. Or clone repo again, or do not use git and fetch tar.gz from site. I did some changes with forced rebase so that happened. When you say what you did be more specific, like are you are using i386 or amd64, and so on. FreeBSD echo.hoth 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r215448M: Thu Nov 18 08:34:00 CET 2010 r...@echo.hoth:/usr/obj/usr/src/sys/HPDV6 amd64 my kernel configuration file is a GENERIC trimmed down to the minimum (so that everything possible is loaded as a module) amd64, I see. And another broadcom card on CURRENT and on amd64 just panics, but this is another driver. Can you post link to your driver? For using code in branch master and ndis5, you will need to reinstall ndisgen and ndiscvt from git repo and do not use one from FreeBSD world. This also means you will need to regenerate miniport module with new ndiscvt ndisgen because interface have changed slightly. i did it, and here you are the results: http://pastebin.ca/1998450 http://pastebin.ca/1998454 Why it picked MAC first time without problems, otherwise ndis0 would never attach, and second time it reports error? For a moment disable wpa_supplicant in your rc.conf. And try to get scan results via ifconfig(8). like this: # ifconfig wlan0 destroy # ifconfig wlan create wlandev ndis0 # ifconfig wlan0 up # ifconfig wlan0 list scan And upload relevant dmesg output (ndis/NDIS lines) somewhere. And/or contact me off-list. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Broadcom BCM4310 USB Controller (Wifi)
On 11/22/10, Paul B Mahol one...@gmail.com wrote: On 11/22/10, Alberto Villa avi...@freebsd.org wrote: On Wednesday 17 November 2010 10:57:34 Paul B Mahol wrote: Please use ndis5 branch. master branch is in heavy development. CURRENT branch just blindly (and badly) track code on FreeBSD CURRENT. ok. unfortunately in this test i made an error and just saw that... `-- git status # On branch ndis5 # Your branch is ahead of 'origin/ndis5' by 13 commits. i hope it's ok for this time Git status should be empty. Just pull again. Or clone repo again, or do not use git and fetch tar.gz from site. I did some changes with forced rebase so that happened. When you say what you did be more specific, like are you are using i386 or amd64, and so on. FreeBSD echo.hoth 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r215448M: Thu Nov 18 08:34:00 CET 2010 r...@echo.hoth:/usr/obj/usr/src/sys/HPDV6 amd64 my kernel configuration file is a GENERIC trimmed down to the minimum (so that everything possible is loaded as a module) amd64, I see. And another broadcom card on CURRENT and on amd64 just panics, but this is another driver. Can you post link to your driver? For using code in branch master and ndis5, you will need to reinstall ndisgen and ndiscvt from git repo and do not use one from FreeBSD world. This also means you will need to regenerate miniport module with new ndiscvt ndisgen because interface have changed slightly. i did it, and here you are the results: http://pastebin.ca/1998450 http://pastebin.ca/1998454 Why it picked MAC first time without problems, otherwise ndis0 would never attach, and second time it reports error? For a moment disable wpa_supplicant in your rc.conf. And try to get scan results via ifconfig(8). like this: # ifconfig wlan0 destroy # ifconfig wlan create wlandev ndis0 # ifconfig wlan0 up # ifconfig wlan0 list scan And upload relevant dmesg output (ndis/NDIS lines) somewhere. And/or contact me off-list. I managed to fix panic on amd64 for driver I'm using. So try the latest version. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: net.link.log_link_state_change broken?
On 11/19/10, Paul B Mahol one...@gmail.com wrote: On 11/18/10, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On Tue, 2 Nov 2010, Paul B Mahol wrote: Hi, It appears we do not log such events anymore (at least with wlan devices) in console. I set this sysctl to 0 via sysctl.conf, if I set it to 1, nothing will change. Because I had loging disabled for very long time I encountered this problem just now. not sure. Might be, might not be. Have you further looked into this? I at least see: ./net80211/ieee80211_freebsd.c: if_link_state_change(ifp, LINK_STATE_UP); ./net80211/ieee80211_freebsd.c: if_link_state_change(ifp, LINK_STATE_DOWN); That part is not problematic, klog part is. Messages of link state changes are not available in console but are available in klog and in console once you open it with cat. Reading comment it appears that logic is inverted in code. kern.consmute=0 caused link state change to never appear (even in dmesg) ... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: net.link.log_link_state_change broken?
On 11/21/10, Paul B Mahol one...@gmail.com wrote: On 11/19/10, Paul B Mahol one...@gmail.com wrote: On 11/18/10, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On Tue, 2 Nov 2010, Paul B Mahol wrote: Hi, It appears we do not log such events anymore (at least with wlan devices) in console. I set this sysctl to 0 via sysctl.conf, if I set it to 1, nothing will change. Because I had loging disabled for very long time I encountered this problem just now. not sure. Might be, might not be. Have you further looked into this? I at least see: ./net80211/ieee80211_freebsd.c: if_link_state_change(ifp, LINK_STATE_UP); ./net80211/ieee80211_freebsd.c: if_link_state_change(ifp, LINK_STATE_DOWN); That part is not problematic, klog part is. Messages of link state changes are not available in console but are available in klog and in console once you open it with cat. Reading comment it appears that logic is inverted in code. kern.consmute=0 caused link state change to never appear (even in dmesg) ... ^kern.consmute=1 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: tmpfs out of space (ZFS related?)
On Sun, Nov 21, 2010 at 10:42 PM, Ivan Voras ivo...@freebsd.org wrote: On 11/21/10 23:19, Eir Nym wrote: On 22 November 2010 01:00, Eir Nymeir...@gmail.com wrote: On 22 November 2010 00:47, Bruce Cranbr...@cran.org.uk wrote: On Mon, 22 Nov 2010 00:43:03 +0300 Eir Nymeir...@gmail.com wrote: Which type of MFS do you use? I think you shold use swap-backed for your /tmp, not malloc-based. Last type is only for in-kernel file system. It's tmpfs(5), not md(4). I wonder if you can create FIFO and sockets with md(4). md(4) is geometry, not filesystem. md is a GEOM class which presents several types of devices backed by virtual memory. You can create file systems on top of those and mount them. The downside is that each of those layers has its own copy of the original data (and them some). tmpfs OTOH is a real memory file system, without the need for a backing device, and it is more efficient with respect to data copies (not perfect - it still AFAIK has to maintain something like 2 copies). AFAIK, if this was ever correct it is not any more. Data copies can mean anything. I use 1.5 GB file in tmpfs on 2GB RAM and 0B SWAP without problems. tmpfs(5) doesn't support this file types as I can see in FreeBSD source code. Maybe it is handled by default code, but they are supported. I have used tmpfs extensively for the last few years for mostly static servers (i.e. /tmp contains some sockets, a small number of short-lived temporary files, etc) - and it so far worked very well. This is actually the first time it failed me in some way. It can be anything: overflow, race, memory corruption ... Find way to reproduce it 100%. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: net.link.log_link_state_change broken?
On 11/18/10, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On Tue, 2 Nov 2010, Paul B Mahol wrote: Hi, It appears we do not log such events anymore (at least with wlan devices) in console. I set this sysctl to 0 via sysctl.conf, if I set it to 1, nothing will change. Because I had loging disabled for very long time I encountered this problem just now. not sure. Might be, might not be. Have you further looked into this? I at least see: ./net80211/ieee80211_freebsd.c: if_link_state_change(ifp, LINK_STATE_UP); ./net80211/ieee80211_freebsd.c: if_link_state_change(ifp, LINK_STATE_DOWN); That part is not problematic, klog part is. Messages of link state changes are not available in console but are available in klog and in console once you open it with cat. Reading comment it appears that logic is inverted in code. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: loading if_bfe after boot
On Fri, Nov 19, 2010 at 1:29 AM, Pyun YongHyeon pyu...@gmail.com wrote: On Sat, Oct 30, 2010 at 09:19:06PM -0700, Pyun YongHyeon wrote: On Sat, Oct 30, 2010 at 5:40 PM, Paul B Mahol one...@gmail.com wrote: Hi, Loading if_bfe module after boot hangs machine, it works/attach fine from loader. Tell me if you need bt. Yes, I want to see the back trace. I think it was fixed in HEAD(r215348) and MFCed to stable/8 and stable/7. Of course it did. Otherwise I would scream on list ;) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Broadcom BCM4310 USB Controller (Wifi)
On 11/17/10, Alberto Villa avi...@freebsd.org wrote: On Mon, Nov 15, 2010 at 2:41 PM, Paul B Mahol one...@gmail.com wrote: Feel free to test code at: gitorious.org/NDISulator github.com/richardpl/NDISulator The code is developed on CURRENT. But with small changes it can be compiled on STABLE too. thanks! i've applied a checkout of last night to current. i can load the module after boot, but the panic is still there when i unload or load on boot, and wpa_supplicant fails to work (see attached log) Just now I have only one tester (and that is without counting me). consider me as the third one :) Please use ndis5 branch. master branch is in heavy development. CURRENT branch just blindly (and badly) track code on FreeBSD CURRENT. When you say what you did be more specific, like are you are using i386 or amd64, and so on. When testing, enable debug.bootverbose, and debug.ndis sysctl before loading miniport module. [miniport module is module you created with ndisgen(8)] Do not load miniport module(s) during boot(from loader), if it ever worked it was big luck. [Even on Windows, drivers are loaded after boot.] Actually drivers can be loaded but we must be extra carefull what to call during boot and what to call after boot. For using code in branch master and ndis5, you will need to reinstall ndisgen and ndiscvt from git repo and do not use one from FreeBSD world. This also means you will need to regenerate miniport module with new ndiscvt ndisgen because interface have changed slightly. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Broadcom BCM4310 USB Controller (Wifi)
On 11/15/10, Alberto Villa avi...@freebsd.org wrote: On Wed, Oct 27, 2010 at 3:36 PM, Paul B Mahol one...@gmail.com wrote: Currently amd64 is broken with some/most drivers. Drivers appears to use fpu registers. I dunno how it ever worked, probably original developer(s) never encountered drivers which use fpu registers. I will probably fix amd64 support in this year. so, i've tried the ndis driver with amd64 and it paniced, as you said. do you have any idea on when you're gonna fix this? i need to know if i can keep amd64 and wait for a fix (in short time) or if i have to install i386 temporarily... Feel free to test code at: gitorious.org/NDISulator github.com/richardpl/NDISulator The code is developed on CURRENT. But with small changes it can be compiled on STABLE too. Just now I have only one tester (and that is without counting me). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ctrl-alt-delete in syscons pause/scrollback mode breaks system
On 11/6/10, Bruce Cran br...@cran.org.uk wrote: Today I came back to my computer and realised I'd left ttyv0 in history/scrollback mode, with scroll-lock enabled. To see what would happen I pressed Ctrl-Alt-Delete to reboot and was surprised to see that it seemed to get partway through the process but it never rebooted: the other ttys were killed and I could still break into the debugger but otherwise the system was unresponsive. Trying to repeat it after rebooting I ended up with a system that won't even break into the debugger. Is this expected? Last issue, was reported my me long ago and only workaround was commited, which actually did not solved problem for me. I'm still looking forward for complete syscons rewrite. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: invalid PDPE on recend amd64
On 11/6/10, Jia-Shiun Li jiash...@gmail.com wrote: Hi, I got a similar panic on amd64. Looking into the source it hit KASSERT((base (len - 1))) in pmap_demote_DMAP(). I replaced it with a printf to see what triggered the assertion and here is the output. Combined with memcontrol output 'bogus' keyword it seems buggy BIOS violated some kind of spec and caused this. Is it fatal? It looks fine on my machine without the assertion. Send uname output. The fix for this issue got commited few days ago. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
net.link.log_link_state_change broken?
Hi, It appears we do not log such events anymore (at least with wlan devices) in console. I set this sysctl to 0 via sysctl.conf, if I set it to 1, nothing will change. Because I had loging disabled for very long time I encountered this problem just now. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wpa_supplicant gets points for trying, I suppose....
On 11/1/10, David Wolfskill da...@catwhisker.org wrote: FreeBSD 9.0-CURRENT #31 r214621M Nov 1 15:09:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:10:10 d130 last message repeated 3 times Nov 1 15:10:50 d130 last message repeated 4 times ... Nov 1 15:11:00 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:11:10 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:20 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:11:30 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:50 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:12:10 d130 last message repeated 2 times Nov 1 15:14:10 d130 last message repeated 12 times I have the switch on this laptop in position to disable the wireless device (iwn(4)). Is there some way wpa_supplicant (or something) might be able to recognize that this is a pointless exercise? Well iwn could bring device down when radio is turned off and bring it up when radio is turned on ??? I don't recall stable/8 doing this, though I could be wrong. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: invalid PDPE on recend amd64
Hi, Booting amd64 kernel panic in pmap_demote_DMAP(): invalid PDPE This is on: Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #1 r214542+ac89f9b: Sat Oct 30 09:40:45 UTC 2010 root@:/usr/obj/usr/src/sys/kernel i386 CPU: Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz (1662.54-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6f2 Family = 6 Model = f Stepping = 2 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2087346176 (1990 MB) ACPI APIC Table: HP 30A2 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard acpi0: HPQOEM SLIC-MPC on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: invalid PDPE on recend amd64
On 10/30/10, Andriy Gapon a...@icyb.net.ua wrote: on 30/10/2010 17:43 Paul B Mahol said the following: Hi, Booting amd64 kernel panic in pmap_demote_DMAP(): invalid PDPE This is on: Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #1 r214542+ac89f9b: Sat Oct 30 09:40:45 UTC 2010 root@:/usr/obj/usr/src/sys/kernel i386 amd64 or i386? That is working i386 kernel, I can send bt of amd64 kernel as picture. CPU: Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz (1662.54-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6f2 Family = 6 Model = f Stepping = 2 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2087346176 (1990 MB) ACPI APIC Table: HP 30A2 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard acpi0: HPQOEM SLIC-MPC on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed It seems that the panic happens at the stage where you should be able to enter ddb and obtain a backtrace at the very least, after adding DDB option to your kernel. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: invalid PDPE on recend amd64
On 10/30/10, Paul B Mahol one...@gmail.com wrote: On 10/30/10, Andriy Gapon a...@icyb.net.ua wrote: on 30/10/2010 17:43 Paul B Mahol said the following: Hi, Booting amd64 kernel panic in pmap_demote_DMAP(): invalid PDPE This is on: Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #1 r214542+ac89f9b: Sat Oct 30 09:40:45 UTC 2010 root@:/usr/obj/usr/src/sys/kernel i386 amd64 or i386? That is working i386 kernel, I can send bt of amd64 kernel as picture. CPU: Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz (1662.54-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6f2 Family = 6 Model = f Stepping = 2 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2087346176 (1990 MB) ACPI APIC Table: HP 30A2 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard acpi0: HPQOEM SLIC-MPC on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed It seems that the panic happens at the stage where you should be able to enter ddb and obtain a backtrace at the very least, after adding DDB option to your kernel. panic: pmap_demote_DMAP: Invalid PDPE cpuid=0 KDB: enter: panic: [ thread pid 0 tid .. Stopped at .. db bt Tracing pid 0 .. kdb_enter() .. panic() .. pmap_demote_DMAP() .. amd64_mrinit() .. mem_modevent() .. module_register_init() .. mi_startup() .. If I remove mem module from loader.conf kernel boots fine. If I kldload mem after boot, panic happens. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: loading if_bfe after boot
Hi, Loading if_bfe module after boot hangs machine, it works/attach fine from loader. Tell me if you need bt. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Broadcom BCM4310 USB Controller (Wifi)
On Fri, Oct 29, 2010 at 6:34 AM, Scot Hetzel swhet...@gmail.com wrote: On Fri, Oct 29, 2010 at 12:59 AM, Matthias Apitz g...@unixarea.de wrote: I booted the 8-CURRENT this morning, loaded the module with kldload(8) and wlan0 came up by its own (I did not realized this yesterday). I have in rc.conf: wlans_ndis0=wlan0 ifconfig_wlan0=WPA DHCP wpa_supplicant(8) started after kldload, and associated the interface with my AP; had to do the DHCP by hand, don't know why? The problem is that the Broadcom NDIS driver is generating connection events, but nothing is relaying that information to the wpa_supplicant daemon. Since the wpa_supplicant daemon doesn't see a connection event, it retries connecting I had created a patch in PR 113915 which solves this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=113915 Give it a try, if it solves your problem submit a followup to the PR. Hmm, ndis_events are required if you use -Dndis and wpa/rsn and need to get event of PMKIDs. For other uses it is of no use. Try -Dbsd driver for wpa_supplicant with code from here: Try http://gitorious.org/ndisulator ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
