Re: user problems when upgrading to v15
Over the last week or so, stable/13, stable/14 and current have improved. Finally, I can make it through a build and install with a password on the root account and a user in the wheel group without having it fail. Brian On 9/9/2023 9:02 AM, John Baldwin wrote: On 9/2/23 7:11 AM, Dimitry Andric wrote: On 1 Sep 2023, at 03:42, brian whalen wrote: Repeating the entire process: I created a 13.2 vm with 6 cores and 8GB of ram. Ran freebsd-update fetch and install. Ran pkg install git bash ccache open-vm-tools-nox11 Used git clone to get current and ports source files. Edited /etc/make.conf to use ccache Ran make -j6 buildworld && make -j6 kernel I then rebooted in single user mode and did the next steps saving output to a file with > filename. etcupdate -p was pretty uneventful. It did show the below and did not prompt to edit. root@f15:~ # less etcupdatep C /etc/group C /etc/master.passwd This is a problem: the "C" characters mean there were conflicts, and it's indeed very unfortunate that etcupdate does not immediately force you to resolve them. Because now you basically have mangled group and master.passwd files, with conflict markers in them! No, the conflicted files are in /var/db/etcupdate/conflicts, the files in /etc are still the old ones at this point and won't be updated until you run 'etcupdate resolve' to fix them. I suspect what happened here is that Brian chose the 'tf' (theirs-full) option for 'etcupdate resolve' when he really wanted to do 'e' to edit the conflicted version. Immediately after this, you should run "etcupdate resolve", and fix any conflicts that it has found. Note that recently there was a lot of churn due to the removal of $FreeBSD$ keywords, and this almost always creates conflicts in the group and passwd files. For lots of other files in /etc, the conflicts are resolved automatically, but unfortunately not for the files that are essential to log in! make installworld seemed mostly error free though I did see a nonzero status for a man page failed inn the man4 directory. etcupdate -B only showed the below. This was my first build after install. root@f15:~ # less etcupdateB Conflicts remain from previous update, aborting. Yes, that is indeed the problem. You must first resolve conflicts from any previous etcupdate run, before doing anything else. As to why it does not immediately forces you to do so, and delegates this to a separate step, which can easily be forgotten, I have no idea. So that if you are doing scripted upgrades, you don't hang forever in a script. The intention is that after doing a bunch of scripted installworld + etcupdate's on various hosts you can use 'etcupdate status' to see if there are any remaining steps requiring manual intervention. There could be an option to request batched vs interactivate updates perhaps. If I type exit in single user mode to go multi user mode, the local user still works. After a reboot the local user still works. This local user can also sudo as expected. This wasn't the case for the previous build when I first reported this. However, if I run etcupdate resolve it is still presenting /etc/group and /etc/master/passwd as problems. If this is is expected behavior for current then no big deal. I just wasn't sure. The conflicts themselves are expected, alas. But you _must_ resolve them, otherwise you can end up with a mostly-bricked system. No, the conflict markers are not placed in the versions in /etc. However, etucpdate does refuse to do a "new" upgrade until you resolve all the conflicts from your previous upgrade to ensure that conflicted upgrades aren't missed.
Re: user problems when upgrading to v15
Repeating the entire process: I created a 13.2 vm with 6 cores and 8GB of ram. Ran freebsd-update fetch and install. Ran pkg install git bash ccache open-vm-tools-nox11 Used git clone to get current and ports source files. Edited /etc/make.conf to use ccache Ran make -j6 buildworld && make -j6 kernel I then rebooted in single user mode and did the next steps saving output to a file with > filename. etcupdate -p was pretty uneventful. It did show the below and did not prompt to edit. root@f15:~ # less etcupdatep C /etc/group C /etc/master.passwd make installworld seemed mostly error free though I did see a nonzero status for a man page failed inn the man4 directory. etcupdate -B only showed the below. This was my first build after install. root@f15:~ # less etcupdateB Conflicts remain from previous update, aborting. If I type exit in single user mode to go multi user mode, the local user still works. After a reboot the local user still works. This local user can also sudo as expected. This wasn't the case for the previous build when I first reported this. However, if I run etcupdate resolve it is still presenting /etc/group and /etc/master/passwd as problems. If this is is expected behavior for current then no big deal. I just wasn't sure. Brian On 8/30/2023 7:35 PM, Graham Perrin wrote: On 31/08/2023 03:31, brian whalen wrote: Understood. I guess I was expecting the update process of etcupdate -p && make installworld && etcupdate -B to not whack existing users or delete an existing root user's password. I accepted the remote and then recreated users and reset passwords and am retrying this. BW Thanks. For clarity: did the routine /not/ prompt you to edit the file (in which, you would have seen conflict markers etc.)? On 8/30/2023 7:21 PM, Graham Perrin wrote: On 31/08/2023 03:00, brian whalen wrote: … I ran etcupdate resolve accepting the remote option and saw 2 issues. The root user's password was deleted. The non root user no longer existed. Logically, remote does not include things such as your root user's password.
Re: user problems when upgrading to v15
Understood. I guess I was expecting the update process of etcupdate -p && make installworld && etcupdate -B to not whack existing users or delete an existing root user's password. I accepted the remote and then recreated users and reset passwords and am retrying this. BW On 8/30/2023 7:21 PM, Graham Perrin wrote: On 31/08/2023 03:00, brian whalen wrote: … I ran etcupdate resolve accepting the remote option and saw 2 issues. The root user's password was deleted. The non root user no longer existed. Logically, remote does not include things such as your root user's password.
Re: user problems when upgrading to v15
I have seen this twice. Once when going from 13.2 to current 14.0 alpha1 and then to 15, and a 2nd time when going from 13.2 to 15. I have a user that is a member of the wheel group. After I upgraded and ran the post reboot commands in single user mode I was alerted to merge conflicts. I ran etcupdate resolve accepting the remote option and saw 2 issues. The root user's password was deleted. The non root user no longer existed.
pkg problems with v15
root@f15:~ # pkg update pkg: Warning: Major OS version upgrade detected. Running "pkg bootstrap -f" recommended Updating FreeBSD repository catalogue... pkg: http://pkgmir.geo.freebsd.org/FreeBSD:15:amd64/quarterly/meta.txz: Not Found repository FreeBSD has no meta file, using default settings pkg: http://pkgmir.geo.freebsd.org/FreeBSD:15:amd64/quarterly/packagesite.pkg: Not Found pkg: http://pkgmir.geo.freebsd.org/FreeBSD:15:amd64/quarterly/packagesite.txz: Not Found Unable to update repository FreeBSD Error updating repositories! root@f15:~ # pkg bootstrap -f The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:15:amd64/quarterly, please wait... pkg: Error fetching http://pkg.FreeBSD.org/FreeBSD:15:amd64/quarterly/Latest/pkg.txz: Operation timed out A pre-built version of pkg could not be found for your system. Consider changing PACKAGESITE or installing it from ports: 'ports-mgmt/pkg'. The pkg package is installed; I put it there while the system was at 13.2 root@f15:~ # pkg info pkg: Warning: Major OS version upgrade detected. Running "pkg bootstrap -f" recommended bash-5.2.15 GNU Project's Bourne Again SHell ca_root_nss-3.89.1 Root certificate bundle from the Mozilla Project ccache-3.7.12_4 Tool to minimize the compile time of C/C++ programs curl-8.1.2 Command line tool and library for transferring data with URLs expat-2.5.0 XML 1.0 parser written in C fusefs-libs-2.9.9_2 FUSE allows filesystem implementation in userspace gettext-runtime-0.21.1 GNU gettext runtime libraries and programs git-2.41.0 Distributed source code management tool glib-2.76.4_1,2 Some useful routines of C programming (current stable version) indexinfo-0.3.1 Utility to regenerate the GNU info page index libdnet-1.13_3 Simple interface to low level networking routines libffi-3.4.4 Foreign Function Interface libiconv-1.17 Character set conversion library libidn2-2.3.4 Implementation of IDNA2008 internationalized domain names libmspack-0.11alpha Library for Microsoft compression formats libnghttp2-1.53.0 HTTP/2.0 C Library libpsl-0.21.2_3 C library to handle the Public Suffix List libssh2-1.11.0,3 Library implementing the SSH2 protocol libunistring-1.1 Unicode string library libxml2-2.10.4 XML parser library for GNOME mpdecimal-2.5.1 C/C++ arbitrary precision decimal floating point libraries open-vm-tools-nox11-12.2.5,2 Open VMware tools for FreeBSD VMware guests (without X11) p5-Authen-SASL-2.16_1 Perl5 module for SASL authentication p5-CGI-4.57 Handle Common Gateway Interface requests and responses p5-Clone-0.46 Recursively copy Perl datatypes p5-Digest-HMAC-1.04 Perl5 interface to HMAC Message-Digest Algorithms p5-Encode-Locale-1.05 Determine the locale encoding p5-Error-0.17029 Error/exception handling in object-oriented programming style p5-GSSAPI-0.28_2 Perl extension providing access to the GSSAPIv2 library p5-HTML-Parser-3.81 Perl5 module for parsing HTML documents p5-HTML-Tagset-3.20_1 Some useful data table in parsing HTML p5-HTTP-Date-6.05 Conversion routines for the HTTP protocol date formats p5-HTTP-Message-6.44 Representation of HTTP style messages p5-IO-HTML-1.004 Open an HTML file with automatic charset detection p5-IO-Socket-IP-0.41 Drop-in replacement for IO::Socket::INET supporting IPv4 and IPv6 p5-IO-Socket-SSL-2.083_1 Perl5 interface to SSL sockets p5-LWP-MediaTypes-6.04 Guess media type for a file or a URL p5-Mozilla-CA-20221114 Perl extension for Mozilla CA cert bundle in PEM format p5-Net-SSLeay-1.92 Perl5 interface to SSL p5-TimeDate-2.33,1 Perl5 module containing a better/faster date parser for absolute dates p5-URI-5.19 Perl5 interface to Uniform Resource Identifier (URI) references pcre2-10.42 Perl Compatible Regular Expressions library, version 2 perl5-5.32.1_3 Practical Extraction and Report Language pkg-1.19.2 Package manager python39-3.9.17 Interpreted object-oriented programming language readline-8.2.1 Library for editing command lines as they are typed
Re: Git segfaulting in libcrypto.so when trying to clone.
I think this just depends on when packages were built in relation to the upgrade of openssl on current. I have just got over this problem by rebuilding and installing the ftp/curl port (different problem here, curl was failing but referred to older version of libssl and libcrypto - which I didn't have a snapshot build). I also rebuilt 'pkg' to get over the same problem. Hopefully package building will catch up with this fairly quickly. My problem was on arm64 so probably a lower priority for getting ports back on track than amd64. Cheers, Brian On 17/10/18 7:15 pm, Brennan Vincent wrote: > Hi Kubilay (or do you prefer "koobs"?). Thanks for the response. > > To answer your questions: > * I am using latest packages > * My /etc/make.conf was empty when I built the system, and now just has > `WITH_DEBUG=yes`. > > # uname -a > FreeBSD freebsd 12.0-ALPHA9 FreeBSD 12.0-ALPHA9 #3 r339359: Tue Oct 16 > 03:28:51 UTC 2018 root@freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 > # ldd /usr/local/bin/curl > /usr/local/bin/curl: > libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x800268000) > libz.so.6 => /lib/libz.so.6 (0x8002e7000) > libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x800301000) > libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800382000) > libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x80038f000) > libthr.so.3 => /lib/libthr.so.3 (0x8003b1000) > libc.so.7 => /lib/libc.so.7 (0x8003dc000) > libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x8007e7000) > libssl.so.8 => /usr/lib/libssl.so.8 (0x800812000) > libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x800888000) > libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800891000) > libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8008e2000) > libcrypto.so.8 => /lib/libcrypto.so.8 (0x8008e7000) > libasn1.so.11 => /usr/lib/libasn1.so.11 (0x800b59000) > libwind.so.11 => /usr/lib/libwind.so.11 (0x800bfd000) > libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x800c27000) > libroken.so.11 => /usr/lib/libroken.so.11 (0x800c2e000) > libcrypt.so.5 => /lib/libcrypt.so.5 (0x800c43000) > libcrypto.so.9 => /lib/libcrypto.so.9 (0x800c65000) > libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 > (0x800f52000) > # ldd /usr/local/lib/libcurl.so.4 > /usr/local/lib/libcurl.so.4: > libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x800707000) > libssl.so.8 => /usr/lib/libssl.so.8 (0x800732000) > libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x8007a8000) > libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800e0) > libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8007b1000) > libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e51000) > libasn1.so.11 => /usr/lib/libasn1.so.11 (0x8010c3000) > libwind.so.11 => /usr/lib/libwind.so.11 (0x8007b6000) > libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x8007e) > libroken.so.11 => /usr/lib/libroken.so.11 (0x8007e7000) > libcrypt.so.5 => /lib/libcrypt.so.5 (0x801167000) > libz.so.6 => /lib/libz.so.6 (0x801189000) > libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x8011a3000) > libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x801224000) > libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x801231000) > libthr.so.3 => /lib/libthr.so.3 (0x801253000) > libc.so.7 => /lib/libc.so.7 (0x800248000) > libcrypto.so.9 => /lib/libcrypto.so.9 (0x80127e000) > libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 > (0x80156b000) > > (aha - libcurl depends on .8 , and the curl binary depends on .9) > > From a cursory glance at the source tree, it seems libcrypto is part of > openssl, is this right? It seems the openssl version is in flux right now, > that might explain things... > > Cheers, > ___ > 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" ___ 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: ALPHA3 niggles
On 28/8/18 11:45 pm, Emmanuel Vadot wrote: > On Tue, 28 Aug 2018 22:10:18 +1000 > Brian Scott wrote: > >> Hi, >> >> Just a couple of small observations with 12.0-ALPHA3 from testing on a >> Raspberry-Pi 3: >> >> * The boot loader (I presume the new LUA based one) is sending escape >> sequences to the screen to format up a boot menu. The screen doesn't >> recognise them and shows a series of ^[ style sequences instead. > If it's stuff like that : > https://people.freebsd.org/~manu/RPI2-HDMI.jpg it's known, we should > remove the beastie menu from the image I think Very similar: https://www.dropbox.com/s/0w4buscnk2ec7ez/2018-08-29%2011.56.51.jpg?dl=0 This is using an HDMI attached monitor. I disconnected the serial console adapter last week and so haven't seen what it looks like over that. I'm a bit of a fan of the beastie menu as a general rule so it would be sad to lose it. Still, if the EFI console can't handle the instructions I'm thinking that some simplified version of menu would have to suffice. > >> * The timeout countdown of the boot loader has reverted to very slow. >> The loader did this earlier in the year on -CURRENT but had obviously >> been fixed for a few months now. Maybe some change needs to be adapted >> from the old to the new loader. > I don't have this problem on my RPI3B+ with latest ALPHA snapshot. > The patch is still in the u-boot-rpi3 port > (https://svnweb.freebsd.org/ports/head/sysutils/u-boot-rpi3/files/patch-lib_efi__loader_efi__console.c?revision=468630=markup) > so I don't know what going on for you. One second on the timer takes about 5 seconds of wall clock time. As I said, it had been good for a few months now but was slow earlier in the year. This is the freebsd loader not u-boot unless I completely misunderstand the booting process (also possible), although I suppose u-boot is still providing the console services. The u-boot countdown timer appears to move quickly enough that I haven't really paid any attention to it. > >> * The root user on the image doesn't have a .login file. > The users are added with pw directly (iirc) and the /etc/skel content > isn't copied in their home directory, that's something we should change > for 13 and mfc back for 12.1 > >> I realise these are all cosmetic issues in the overall scheme of things >> but if anyone is working on a bit of spit-and-polish for the new release >> they might want to have a look at a few of these. >> >> Otherwise I'm happy to say that I haven't found any significant problems >> yet. I'll keep looking though. >> >> Keep up the good work, >> >> Brian >> >> ___ >> 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" Cheers, Brian ___ 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"
ALPHA3 niggles
Hi, Just a couple of small observations with 12.0-ALPHA3 from testing on a Raspberry-Pi 3: * The boot loader (I presume the new LUA based one) is sending escape sequences to the screen to format up a boot menu. The screen doesn't recognise them and shows a series of ^[ style sequences instead. * The timeout countdown of the boot loader has reverted to very slow. The loader did this earlier in the year on -CURRENT but had obviously been fixed for a few months now. Maybe some change needs to be adapted from the old to the new loader. * The root user on the image doesn't have a .login file. I realise these are all cosmetic issues in the overall scheme of things but if anyone is working on a bit of spit-and-polish for the new release they might want to have a look at a few of these. Otherwise I'm happy to say that I haven't found any significant problems yet. I'll keep looking though. Keep up the good work, Brian ___ 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: Elantech Touchpad Woes - Support for Elantech touchpads over i2c/SMBus still possibly missing
Hi all, I have a ASUS Zenbook UX430U with the same problem. I am heading to BSDCan (and the FreeBSD Dev Submit as a guest) this week and could spend some time working on this in the hacker lounge. That said, I am new to FreeBSD driver code, so I could use some guidance to help me along. Anyone headed to the conference that might be able to lend me a hand? Thanks, Brian Brian Kidney, M.Eng., P.Eng. PGP Fingerprint: B8C9 D174 BABC 7FD8 67D0 DF84 FDEE B338 F248 A893 On 3 Jun 2018, at 2:43, Albert wrote: Michael, Good to know you still have plans to work on that eventually. It'd be much appreciated. Looking at the source for your cyapa driver, I see you've ported it from the DragonFlyBSD driver (and they in turn adapted it from the Linux one). I should've looked into that earlier... Instead I spent most of my day trying to get OpenBSD running to try and follow Tom's hint at possible support there, but I had so many more issues along the way that in the end I figured "if I'm having trouble even getting a keyboard to work on this with my system, a touchpad will likely be the least of my worries." So, I'm back to my FreeBSD CURRENT install, still no touchpad support (obviously). I guess I'll be doing some more research on these things and tinkering with what I find. Unfortunately, I'm moving overseas in a couple of weeks and leaving my desktop behind, which means I need to have this laptop in full working condition by then, so if I don't make any progress, I'll have to somewhat reluctantly go back to Linux for the time being. If/when that happens, I'll still be happy to help with any testing. MfG, - Albert ___ 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" ___ 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: Leaving the Desktop Market
as well as his laptop. He is very happy with the change. Cheers Andreas Cheers, -matt ___ 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-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- Best Wishes, Brian Kim ___ 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 in get_next_dirent
Hopefully it's not still broken. I attempted to fix the problem with r211684 but the fix was essentially a no-op, it didn't fix or break anything. I believe r211818 fixed the problem in head and r212137 fixed it in stable/8. Can you try an upgrade to at least r211818 and see if that solves the problem? Thanks. On Thu, 02 Sep 2010 11:48:44 +0300 Andriy Gapon a...@icyb.net.ua wrote: Brian, after I upgrade from beginning-of-June kernel to end-of-August one (r211758) I get a panic in get_next_dirent which happens during parallel access to FS like during buildworld with -jN. I am upgrading kernel to the latest revision as of today. Could this be something that you accidentally broke and then fixed while pursuing your NFS issue? -- Andriy Gapon -- Brian Somers br...@awfulhak.org Don't _EVER_ lose your sense of humour ! br...@freebsd.org signature.asc Description: PGP signature
Re: A page fault in subr_turnstile.c:propogate_priority()
Igor Sysoev [EMAIL PROTECTED] wrote: I'd cvsup'ed 5.1-CURRENT from 2003.11.04.02.02.00 up to 2003.11.28.00.00.00 with the turnstile support and it can still causes sometimes a page fault in propogate_priority(). I have core dump and can send debug output. Go ahead and load up kernel.debug and the core dump in gdb -k, and show us the backtrace. Also, do you have any idea about more specific circumstances that will cause this problem? Thanks! -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
IPv6 locking crash (recursion)
Has anyone else tried out the most basic IPv6 test: ndp -I iface and
then ping6 fe80::normal address without %iface extension? I was
greeted by recursion on a non-recursive lock. After some sleuthing,
I tried to determine what conditions could be tested for that would
indicate this must not call the nd6_is_addr_neighbor() call because
we're from a normal RTM_RESOLVE initializing a new route, and this
is the most correct thing I can come up with. It actually would do
something entirely different if recursion were allowed. Comments?
Index: nd6.c
===
RCS file: /u/FreeBSD-cvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.37
diff -u -r1.37 nd6.c
--- nd6.c 8 Nov 2003 23:36:32 - 1.37
+++ nd6.c 26 Nov 2003 13:45:45 -
@@ -1095,7 +1095,8 @@
if (req == RTM_RESOLVE
(nd6_need_cache(ifp) == 0 || /* stf case */
-!nd6_is_addr_neighbor((struct sockaddr_in6 *)rt_key(rt), ifp))) {
+ ((!(rt-rt_flags RTF_WASCLONED) || rt-rt_flags RTF_LLINFO)
+ !nd6_is_addr_neighbor((struct sockaddr_in6 *)rt_key(rt), ifp {
/*
* FreeBSD and BSD/OS often make a cloned host route based
* on a less-specific route (e.g. the default route).
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Bernd Walter [EMAIL PROTECTED] wrote: On Fri, Nov 21, 2003 at 12:35:50PM -0500, Brian F. Feldman wrote: Doug White [EMAIL PROTECTED] wrote: The OHCI driver is largely synced with NetBSD so you might see if they have the same bug. I'll look around for a bootable NetBSD CD. NetBSD is different in that point. This might be the underlying wierdness we were seeing in gtetlow's microdrive with transfers over 8k. The one-page-crossing ohci limitation is really annoying. Is there a way to add a quirk for max 8k transfers or anything? Even though that would be patently lame, I'd like to get some sort of workaround here. I don't even know what is supposed to be the problem here -- the fact that it's an ohci controller, an ohci+ehci controller, or that it's some specific controller issue... We never did any page crossing on ohci/ehci bevor the newbus change took place. Found it!!! Definitely a problem created then... --- ohci.c 12 Nov 2003 01:40:11 - 1.138 +++ ohci.c 22 Nov 2003 03:28:42 - @@ -569,7 +569,7 @@ cur-td.td_cbp = htole32(dataphys); cur-nexttd = next; cur-td.td_nexttd = htole32(next-physaddr); - cur-td.td_be = htole32(DMAADDR(dma, curlen - 1)); + cur-td.td_be = htole32(DMAADDR(dma, offset + curlen - 1)); cur-len = curlen; cur-flags = OHCI_ADD_LEN; cur-xfer = xfer; I'm a lot happier now :-) Let's start trying to get this stuff merged in! -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Doug White [EMAIL PROTECTED] wrote: The OHCI driver is largely synced with NetBSD so you might see if they have the same bug. I'll look around for a bootable NetBSD CD. This might be the underlying wierdness we were seeing in gtetlow's microdrive with transfers over 8k. The one-page-crossing ohci limitation is really annoying. Is there a way to add a quirk for max 8k transfers or anything? Even though that would be patently lame, I'd like to get some sort of workaround here. I don't even know what is supposed to be the problem here -- the fact that it's an ohci controller, an ohci+ehci controller, or that it's some specific controller issue... On Thu, 20 Nov 2003, Brian F. Feldman wrote: Thanks for the patches to try! They unfortunately didn't fix the crash I have, but I found out why it's occurring. See ohci.c:1389: if (std-td.td_cbp != 0) len -= le32toh(std-td.td_be) - le32toh(std-td.td_cbp) + 1; In one of my transfers (look in my log for the 2560 byte one) that statement actually adds 8192 to len, which is utterly bogus because you can see it only allocates 2560 -- hence when it tries to finish the transfer it memcpy()'s way too much memory and my kernel segfaults. If I #if 0 this out, I'm left only with umass0: BBB reset failed, STALLED messages... which is a lot better than before! I don't know under what situations that bit of code makes sense, but it definitely needs more reviewing! Stalls usually come from the device receiving bad data. Rather than return errors, usb generally just hangs the endpoint. Hmm :-/ I wonder if anyone could interpret the debugging info enough to have an idea what it's disliking for certain. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Bernd Walter [EMAIL PROTECTED] wrote: On Fri, Nov 21, 2003 at 12:35:50PM -0500, Brian F. Feldman wrote: Doug White [EMAIL PROTECTED] wrote: The OHCI driver is largely synced with NetBSD so you might see if they have the same bug. I'll look around for a bootable NetBSD CD. NetBSD is different in that point. This might be the underlying wierdness we were seeing in gtetlow's microdrive with transfers over 8k. The one-page-crossing ohci limitation is really annoying. Is there a way to add a quirk for max 8k transfers or anything? Even though that would be patently lame, I'd like to get some sort of workaround here. I don't even know what is supposed to be the problem here -- the fact that it's an ohci controller, an ohci+ehci controller, or that it's some specific controller issue... We never did any page crossing on ohci/ehci bevor the newbus change took place. Are you hinting that I need to find some way to defragment the DMA buffers I'm getting back? -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Thanks for the patches to try! They unfortunately didn't fix the crash I have, but I found out why it's occurring. See ohci.c:1389: if (std-td.td_cbp != 0) len -= le32toh(std-td.td_be) - le32toh(std-td.td_cbp) + 1; In one of my transfers (look in my log for the 2560 byte one) that statement actually adds 8192 to len, which is utterly bogus because you can see it only allocates 2560 -- hence when it tries to finish the transfer it memcpy()'s way too much memory and my kernel segfaults. If I #if 0 this out, I'm left only with umass0: BBB reset failed, STALLED messages... which is a lot better than before! I don't know under what situations that bit of code makes sense, but it definitely needs more reviewing! Please check out my debugging messages and tell me if you see any hints as to why the transfers are getting stalled. I should have looked at the debugging messages long ago, I guess. Thanks! http://green.homeunix.org/~green/ohci-debugging.txt.gz -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Brian F. Feldman [EMAIL PROTECTED] wrote: Thanks for the patches to try! They unfortunately didn't fix the crash I have, but I found out why it's occurring. See ohci.c:1389: if (std-td.td_cbp != 0) len -= le32toh(std-td.td_be) - le32toh(std-td.td_cbp) + 1; In one of my transfers (look in my log for the 2560 byte one) that statement actually adds 8192 to len, which is utterly bogus because you can see it only allocates 2560 -- hence when it tries to finish the transfer it memcpy()'s way too much memory and my kernel segfaults. If I #if 0 this out, I'm left only with umass0: BBB reset failed, STALLED messages... which is a lot better than before! I don't know under what situations that bit of code makes sense, but it definitely needs more reviewing! Please check out my debugging messages and tell me if you see any hints as to why the transfers are getting stalled. I should have looked at the debugging messages long ago, I guess. Thanks! http://green.homeunix.org/~green/ohci-debugging.txt.gz BTW, replying to myself -- it seems to be something missing from the multi-allocation transfers (8KB), because I can do up to 8KB transfers perfectly fine now, but 10KB ones, for example, like mdir(8) does are the ones that give me BBB stalls. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Josef Karthauser [EMAIL PROTECTED] wrote: On Sun, Nov 17, 2002 at 01:18:00PM -0500, Brian F. Feldman wrote: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. Anyone? I kinda want to use my CF reader. There are rumours that OHCI is borked in NetBSD too and this is a bug that we've inherited. Me, I've not got an OHCI system to test just UHCI. Did it used to work, and got broken, or has it never worked? Jeez, it's been broken a year and it's almost 5.2-RELEASE now. Does anyone have ANY leads on these problems? I know precisely nothing about how my USB hardware is supposed to work, but this OHCI+EHCI stuff definitely doesn't, and it's really not uncommon at all. Is it unbroken in NetBSD currently? -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_tun failed to register
On Wed, 05 Nov 2003 18:37 Michael Nottebrock wrote: On Tuesday 04 November 2003 15:32, Antoine Jacoutot wrote: Matteo Riondato wrote: Well, it did not change anything :( What is really strange is that tun is compiled in the kernel, but the module is started anyway ??? I had the same problem last year and solved it by removing device tun from the kernel configuration file. Yes, I though about it. But still, it is a strange bug and I cannot believe I (well, and you :) ) am the only one seeing this. It's been there for quite a while, I see that behaviour in 5.1-RELEASE, too. =2D-=20 ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org This looks like the opposite of a problem on STABLE. On CURRENT ifconfig checks for 'tun' in the kernel when you do e.g. 'ifconfig tun0' [1], but the driver is registered as 'if_tun'. At the moment I don't have any 5-* boxes, so I can't check this for sure, but it looks like ifconfig will be run at startup if you have any ifconfig_tun* lines in rc.conf. You can see if ifconfig is the culprit by booting single-user and doing ifconfig tun0 (it is only the first attempt that gives the error message in question). If so, the following (Untested!) patch would presumably fix it: Index: sys/net/if_tun.c === RCS file: /home/ncvs/src/sys/net/if_tun.c,v retrieving revision 1.129 diff -u -r1.129 if_tun.c --- sys/net/if_tun.c 31 Oct 2003 18:32:08 - 1.129 +++ sys/net/if_tun.c 5 Nov 2003 21:59:10 - @@ -200,7 +200,7 @@ 0 }; -DECLARE_MODULE(if_tun, tun_mod, SI_SUB_PSEUDO, SI_ORDER_ANY); +DECLARE_MODULE(tun, tun_mod, SI_SUB_PSEUDO, SI_ORDER_ANY); static void tunstart(struct ifnet *ifp) === A similar change would likely work for if_ppp.c. Assuming I am right about this (hah :) a pr would seem to be in order. Brian [1] Per this commit: mdodd 2003/04/14 23:25:58 PDT FreeBSD src repository Modified files: sbin/ifconfigifconfig.c Log: Don't abuse module names to facilitate ifconfig module loading; such abuse isn't really needed. (And if we do need type information associated with a module then we should make it explicit and not use hacks.) Revision ChangesPath 1.89 +1 -1 src/sbin/ifconfig/ifconfig.c ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel Panic
Steve Ames [EMAIL PROTECTED] wrote: For the past few weeks my -CURRENT system has been locking up. With a recent kernel (from 11/2) the following appears: Fault trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc049d0db stack pointer = 0x10:0xe009cc88 frame pointer = 0x10:0xe009cc9c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 23 (irq10: dc0) trap number = 12 panic: page fault syncing disks, buffers remaining... 6800 6800 That bit about the current process and 'dc0' kind of makes me believe it was a dc driver issue? I may replace that card (with an ethernet card that doesn't use dc) and see if the problem goes away. Am I correct in believing this is a dc issue? If so, hope the above helps in diagnosing the problem. Otherwise... any other pointers? instruction pointer = 0x8:0xc049d0db That will tell you exactly where the problem is... -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/kern vfs_bio.c
Kirk McKusick [EMAIL PROTECTED] wrote: mckusick2003/11/03 22:30:01 PST FreeBSD src repository Modified files: sys/kern vfs_bio.c Log: Allow the bufdaemon and update daemon processes to skip the waitrunningbufspace() calls so that they are always able to proceed and clean up buffer space. This will fix at least some of any deadlocks you may be seeing with md(4) or similar devices, totally unrelated to hardware. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: runningbufspace related lock-ups with md(4)/UFS/SU (PATCH ?)
Brian F. Feldman [EMAIL PROTECTED] wrote: Kirk McKusick [EMAIL PROTECTED] wrote: I have been able to reproduce your hang on my system and your suggested fix does prevent it. I am going to run some more buffer starvation-type tests on it this week and if they do not cause other problems, I will put in your suggested fix. Thanks, Kirk; seems everyone who's been able to reproduce it can't do so anymore when the synchers are disallowed from waiting on runningbufspace (a couple extra people testing it that haven't spoken up on the list). Replying to myself -- anyone with any further thoughts, objections, desire to fix this one way or another? -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: runningbufspace related lock-ups with md(4)/UFS/SU (PATCH ?)
Kirk McKusick [EMAIL PROTECTED] wrote: I have been able to reproduce your hang on my system and your suggested fix does prevent it. I am going to run some more buffer starvation-type tests on it this week and if they do not cause other problems, I will put in your suggested fix. Thanks, Kirk; seems everyone who's been able to reproduce it can't do so anymore when the synchers are disallowed from waiting on runningbufspace (a couple extra people testing it that haven't spoken up on the list). -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using ipfw in current branch
Hello again, Please disregard the email below, I realized I wasn't using that kernconf file. So I re-added the following lines to the latest GENRIC kernconf file: # JD options IPFILTER# ipfilter or something options IPDIVERT# enable nat options IPFILTER_LOG# something else too options IPFILTER_DEFAULT_BLOCK # Block all packets by default [snip] Ideas? Here is the updated kernconf link: http://www.dictos.com/AHAB Thanks, -Jason Try reading /usr/src/UPDATING (its near the top, but read the whole thing anyway - it'll be good for you). Also, ipfw and ipfilter are not the same thing. Brian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
runningbufspace related lock-ups with md(4)/UFS/SU (PATCH ?)
I'm having problems where the entire system is locking up when using a MD UFS+SoftUpdates partition. I can simply dd if=/dev/zero of=/mnt/foo and in a couple tries it will lock up. When it locks up, buf_daemon (or if that is patched against, syncer) is calling waitrunningbufspace() from a non-B_ASYNC buf call. Because of this, the md(4) (md0) thread is stuck in ufs waiting to receive a lock on the vnode that one of the syncer/flusher daemons has locked, waiting for bufspace to run down. The user program causing the problem is still stuck in wdrain because it's also waiting for waitrunningbufspace() to return. In short, everything wants to try to reduce the amount of outstanding buffer space, but nothing moves forward while GEOM/md(4)/what have you are waiting for the daemons to let go of the vnode so they can write out data. Does this scenario make sense? I have fixed it here using the following very simple patch, which disables the implicit waitrunningbufspace() calls so the daemons can't get stuck there. diff -r1.412 vfs_bio.c 73a74,75 static struct proc *bufdaemonproc; 889c891,893 waitrunningbufspace(); --- if (curthread-td_proc != bufdaemonproc curthread-td_proc != updateproc) waitrunningbufspace(); 2038,2039d2041 static struct proc *bufdaemonproc; -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to boot cvsup 20031011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 15 Oct 2003, Terry Lambert wrote: Dimitry Andric wrote: On 2003-10-15 at 03:30:54 Brian J. Creasy wrote: unfortunately, we are not getting any errors. the system just restarts after it starts booting the kernel. I've got the same version here of pmap.c, but in my case the kernel hangs just after the boot loader's 'spinner' goes away, before the initial copyright message even. This happens on my old pentium router box, however on another box (well, not a real one, it's VMware ;) this does NOT occur, with precisely the same cvsup... I'm going to bet that both your machines have an odd amount of memory in about the same ballpark. my fujitsu lifebook p2120 has 384mb of ram with 8mb shared video. i'm going to start checking past days' kernels and see exactly what day it stopped working. In my experience, the auto-tuning code still needs some tuning... -- Terry - --- Brian J. Creasy -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/jVoGWMKWjLymTUYRArYtAJ9v9kNfW5HUXcav2xQOSJL4VNgXxwCgt017 w7hBXU4+Y/T+4BEKHPAnz/A= =rjZl -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to boot cvsup 20031011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 12 Oct 2003, Anish Mistry wrote: I finally recvsupped today as some problems with my ata stuff was fixed. Went through the normal buildworld/kernel progress and on reboot of loading the new kernel, it loads the kernel and modules and then as it starts booting it just causes my machine to restart. It doesn't have a serial port so I can't get any debug info that way. I can still boot in with an old kernel, so i can get debug info that way if needed. Old dmesg and pciconf attached. - -- Anish Mistry hi. i'm having the same problem and my pciconf output is the same as yours. you have a fujitsu lifebook p2120, right? i tried the same source (world and kernel) on one of my desktop machines and it is able to boot just fine. looks like this is a tm crusoe issue. maybe something with the acpi or longrun stuff. i'm not too proficient with freebsd kernel hacking, so hopefully someone else will be able to tackle this. - --- Brian J. Creasy -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/jIaZWMKWjLymTUYRArVrAJ454d0I3V3GvA+9FkNqpz6EL3y1KQCgt9Vk ArLxKFm9nNsfgiSe2ZpYPWs= =zLwX -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to boot cvsup 20031011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 14 Oct 2003, Anish Mistry wrote: hi. i'm having the same problem and my pciconf output is the same as yours. you have a fujitsu lifebook p2120, right? P2110. I'm at least glad to hear that I'm not alone. as am i. i tried the same source (world and kernel) on one of my desktop machines and it is able to boot just fine. looks like this is a tm crusoe issue. maybe something with the acpi or longrun stuff. i'm not too proficient with freebsd kernel hacking, so hopefully someone else will be able to tackle this. When was the last good cvsup that you did? I think we will have to track down ourselves which commit broke since no one else is having this problem. I don't remember when I did mine since I let a friend borrow it for a couple of weeks. I hope that someone with more knowledge can point where to start looking. It isn't ACPI since it still doesn't work when unloaded from the boot loader. --- Brian J. Creasy -- Anish Mistry the last good cvsup i did was quite a while ago. july 13th. i got a little hung up with the semester starting back up. there isn't a way to tell cvsup a specific date to roll back to, is there? - --- Brian J. Creasy -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/jKCkWMKWjLymTUYRAg5tAJwNE3LxAxd+UNC+5hxKuYzLEZ5YTQCbBB7y rQ7JmenMscCERiZmAL3djCY= =UoI8 -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to boot cvsup 20031011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 14 Oct 2003, Don Lewis wrote: On 12 Oct, Anish Mistry wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I finally recvsupped today as some problems with my ata stuff was fixed. Went through the normal buildworld/kernel progress and on reboot of loading the new kernel, it loads the kernel and modules and then as it starts booting it just causes my machine to restart. It doesn't have a serial port so I can't get any debug info that way. I can still boot in with an old kernel, so i can get debug info that way if needed. Old dmesg and pciconf attached. What version of sys/i386/i386/pmap.c do you have? If you are getting the pmap_zero_page: CMAP3 busy, it should be fixed by version 1.446, which phk checked in 2003/10/12 10:55:45. __FBSDID($FreeBSD: src/sys/i386/i386/pmap.c,v 1.447 2003/10/13 03:28:31 alc Exp $); unfortunately, we are not getting any errors. the system just restarts after it starts booting the kernel. - --- Brian J. Creasy -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/jKNUWMKWjLymTUYRAq21AJ0TCECQQNrc7L1LZu6PJ/Xeq0ydxgCeIcoz 2TPzvP2MV/3/K6GmAJIFeHc= =4jHZ -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ata broken on Thinkpad A22m
After updating to yesterday's -CURRENT, my IBM Thinkpad A22m stoped booting. It hangs at: GEOM: create disk ad0 dp=0xc3ded670 ad0: 38154MB IC25N040ATCS04-0 [77520/16/63] at ata0-master UDMA33 ata1: resetting devices .. done The console is still alive, but the kernel appears to be waiting for an interrupt that will never come. My Thinkpad is known to have a buggy ata controller which (sometimes? all the time?) fails to send interrupts for ata1-slave, and causes various revisions of the kernel to complain in various places. -CURRENT used to complain at boot, and the most recent working kernel I have complains at shutdown. The most recent working kernel, from earlier this week: GEOM: create disk ad0 dp=0xc3ded670 ad0: 38154MB IC25N040ATCS04-0 [77520/16/63] at ata0-master UDMA33 acd0: DVDROM HITACHI DVD-ROM GD-S200 at ata1-master PIO4 Mounting root from ufs:/dev/ad0s3a at shutdown: syncing disks, buffers remaining... 3 3 1 1 done Uptime: 2m21s ata1-slave: WARNING - FLUSHCACHE recovered from missing interrupt -- Brian Buchanan, CISSP [EMAIL PROTECTED] -- FreeBSD - The Power to Servehttp://www.freebsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
yep, umass still broken
ums0: 3 buttons and Z dir. uhub5: Texas Instruments TUSB2046 hub, class 9/0, rev 1.10/1.25, addr 5 uhub5: 4 ports with 4 removable, bus powered umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 7 umass0: Get Max Lun not supported (STALLED) pcm0: CMedia CMI8738 port 0xc800-0xc8ff irq 2 at device 4.0 on pci2 dc0: ADMtek AN985 10/100BaseTX port 0xc400-0xc4ff mem 0xeb80-0xeb8003ff irq 5 at device 5.0 on pci2 dc0: Ethernet address: 00:20:78:0f:88:c9 miibus0: MII bus on dc0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci1: HighPoint HPT366 UDMA66 controller port 0xb400-0xb4ff,0xb800-0xb803,0xc000-0xc007 irq 2 at device 6.0 on pci2 atapci1: [MPSAFE] ata2: at 0xc000 on atapci1 ata2: [MPSAFE] atapci2: HighPoint HPT366 UDMA66 controller port 0xa400-0xa4ff,0xa800-0xa803,0xb000-0xb007 irq 2 at device 6.1 on pci2 atapci2: [MPSAFE] ata3: at 0xb000 on atapci2 ata3: [MPSAFE] xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xa000-0xa07f mem 0xeb00-0xeb7f irq 9 at device 8.0 on pci2 xl0: Ethernet address: 00:e0:18:9b:ad:9e miibus1: MII bus on xl0 ukphy1: Generic IEEE 802.3u media interface on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: Parallel port bus on ppc0 ppbus0: IEEE1284 device found Probing for PnP devices on ppbus0: lpt0: Printer on ppbus0 lpt0: Interrupt-driven port sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 orm0: Option ROMs at iomem 0xcc000-0xc,0xc-0xc9fff on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 1.000 msec ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to deny, logging limited to 100 packets/entry by default IPsec: Initialized Security Association Processing. acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% GEOM: create disk ad0 dp=0xc239c070 ad0: 76319MB WDC WD800BB-32BSA0 [155061/16/63] at ata0-master UDMA100 GEOM: create disk ad1 dp=0xc239bd70 ad1: 43979MB IBM-DTLA-307045 [89355/16/63] at ata1-master UDMA100 acd0: CDROM FX322M at ata2-master PIO4 GEOM: create disk da0 dp=0xc2391c50 SMP: AP CPU #1 Launched! da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 Mounting root from ufs:/dev/ad0s2a -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Annoucning DragonFly BSD!
On Thu, Jul 17, 2003 at 08:56:56PM -0400, Chuck Robey wrote: On Thu, 17 Jul 2003, Gregory Sutter wrote: To drag this back to more interesting topics, I'm not yet convinced that branching off 4.X is a good thing. Gosh, if only there were a DragonFly BSD mailing list, so we _can_ keep on topic somewhere. :) -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA BSD admin/developer at large ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
freebsd 5.0 on hp netserver lf
Folks, I posted a question earlier on freebsd-questions concerning this, and have since discovered a bit more. Sorry about the cross posting. I'm trying to get 5.0 running on an old hp netserver lf. quoting some random website: How come FreeBSD does not detect my HP Netserver's SCSI controller? This is basically a known problem. The EISA on-board SCSI controller in the HP Netserver machines occupies EISA slot number 11, so all the true EISA slots are in front of it. Alas, the address space for EISA slots = 10 collides with the address space assigned to PCI, and FreeBSD's auto-configuration currently cannot handle this situation very well. So now, the best you can do is to pretend there is no address range clash :), by bumping the kernel option EISA_SLOTS to a value of 12... Of course, this does present you with a chicken-and-egg problem when installing on such a machine. In order to work around this problem, a special hack is available inside UserConfig. Do not use the visual interface, but +the plain command-line interface there. Simply type eisa 12 quit at the prompt, and install your system as usual. While it is recommended you compile and install a custom kernel anyway. The above quoted instructions worked fine when booting with 4.7 floppies, but 5.0 seems to lack the option to boot into UserConfig with a boot -c command. Looking at the device.hints options, which seem to be replacing the UserConfig command, I don't see anything listed for eisa slots. With 5.0's boot loader, I've used set EISA_SLOTS=12 set EISA=12 but the dmesg and installer still don't list the scsi controller, and hence no drives. Interestingly, an lsdev at the boot prompt correctly lists the floppy and two drives, including the partition information. Any suggestions would be greatly appreciated. thanks, Brian -- Brian Kirk primuul.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: freebsd 5.0 on hp netserver lf
set hw.eisa_slots=12 works, it recognizes the controller and drives, then panics. I think I'll settle for 4.7 on here fow now. thanks for your help, Brian On Fri, Mar 21, 2003 at 06:00:29PM -0500, Matthew Emmerton wrote: - Original Message - From: Brian J. Kirk [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 21, 2003 5:45 PM Subject: freebsd 5.0 on hp netserver lf Folks, I posted a question earlier on freebsd-questions concerning this, and have since discovered a bit more. Sorry about the cross posting. I'm trying to get 5.0 running on an old hp netserver lf. quoting some random website: How come FreeBSD does not detect my HP Netserver's SCSI controller? This is basically a known problem. The EISA on-board SCSI controller in the HP Netserver machines occupies EISA slot number 11, so all the true EISA slots are in front of it. Alas, the address space for EISA slots = 10 collides with the address space assigned to PCI, and FreeBSD's auto-configuration currently cannot handle this situation very well. So now, the best you can do is to pretend there is no address range clash :), by bumping the kernel option EISA_SLOTS to a value of 12... Of course, this does present you with a chicken-and-egg problem when installing on such a machine. In order to work around this problem, a special hack is available inside UserConfig. Do not use the visual interface, but +the plain command-line interface there. Simply type eisa 12 quit at the prompt, and install your system as usual. While it is recommended you compile and install a custom kernel anyway. The above quoted instructions worked fine when booting with 4.7 floppies, but 5.0 seems to lack the option to boot into UserConfig with a boot -c command. Looking at the device.hints options, which seem to be replacing the UserConfig command, I don't see anything listed for eisa slots. With 5.0's boot loader, I've used set EISA_SLOTS=12 set EISA=12 but the dmesg and installer still don't list the scsi controller, and hence no drives. Interestingly, an lsdev at the boot prompt correctly lists the floppy and two drives, including the partition information. Any suggestions would be greatly appreciated. thanks, Brian -- Brian Kirk primuul.com Try using hw.eisa_slots = 12. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Brian Kirk primuul.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Changes to libfetch in 5.0 break proxy support?
I'm having a problem with fetch and libfetch in 5.0, and (given that I currently have a bad cold), I'm hoping to get a cheap answer before I have to start crawling through code. In the 4.x days, I was able to set up an apache web proxy, and then export FTP_PASSIVE_MODE=YES and HTTP_PROXY=thehostoftheproxy:80, and then go to /usr/ports, and say, for instance make all. Everything would then download correctly, and go on happily. Now, however, it appears that when I do this, the connection either times out, or I get a file with the right name, but the contents are an HTML document (wrapped to fit in 80 cols). HTMLHEADMETA HTTP-EQUIV=REFRESH CONTENT=0 URL=ftp://space.mit.edu/pub/davis/jed/v0.99/jed-B0.99-15.tar.gz; /HEADBODY/BODY/HTML I know the proxy is working, as my 4.x boxes still go through it happily. Anyone have any ideas if something has broken, or whether its pilot error? -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: cred/uidinfo botch
No, that's not the actual panic message, but the one you get isn't very
useful except to notify you that your uidinfo struct was just freed :)
Here's my backtrace. I run an SMP machine, so I'm leaning toward the idea
this is a race condition. Am I the first to experience extra uidinfo frees?
I don't think it should be that strange that the uidinfo didn't have many
extra references lying around, since the credential shared by my processes
was generally the only thing referencing that entry... but I don't know why
the cred was getting freed, as there was obviously a lot more than that one
process running as my user with stock credentials, but uihashtbl[]
definitely showed that all information relevant to my uid was freed.
#0 doadump () at ../../../kern/kern_shutdown.c:239
#1 0xc019d720 in boot (howto=0x104) at ../../../kern/kern_shutdown.c:371
#2 0xc019d9d9 in panic () at ../../../kern/kern_shutdown.c:542
#3 0xc02e6b4b in trap_fatal (frame=0xd76e7b0c, eva=0x0) at
../../../i386/i386/trap.c:843
#4 0xc02e6802 in trap_pfault (frame=0xd76e7b0c, usermode=0x0, eva=0x1a0) at
../../../i386/i386/trap.c:757
#5 0xc02e6379 in trap (frame={tf_fs = 0x18, tf_es = 0x10, tf_ds = 0x10, tf_edi =
0xc291fe10, tf_esi = 0xc030f532, tf_ebp = 0xd76e7b4c, tf_isp = 0xd76e7b38, tf_ebx =
0x1a0, tf_edx = 0x1a0, tf_ecx = 0x0, tf_eax = 0x1a0, tf_trapno = 0xc, tf_err = 0x0,
tf_eip = 0xc01fd0a8, tf_cs = 0x8, tf_eflags = 0x10246, tf_esp = 0xd76e7c14, tf_ss =
0xc01b932c}) at ../../../i386/i386/trap.c:444
#6 0xc02cf788 in calltrap () at {standard input}:97
#7 0xc01b932c in kvprintf (fmt=0xc030f532 @ %s:%d, func=0xc01b8d00
snprintf_func, arg=0xd76e7c30, radix=0xa, ap=0xd76e7c74 Òü0À¬\003) at
../../../kern/subr_prf.c:668
#8 0xc01b8c7e in vsnprintf (str=0xc03720c0 page fault, size=0x0, format=0x0,
ap=0x0) at ../../../kern/subr_prf.c:413
#9 0xc019d947 in panic (fmt=0xd76e7c30 Ù 7Àç) at ../../../kern/kern_shutdown.c:509
#10 0xc0194123 in _mtx_lock_flags (m=0x0, opts=0x0, file=0xc030fcd2
../../../kern/kern_resource.c, line=0x3ac) at ../../../kern/kern_mutex.c:333
#11 0xc019c86d in uifree (uip=0x3ac) at ../../../kern/kern_resource.c:940
#12 0xc019a5f1 in crfree (cr=0xc030fcd2) at ../../../kern/kern_prot.c:1725
#13 0xc019a885 in cred_update_thread (td=0xc291fe10) at ../../../kern/kern_prot.c:1832
#14 0xc02e6c31 in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi =
0x805a08e, tf_esi = 0x806a092, tf_ebp = 0xbfbff4e8, tf_isp = 0xd76e7d74, tf_ebx =
0xbfbff3b0, tf_edx = 0x10, tf_ecx = 0x805a0a1, tf_eax = 0xbc, tf_trapno = 0x0, tf_err
= 0x2, tf_eip = 0x2821bd93, tf_cs = 0x1f, tf_eflags = 0x282, tf_esp = 0xbfbff2ec,
tf_ss = 0x2f}) at ../../../i386/i386/trap.c:960
#15 0xc02cf7dd in Xint0x80_syscall () at {standard input}:139
--
Brian Fundakowski Feldman \'[ FreeBSD ]''\
[EMAIL PROTECTED] \ The Power to Serve! \
Opinions expressed are my own. \,,\
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: dsp device busy (me too) vchans weirdness
John Hay [EMAIL PROTECTED] wrote: On Wed, Feb 12, 2003 at 08:31:11PM +0200, John Hay wrote: Just switching vchans off on the Dell made the sound work again. Looks like I have to take that back. I just tried a brand new -CURRENT kernel and vchans are now working. I have only tried it by setting hw.snd.maxautovchans. It does produce a lot of could sleep with messages though: Yeah. I found and fixed that a few days ago. It's been around for at least a month, but for some reason I'm getting a lot of ENODEV errors in dsp_reset() which is what made it known. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Sysinstall project?
I was just going through the list of projects at the FreeBSD website. I didn't see one for the installer. I was curious if anyone was working on an upgrade/replacement for sysinstall... I know of Jordan's paper on the subject, et al, but curious if anyone was doing anything more than maintaining our existing sysinstall. -B To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA panic under load
John Baldwin [EMAIL PROTECTED] wrote: On 12-Dec-2002 Kris Kennaway wrote: I got this on an alpha tonight. It was under heavy load at the time (18 simultaneous package builds had just been spawned on the machine). Any ideas? Slab at 0xfc00042d3fb8, freei 2 = 0. panic: Duplicate free of item 0xfc00042d22e0 from zone 0xfc0007d31800(VMSPACE) db_print_backtrace() at db_print_backtrace+0x18 panic() at panic+0x104 uma_dbg_free() at uma_dbg_free+0x170 uma_zfree_arg() at uma_zfree_arg+0x150 vmspace_free() at vmspace_free+0xe4 swapout_procs() at swapout_procs+0x428 vm_daemon() at vm_daemon+0x74 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 db I have seen this on a couple of different arch's I think. A vmspace shouldn't be free'd here, it's refcount should not be that low. I wonder if something is free'ing the vmspace w/o dropping the refcount? The problem appears to be that swapout_procs() is swapping out a process that is in the process of exiting (in exit1()) and having already relinquished its vmspace, but has not set PRS_ZOMBIE yet (which would be preventing the swapout). It's clearly not correct for a process in exit1() to be swapped out, and the vmspace _needs_ to be decremented in the correct place or resources are NEVER freed when the race is lost. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA panic under load
Jake Burkholder [EMAIL PROTECTED] wrote: Apparently, On Sat, Dec 14, 2002 at 07:37:31PM -0500, Brian F. Feldman said words to the effect of; John Baldwin [EMAIL PROTECTED] wrote: On 12-Dec-2002 Kris Kennaway wrote: I got this on an alpha tonight. It was under heavy load at the time (18 simultaneous package builds had just been spawned on the machine). Any ideas? Slab at 0xfc00042d3fb8, freei 2 = 0. panic: Duplicate free of item 0xfc00042d22e0 from zone 0xfc0007d31800(VMSPACE) db_print_backtrace() at db_print_backtrace+0x18 panic() at panic+0x104 uma_dbg_free() at uma_dbg_free+0x170 uma_zfree_arg() at uma_zfree_arg+0x150 vmspace_free() at vmspace_free+0xe4 swapout_procs() at swapout_procs+0x428 vm_daemon() at vm_daemon+0x74 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 db I have seen this on a couple of different arch's I think. A vmspace shouldn't be free'd here, it's refcount should not be that low. I wonder if something is free'ing the vmspace w/o dropping the refcount? The problem appears to be that swapout_procs() is swapping out a process that is in the process of exiting (in exit1()) and having already relinquished its vmspace, but has not set PRS_ZOMBIE yet (which would be preventing the swapout). It's clearly not correct for a process in exit1() to be swapped out, and the vmspace _needs_ to be decremented in the correct place or resources are NEVER freed when the race is lost. P_WEXIT is set, so the process won't get swapped out. The problem is that the vmspace refcnt is 0 when swapout_procs is called, since it was decremented in exit1. The refcnt is incremented before p_flag is tested for P_WEXIT, the swapout is skipped because its found to be set, and then vmspace_free is called which decrements the refcnt to 0 and prematurely frees the vmspace. Decrementing the refcnt in exit1 breaks the normal refernce count semantics because the vmspace is not being freed then. There are no normal reference count semantics; exit1() attempts to free parts of the vmspace. Sounds to me like a simple solution is to check for P_WEXIT both before and after incrementing the vmspace refcount. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA panic under load
Matthew Dillon [EMAIL PROTECTED] wrote:
What about something like this. If the vm_refcnt is still being
decremented too early, could it be moved to just before the thread_exit()
call?
The problem that had to be fixed by removing this race was that two
processes with the same vmspace can exit at the same time, and the
vm_refcnt could be 2 the entire time, so neither would perform the current
if (--vm-vm_refcnt == 0) { block.
--
Brian Fundakowski Feldman \'[ FreeBSD ]''\
[EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \
Opinions expressed are my own. \,,\
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
fincore.c strikes again (panic bremfree: bp not locked)
I don't have any more info since for some reason the kernel wasn't saved
when my system dumped core, but yet again fincore.c causes evidence that
-CURRENT has regressed again. I can't find the old thread I'm thinking of,
but from a slightly different thread, bde knew what was going on. For
further reference:
#include stdio.h
#include unistd.h
#include stdlib.h
#include sys/types.h
#include sys/mman.h
#include fcntl.h
#include sys/stat.h
#include machine/param.h
#include errno.h
/*
** print pages of file in core
*/
void usage(char *name)
{
printf(Usage: %s [-ns] files...\n,name);
printf(\t-n\t\tDo not print filename\n);
printf(\t-o\t\tOnly print files with at least one page in core\n);
printf(\t-s\t\tDo not print file size in pages\n);
}
main(int ac,char **av)
{
int c;
int print_name = 1;
int print_sizepages = 1;
int only_nonzero = 0;
int status = 0;
while((c = getopt(ac,av,nos)) != -1) {
switch(c) {
case 'n':
print_name = 0;
break;
case 'o':
only_nonzero = 1;
break;
case 's':
print_sizepages = 0;
break;
default:
usage(av[0]);
exit(1);
}
}
for(; optind ac ; optind++) {
int fd;
int pind,pcount;
caddr_t addr;
struct stat statbuf;
size_t len;
size_t numpages;
char *pvec;
if (stat(av[optind],statbuf)) {
perror(stat);
status = 1;
continue;
}
if (!S_ISREG(statbuf.st_mode)) {
close(fd);
continue;
}
if ((fd = open(av[optind],O_RDONLY)) 0) {
perror(av[optind]);
status = 1;
continue;
}
if (fstat(fd,statbuf)) {
perror(fstat);
close(fd);
status = 1;
continue;
}
if (!S_ISREG(statbuf.st_mode)) {
close(fd);
continue;
}
len = statbuf.st_size;
numpages = len/PAGE_SIZE + ((len % PAGE_SIZE) != 0);
if (! (statbuf.st_mode (S_IFREG|S_IFCHR))) {
pcount = 0;
} else if (len) {
if ((addr = mmap(0,len,PROT_READ,MAP_SHARED,fd,0)) ==
MAP_FAILED) {
fprintf(stderr, mmap (%s): %s\n, av[optind],
strerror(errno));
close(fd);
status = 1;
continue;
}
pvec = malloc(numpages);
if (mincore(addr,len,pvec))
{
perror(mincore);
exit(1);
}
for(pcount = 0,pind = 0 ; pind numpages ; pind++) {
if (pvec[pind]) pcount++;
}
free(pvec);
if (munmap(addr,len)) {
perror(munmap);
exit(1);
}
} else {
pcount = 0;
}
if (pcount || !only_nonzero) {
if (print_name) printf(%s: ,av[optind]);
printf(%d,pcount);
if (print_sizepages) printf(/%d,numpages);
printf(\n);
}
close(fd);
}
exit(status);
}
--
Brian Fundakowski Feldman \'[ FreeBSD ]''\
[EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \
Opinions expressed are my own. \,,\
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
A couple of 5.0 RC#0 sysinstall issues
I just installed RC#0. It appears to be as good as some of the DP versions. I haven't done much with it yet, but a couple of minor sysinstall issues that are ugly. 1.) It appears, during install that devfs gets mounted on /dev twice. It doesn't appear to impact anything, its just an oddity. 2.) Doing a Custom install with a custom distribution set, I receive, on the first console: S:21494970 = (ff/ff/ff) E:2988-899 = (ff/ef/ff) S:29880900 = (ff/ff/ff) E:78172289 = (ff/ef/ff) 1S:63 = (0/1/1) E:128519 = (7/fe/3f) S:128520 = (8/0/1) E:120101939 = (ff/fe/ff) Note that these are scattered around on the display behind the front dialog box, so the order they appear, or if this is the entire message, I'm not sure. I'm guessing that there is some output that should be going to the debug console, rather than the install console. I'll report more as I find it. -B To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Diffs for TREK Smartdrive (8MB) support
The following patches apply to 5.0-CURRENT-DP2. They add support for the
Trek SmartDrive 8MB. I'm assuming that the other drives have differing product
numbers, but I don't have any other reference hardware to play with. However,
this may act as a good starting point for others who have the larger drives
available.
Overall, the performance appears slow (0.04MB/s), but given the small size,
its only mildly annoying. If any USB Wizards have suggestions for speeding
it up (the drive specs say that it should be ~500KB/sec read, and ~250KB/sec
for writes), I'll be happy to test them out.
I would like someone to commit this, and let me know when its in. Thanks.
-Brian
PS - I'll be looking at doing a patch for -STABLE, as well, but the USB
code looks very, very different
diff -r sys/dev/usb/umass.c sys/dev/usb.new/umass.c
325a326,330
{ USB_VENDOR_TREK, USB_PRODUCT_TREK_THUMBDRIVE_8MB, RID_WILDCARD,
UMASS_PROTO_ATAPI | UMASS_PROTO_BBB,
IGNORE_RESIDUE
},
diff -r sys/dev/usb/usbdevs sys/dev/usb.new/usbdevs
1070a1071
product TREK THUMBDRIVE 0x9988 ThumbDrive
diff -r sys/dev/usb/usbdevs.h sys/dev/usb.new/usbdevs.h
1078a1079,1080
#define USB_PRODUCT_TREK_THUMBDRIVE_8MB 0x9988 /* ThumbDrive */
diff -r sys/dev/usb/usbdevs_data.h sys/dev/usb.new/usbdevs_data.h
2573a2574,2580
{
USB_VENDOR_TREK, USB_PRODUCT_TREK_THUMBDRIVE_8MB,
0,
Trek Technology,
ThumbDrive,
},
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Are SysV semaphores thread-safe on CURRENT?
On Mon, 18 Nov 2002 22:05:34 -0800, Terry Lambert wrote: Use mmap of a backing-store file, and then use file locking to do record locking in the shared memory segment. Ok, I did this, and it actually works considerably better than the SysV shared memory. However flock() has the same problem as the SysV semaphores, where they block the entire process, allowing the same deadlock situation to occur. Has this flock() behavior changed in CURRENT? It seems like this behavior is much more likely to change than the SysV code. Thanks! Brian Smith To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DP2 iso crash on boot
On Tue, Nov 19, 2002 at 01:21:56PM -0500, Matt Haught wrote: With the DP2 iso (from ftp5), I get a crash on boot right after the acpi module is loaded. The error is (manually copied) and occured 5 out of 5 times that I tried: I recently worked on loading 5.0 onto a dual Xeon which panic'd in a similar way. You might be able to avoid the problem by stopping the loader before it boots the kernel, and issuing: unset ACPI_LOAD at the loader prompt. Then issue the boot command manually. That may get you going. If so, you should be able to add the following to your /boot/loader.conf file: exec=unset ACPI_LOAD Good luck! -Brian -- Brian Dean [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Are SysV semaphores thread-safe on CURRENT?
I've been porting an application from Linux to FreeBSD using STABLE, and it appears from looking at the semaphore code that the SysV semaphores are not thread safe on STABLE. I don't have CURRENT source code to look at currently. Does anyone know if they are thread-safe in CURRENT? Thanks! Brian Smith To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Are SysV semaphores thread-safe on CURRENT?
On Mon, 18 Nov 2002 21:33:38 -0500 (EST), Daniel Eischen wrote: [ I assume you mean semop, semctl, not sema_* or sem_* ] Yes ... semop() specifically is causing the problems... Sure SysV semaphores are thread-safe. When a thread blocks on one, the entire process blocks (no threads run). You won't get any safer than that ;-) Yikes that isn't good. Is that only in STABLE? or does CURRENT do that as well? I guess I'll have to protect the semop() call with a pthread mutex to prevent two threads locking a single semaphore by the same process (creating a deadlock situation). Is this the recommended method of preventing these problems? (the SysV semaphore is protecting shared memory accessed by multiple processes). Thanks for the info... it explains alot! Brian Smith To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Brian Fundakowski Feldman [EMAIL PROTECTED] wrote: I can't get more info because crash dumps don't work when this happens, but for what it's worth, here's a traceback which shows what happens when I attempt to use my da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device on an OHCI-based controller. This was working just a few days ago with a UHCI controller, so ... The crash is from an invalid read at 0xbff3e000, which is PTmap plus some offset. The trace as far as I can get it, from a kernel with USB but no options enabled, would be: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. Anyone? I kinda want to use my CF reader. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
UFS2 extended attribute corruption woes
) {
/* new, append at end */
p = eae + easize;
easize += ealength;
--
Brian Fundakowski Feldman \'[ FreeBSD ]''\
[EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \
Opinions expressed are my own. \,,\
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
Wow, spooky, I used to live at: 8716 W 70th Terr Shawnee Mission, KS 66204 Of course, that was back in the early 70's ;). Anyway, I might be able to get you a copy if you want 1. I have a spare 5.0-DP somewhere at one of my customers in Lenexa, or I could make a newer version. Unfortunately, I cannot get to my broadband connection until Thursday because I am staying with my wife at the hospital. If noone else sends you one, I will try to make one for you and mail it then. - brian On Tue, 22 Oct 2002, Juli Mallett wrote: * De: Soeren Schmidt [EMAIL PROTECTED] [ Data: 2002-10-22 ] [ Subjecte: Re: 5.0-RUSH: -current install testers wanted! ] It seems Juli Mallett wrote: Find another box where it has already been successfully installed, and an ISO image has been built from sources. I don't have a CD burner. I have no ability to burn a CD at all. Where do you live ? I'm sure we can find someone with a CD burner near you willing to make a copy and snailmail it to you... (Consider this a beg for anyone close enough for it to be cost effective to send me a 5.0-CURRENT snapshot CD, on which I can somehow disable the atkbdc/atkbd stuff at bootup, or which has them out of the kernel...) Juli Mallett 11145 W 76th Terrace Shawnee, KS 66214 United States Thanks for the idea :) juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message +---+--+ He rides a cycle of mighty days, and \ Wm Brian and Lori McCane represents the last great schizm among\ McCane Consulting the gods. Evil though he obviously is, \ [EMAIL PROTECTED] he is a mighty figure, this father of \ http://freenews.maxbaud.net/ my spirit, and I respect him as the sons \ http://www.sellit-here.com/ of old did the fathers of their bodies. \ http://recall.maxbaud.net/ Roger Zelazny - Lord of Light\ http://www.mccons.net/ +---+--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Josef Karthauser [EMAIL PROTECTED] wrote: Does this happen on a current with this patch applied too? I'm certain I tried this already :( -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSE
German Tischler [EMAIL PROTECTED] wrote: Hi. I can panic my current system compiled from sources of yesterday by just starting mozilla or ogg123 ogg-file if I don't include options CPU_DISABLE_SSE in my kernel configuration file. Is anyone else seeing any SSE code related problems ? (P III based SMP system here) Yes; I seem to have this problem on my system whether or not SSE is enabled, though. I've got a: CPU: AMD Athlon(TM) XP 2000+ (1666.65-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc040AMIE,DSP,3DNow! I'm trying to track it down, though. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSE
German Tischler [EMAIL PROTECTED] wrote: Hi. I can panic my current system compiled from sources of yesterday by just starting mozilla or ogg123 ogg-file if I don't include options CPU_DISABLE_SSE in my kernel configuration file. Is anyone else seeing any SSE code related problems ? (P III based SMP system here) Yes, I see the same problems with npxrestore() in sigreturn(), but on my Athlon it seems to occur with or without SSE. I'm trying to track it down... -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
vnode locking screwed up in src/sys/ufs/ffs/ffs_snapshot.c:ffs_snapshot()
I got a crash today because xvp did not have an interlock when the call was made to vn_lock(LK_INTERLOCK): 407 if (snapdebug) 408 vprint(ffs_snapshot: busy vnode, xvp); 409 if (vn_lock(xvp, LK_EXCLUSIVE | LK_INTERLOCK, td) != 0) 410 goto loop; 411 xp = VTOI(xvp); 412 I don't in fact see any reason why xvp would have been locked already and that this could possibly be valid in the face of a mountpoint which had any vnodes at all open. This occurred on fscking my /tmp filesystem because of crashes (due to an SSE utilization bug in the kernel, it seems), which I'm sure was a filesystem in heavy use already. Does anyone have any insight on what the correct fix to this is? I don't have any idea exactly how to correct the locking in this function. Thanks for insight! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
I can't get more info because crash dumps don't work when this happens, but for what it's worth, here's a traceback which shows what happens when I attempt to use my da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device on an OHCI-based controller. This was working just a few days ago with a UHCI controller, so ... The crash is from an invalid read at 0xbff3e000, which is PTmap plus some offset. The trace as far as I can get it, from a kernel with USB but no options enabled, would be: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSE
German Tischler [EMAIL PROTECTED] wrote: Hi. I can panic my current system compiled from sources of yesterday by just starting mozilla or ogg123 ogg-file if I don't include options CPU_DISABLE_SSE in my kernel configuration file. Is anyone else seeing any SSE code related problems ? (P III based SMP system here) I seem to have the same problem on my currently-UP Athlon system, whether or not SSE is enabled; I'm trying to track it down... -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic from _mutex_assert in kern_lock.c
Steven G. Kargl [EMAIL PROTECTED] wrote: The source tree was retrieved by cvsup at 21:47 (PST) on Oct 4. This is a non-GEOM and non-acpi kernel. I have the core and kernel.debug, so any further postmortem is possible. I think the problem is that in src/sys/ufs/ffs/ ffs_snapshot.c:ffs_snapshot(), as the mnt vnode list is traversed none of the vnodes (xvp) would actually GET VI_LOCK()ed in the first place, and so the LK_INTERLOCK is bogus in the vn_lock() call. Kirk would know for sure what to do about this... -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic from _mutex_assert in kern_lock.c
Steven G. Kargl [EMAIL PROTECTED] wrote: Brian F. Feldman said: Steven G. Kargl [EMAIL PROTECTED] wrote: The source tree was retrieved by cvsup at 21:47 (PST) on Oct 4. This is a non-GEOM and non-acpi kernel. I have the core and kernel.debug, so any further postmortem is possible. I think the problem is that in src/sys/ufs/ffs/ ffs_snapshot.c:ffs_snapshot(), as the mnt vnode list is traversed none of the vnodes (xvp) would actually GET VI_LOCK()ed in the first place, and so the LK_INTERLOCK is bogus in the vn_lock() call. Kirk would know for sure what to do about this... I came to the same conclusion after I sent the original email. What I don't understand is how I ended up in ffs_snapshot(), because I don't have a snapshot of /var. I tried snapshots when Kirk first introduced the feature, but I removed all of the snapshots a long time ago. Is there a flag in the superblock that I need to clear? One other point, the machine was doing a background fsck on /var. Does a background fsck go through ffs_snapshot()? Exactly: background fsck takes a snapshot to work on. I think background_fsck=NO is a good workaround at the moment for this. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSE
Brian F. Feldman [EMAIL PROTECTED] wrote: German Tischler [EMAIL PROTECTED] wrote: Hi. I can panic my current system compiled from sources of yesterday by just starting mozilla or ogg123 ogg-file if I don't include options CPU_DISABLE_SSE in my kernel configuration file. Is anyone else seeing any SSE code related problems ? (P III based SMP system here) I seem to have the same problem on my currently-UP Athlon system, whether or not SSE is enabled; I'm trying to track it down... On further reflection, this DEFINITELY has to do with the work done on npx(4)/signals/etc. in the past week. I _must_ be getting a GPF because the fpu state that it's attempting to restore is corrupt (i.e.: the control word is incorrect), so something is not being initialized somewhere that it used to be, or is being initialized incorrectly. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM problems?
walt [EMAIL PROTECTED] wrote:
Just finished making world and kernel at about 01:00 GMT Oct 6.
dmesg includes this printout:
Initializing GEOMetry subsystem
ad0: 76319MB ST380021A [155061/16/63] at ata0-master UDMA100
ad2: 42934MB WDC WD450AA-00BAA0 [87233/16/63] at ata1-master UDMA66
acd0: CD-RW R/RW 4x4x24 at ata1-slave PIO4
Mounting root from ufs:/dev/ad2s2a
00 01 c1 ff 83 fe ff ff 3f 00 00 00 06 5b 5f 00 |?[_.|
[0] f:00 typ:131 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:6249222
00 00 c1 ff 05 fe ff ff 45 5b 5f 00 b3 f1 5a 00 |E[_...Z.|
[1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:6249285 l:5960115
00 01 c1 ff 07 fe ff ff 3f 00 00 00 74 f1 5a 00 |?...t.Z.|
[0] f:00 typ:7 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:5960052
00 00 c1 ff 05 fe ff ff f8 4c ba 00 e2 05 18 00 |.L..|
[1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:12209400 l:1574370
many more lines snipped
Is this normal output now?
Sounds like debugging prints that should probably not be enabled by
default...
And there's this:
#disklabel ad0
disklabel: ioctl DIOCGDINFO: Operation not supported by device
#disklabel -r ad0
disklabel: bad pack magic number (label is damaged, or pack is unlabeled)
Same errors with ad2.
All the partitions do mount and seem to work OK, so I'm not sure how
much of this is expected behavior.
Are you using dangerously-dedicated disks? That is, no fdisk-style
partition table? If so, disklabel on ad0 or ad2 itself would be valid. It
doesn't appear you are, in which case a disklabel operation should be
performed on the slice, e.g. disklabel ad2s2.
--
Brian Fundakowski Feldman \'[ FreeBSD ]''\
[EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \
Opinions expressed are my own. \,,\
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: make install failed on XFree86-4-client (with 6/10 -current)
Well, this has been happening for about a year on my dev box. It's not gcc 3.1 specific. I've never gotten around to figuring out why it works on some machines. On Sat, 29 Jun 2002 19:41:51 -0700, David O'Brien wrote: On Sat, Jun 29, 2002 at 11:30:48PM +0100, Brian Somers wrote: The problem is because the glxinfo program uses CCLINK to link, but it's a c++ program. Changing the CCLINK to CXXLINK works. We can't be the only ones seeing this -- surely anyone using Gcc 3.1 on their i386 (any OS) box. Has anyone [that cares] emailed any of the XFree86 guys?? -- Brian [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.Awfulhak.orgbrian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make install failed on XFree86-4-client (with 6/10 -current)
I've been seing this problem for ages on my dev box, but it doesn't happen on other boxes. The problem is because the glxinfo program uses CCLINK to link, but it's a c++ program. Changing the CCLINK to CXXLINK works. I have no idea why there's no problem on some machines. On Mon, 17 Jun 2002 12:09:14 +0800, Ying-Chieh Liao wrote: make build all ok, but failed on install should I rebuild world first ? installing in programs/glxinfo... rm -f glxinfo LD_LIBRARY_PATH=../../exports/lib cc -o glxinfo -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -L/usr/X11R6/lib -lc_r -lm -Wl,-rpath,/usr/X11R6/lib /usr/X11R6/lib/libGLU.so: undefined reference to `operator new[](unsigned)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete(void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `__gxx_personality_v0' /usr/X11R6/lib/libGLU.so: undefined reference to `__cxa_pure_virtual' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete[](void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator new(unsigned)' *** Error code 1 Stop in /usr/ports/x11/XFree86-4-clients/work/xc/programs/glxinfo. *** Error code 1 -- self-producing in perl : $_=q(print\$_=q($_);eval;);eval; -- V Vinay -- Brian [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.Awfulhak.orgbrian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
memory/swapping problem
I am having a problem with a new server that I am setting up to host my UseNet news and email. Machine: 1.26GHz 512MB/L1 Cache 768MB PC133 Memory 4x60GB UDMA100 IDE Drives 4x36GB 160MBit SCSI Drives OS: 5.0-CURRENT (yes I know, but I have been CURRENT since 386bsd 0.1) Software: INN 2.3.3 Sendmail w/amavisd milter ipop3d This machine has been running for about 2 months on CURRENT with no problems, but I recently upgraded the CPU from an 866 to the new one. At that time, I also planned to replace the motherboard with a new Intel SAI2 dual processor board, add a 2nd processor and drop in 3x512MB ECC Registered DIMMs. So I built and installed a more current CURRENT and added SMP to the config for my kernel. The motherboard was defective, so I put back in the original board and memory chips, while I wait for the replacement board. The 2nd night after the build was done, I started having memory/swap/wired problems. I rebuilt the kernel for UP operation, but the problems have not gone away. Machine averages about 95% idle all day except during news expiration. For the first day, it averages around 45M wired. 'inn' process is about 137MB RSS. During expiration there is an understandable spike in CPU and Swap activity. 'expire' process is about 259MB RSS. When the expiration completes there is about 254MB still wired. The second night it goes to 500+MB wired and the system never finishes expiration before I get a call that email is down. I have actually gone out and killed every process running on the machine that I can (including inetd, syslogd, cron, sshd, sendmail and inn). The wired memory is never released until I reboot the machine. Any ideas (other than going to STABLE :)? - brian +---+--+ He rides a cycle of mighty days, and \ Wm Brian and Lori McCane represents the last great schizm among\ McCane Consulting the gods. Evil though he obviously is, \ [EMAIL PROTECTED] he is a mighty figure, this father of \ http://bmccane.maxbaud.net/ my spirit, and I respect him as the sons \ http://www.sellit-here.com/ of old did the fathers of their bodies. \ http://recall.maxbaud.net/ Roger Zelazny - Lord of Light\ http://www.maxbaud.net/ +---+--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Automagic Reboots
Sid Carter [EMAIL PROTECTED] wrote: Hi, This is so cool ;) I just got rebooted again, :D The messages show this. --- Jun 25 18:06:30 calvin kernel: /usr/src/sys/vm/uma_core.c:1331: could sleep with process lock locked from /usr/src/sys/kern/kern_exec.c:321 Jun 25 18:21:19 calvin syslogd: kernel boot file is /boot/kernel/kernel Jun 25 18:21:19 calvin kernel: Memory modified after free 0xc2cb9800(252) Jun 25 18:21:19 calvin kernel: panic: Most recently used by kqueue I've actually seen this, too; not been able to track it down at all, though. At the moment, I've checked everywhere obviously M_KQUEUE memory is alloced and dealloced and have no good leads. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Floppy only 8.3 filenames
- Original Message - From: Jan Stocker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, June 22, 2002 4:50 PM Subject: Re: Floppy only 8.3 filenames /dev/ad0s1 /dosmsdos rw 0 0 looks quite longfilenamed on my FAT32 slice since ages... On Sat, 2002-06-22 at 22:48, Peter Hessler wrote: MS-DOS can only handle 8.3 file names. It's by design (MS not FreeBSD). /snip/ mount -t msdos /dev/fd0 /mnt /snip/ -- Peter Hessler [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message ugh top-posting... perhaps try forcing it with -o longnames ? Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/ +[+++[-]-]+..+.+++.-.[+---]++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade instructions are incorrect
- Original Message - From: M. Warner Losh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, May 22, 2002 2:04 PM Subject: Re: Upgrade instructions are incorrect This seems exactly backwards. Warner Unlike replying to something without including a shred of context, to half-a-dozen addresses including a mail list, to which all the other recipients are probably subscribed anyways. Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/ +[+++[-]-]+..+.+++.-.[+---]++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
no matter which kernel I try to boot. Booting my new kernel with the old loader (from the DP1 dist) works fine until it tries to start init(8): spec_getpages: preposterous offset 0xfff8f446 exec /sbin/init: error 5 spec_getpages: preposterous offset 0xfff81426c000 exec /sbin/init.bak: error 5 spec_getpages: preposterous offset 0xfff8c86c exec /stand/sysinstall: error 5 init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall panic: no init panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 Booting DP1's GENERIC with the old loader and the new userland works fine. Clean tree, no funny stuff in make.conf (unless 'CPUTYPE?=ev56' counts as funny stuff) This was fixed an hour or so ago. Phk backed out the daddr_t size change pending investigation. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
Brian Somers [EMAIL PROTECTED] writes: This was fixed an hour or so ago. Phk backed out the daddr_t size change pending investigation. Does that fix the loader too, or just the kernel? I'm not sure, I'm just rebuilding now. Remember, /boot/loader.old is left around... handy in this situation (I'd forgotten 'till jhb pointed it out). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: loader failure
Brian Somers [EMAIL PROTECTED] writes: This was fixed an hour or so ago. Phk backed out the daddr_t size change pending investigation. Does that fix the loader too, or just the kernel? I'm not sure, I'm just rebuilding now. Remember, /boot/loader.old is left around... handy in this situation (I'd forgotten 'till jhb pointed it out). Yes, the daddr_t backout has fixed the loader and the filesystem problems. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT and P-IV problems
On Sat, May 04, 2002 at 09:26:33PM +0100, Brian Somers wrote:
Try disabling -pipe when building the compiler. This seems to make
things more stable here (CFLAGS=-O in /etc/make.conf) - as if
building the kernel with -pipe sometimes produces a kernel that
subsequently murders the compiler with sig11/sig4 all the time.
If so, then we have a bug in our pipe ('|', not 'gcc -pipe')
implimentation.
That would seem to be the case - assuming my hypothesis is correct -
which is far from being a sure thing at this point.
If things stay stable for the next week or so, I'll set the machine
up to start doing parallel builds and see where we go from there...
--
Brian [EMAIL PROTECTED][EMAIL PROTECTED]
http://www.freebsd-services.com/brian@[uk.]FreeBSD.org
Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Problems with Dell Inspiron 2500/NEWCARD/Xircom CBEM56G
Scott Penno [EMAIL PROTECTED] wrote: I removed apm from the kernel which appeared to be playing having with acpi and things are now working a treat. The card works fine, however I do receive the following message, 'cardbus0: unknown card (vendor=0x115d, dev=0x0103) at 0.1 irq 5'. I've had a look through various lists and couldn't find a resolution. Is this a real drama and if so, how do I correct it? I believe that's the modem device on the card. I don't believe that it is in fact a normal serial port in any case, so it's worth just ignoring in my opinion. (Witness the address 0.1, where the Ethernet was probably found at 0.0). Sound about right? -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT and P-IV problems
Hi, Try disabling -pipe when building the compiler. This seems to make things more stable here (CFLAGS=-O in /etc/make.conf) - as if building the kernel with -pipe sometimes produces a kernel that subsequently murders the compiler with sig11/sig4 all the time. This is just marginally more than theory at the moment though. You may need to bootstrap a new kernel by building it on another machine to get things running again. Hi all, I experiment very strange problems here at the moment with a new server. Buildworld survives about 30 secondy, the errors are SIG4 (90%) and SIG11 (10%). And I cannot compile any important programs :-/ I've exchanged all relevant parts: - Power Supply: 300W, for PIV with additional CPU supply - CPU (PIV, 2Ghz, 512K cache) - Ram with ECC correction - Board (Intel D845BG) - SCSI Card. (it happens also on ATA) We have these boards running fine here. And now to the strange part. It does not happen with STABLE. This let's me beleave that this is a CURRENT problem. I'm really really pointless. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfilter not broken for me
On Sat, Apr 27, 2002 at 04:01:28PM +1000, Darren Reed wrote: In some email I received from Doug Barton, sie wrote: On Fri, 26 Apr 2002, Ruslan Ermilov wrote: =20 I tested this on i386 only with 2 days old -CURRENT (today's is broken due to the import of latest IPFilter suite) =20 I updated to the latest and greatest last night around midnight and built/installed -current just fine. What about the ipfilter import = is broken, and have you let Darren know? I haven't seen anything on the li= sts about it... =20 I have not received any email about it. I tested building all the ipfilt= er binaries and kernel after the import and came up clean. if ref5 was a bit quicker =20 That was probably a local problem on one of the Brian's fast machines where I initially attempted to finally test my patch (unsynched cvsup update?). Sorry for the false alarm, I can't check it right now anyway. Yes... I've had periods where the compiler drops cores all over the place, and other periods where things work fine. It's on a P4-1.7Ghz and has behaved like this since about last August. The only variable is the kernel - some kernels work and some don't. I've spent many 10s of hours trying to track it down, and I still have no idea what causes it - except that some kernels ``just work'' and some don't. Maybe it depends on the humidity in the room when a kernel is built or something - and I'm only half joking here ! FWIW ru, /boot/kernel/kernel seems ok now. /boot/kernel.sig/kernel isn't. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Revision 1.88 of kern_linker.c breaks module loading for diskless
In message [EMAIL PROTECTED], Harti Brandt write s: the check for rootdev != NODEV introduced in rev 1.88 breaks loading of kernel modules from an NFS mounted root in diskless configurations. Dropping in gdb and printing rootdev shows -1 which is, I assume, NODEV. Ah, that would explain a problem I saw recently on a netbooted box where kldload only worked with full module paths. Could `rootvnode' be checked for NULL instead? Hi, The intent is to discover whether there's a filesystem yet (vn_open() will die horribly otherwise). My use of rootdev is (obviously) flawed. AFAICT, either rootvp or rootvnode should be used, but I can't tell the difference between the two at a glance and am lacking development resources right now (my development box seems to enjoy dropping cores too frequently to build a kernel at the moment). If somebody could test that rootvnode or rootvp are non-NULL after an NFS-mounted root is set up, I'd thankfully approve the quick fix... :*) Cheers. Ian -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory overwrite problem in the -current kernel ??
On Tue, Apr 23, 2002 at 01:54:17PM +0200, Poul-Henning Kamp wrote: This commit detects a memory overwrite problem in the kernel which happens before we ever get into userland for the first time. Do you know the address being corrupted? If so, try breaking into ddb early on and set a hardware watchpoint. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/usr.sbin/ppp Makefile async.c async.h atm.c bundle.c ccp.c ccp.h chap.c chap.h chat.c command.c datalink.c datalink.h defs.c defs.h ether.c exec.c i4b.c lcp.c lcp.h main.c mppe.c netgraph.c netgraph.h physical.c physical.h route.c tcp.c ...
Hello. brian 2002/03/30 04:30:11 PST Modified files: usr.sbin/ppp Makefile async.c async.h atm.c bundle.c ccp.c ccp.h chap.c chap.h chat.c command.c datalink.c datalink.h defs.c defs.h ether.c exec.c i4b.c lcp.c lcp.h main.c mppe.c physical.c physical.h route.c tcp.c tty.c udp.c : 1.126 +13 -17src/usr.sbin/ppp/bundle.c In the 6th chunk, a decrement to bundle.unit after succeeding ID0kldload() is lost. This results in the unit number of tun device set to 1(tun1) instead of 0(tun0) when if_tun.ko is not yet kldload'ed() before ppp is invoked. If I exit from ppp and start it again, ppp uses tun0, leaving tun1 behind. After that and receiving a few megabytes, I've experienced a mysterious panic (getnewvnode: free vnode isn't). The panic itself, though, is something similar to that I'm always seeing whenever I didn't kill pccardd before doing acpiconf -s3, so it might be unrelated to this issue. Anyway, a patch is attached. Regards. [.] Committed - thanks. I'd seen that it was doing this, but hadn't got around to tracking it down :*) I don't think the vnode thing is associated. That's probably a locking problem that jhb may (or may not) have fixed already. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mktime() doesn't fix deadzones...
Hi, I've cc'd -standards as I think this would be of interest there. IMHO the SQL code you quote in the PR should fail with an ``invalid time'' error. Personally I like the fact that mktime() returns -1 - it allows date's -v option to act sanely, although I must admit it was a PITA to get right. The really big question is, how can you ``fix'' mktime() ? If a value of 2002-4-7 2:0:0.0 becomes 2002-4-7 3:0:0.0 PDT, then you can deduce that 2 == 3 and go on to deduce other equally bizarre things Thinking about it makes my head hurt ! I haven't read POSIX yet, but mktime() fails on the boundary condition blackholes when timezones change. I just filed a patch for the PostgreSQL port so that it deals with this problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D36954 I believe that Linux and SunOS handle this automatically and am wondering if FreeBSD should too (this was the 1st time the PostgreSQL guys had heard of this in over 6 years). I'm not a daylight savings expert, but am wondering what other people think. Seems like a good idea(TM) to me. For example (PST/PDT assumed): 2002-4-7 2:0:0.0 should be: 2002-4-7 3:0:0.0 Anyone object or have any thoughts? -sc -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: segfault in getpwuid()?
Yes, I think I can !
I'll bet the binary in question is using libc.so.4 *AND* libc.so.5
because of a third library that has a libc.so.4 dependency.
This confused me for quite some time with apache.
for f in /usr/local/lib/*.so
do
objdump -x $f 2/dev/null | grep -q NEEDED.*libc.so.4 echo $f
done
Can anyone explain this to me?
#0 0x286613cc in _ftello () from /usr/lib/libc.so.5
#1 0x28661358 in ftello () from /usr/lib/libc.so.5
#2 0x286612f6 in ftell () from /usr/lib/libc.so.5
#3 0x28678ef7 in .cerror () from /usr/lib/libc.so.5
#4 0x28676c9e in isatty () from /usr/lib/libc.so.5
#5 0x2865f621 in _nsyy_init_buffer () from /usr/lib/libc.so.5
#6 0x2865f577 in _nsyy_create_buffer () from /usr/lib/libc.so.5
#7 0x2865e9c3 in _nsyylex () from /usr/lib/libc.so.5
#8 0x28657680 in _nsyyparse () from /usr/lib/libc.so.5
#9 0x2865905d in _nsdbtget () from /usr/lib/libc.so.5
#10 0x286591dc in nsdispatch () from /usr/lib/libc.so.5
#11 0x2863085a in getpwuid () from /usr/lib/libc.so.5
#12 0x2814db0e in g_get_any_init () at gutils.c:539
#13 0x2814ddb9 in g_get_home_dir () at gutils.c:623
#14 0x2859bd97 in gnomelib_init () from /usr/X11R6/lib/libgnome.so.5
#15 0x282123bf in gnome_init_with_popt_table ()
from /usr/X11R6/lib/libgnomeui.so.5
#16 0x282124ae in gnome_init () from /usr/X11R6/lib/libgnomeui.so.5
#17 0x281765b5 in gnome_CORBA_init () from /usr/X11R6/lib/libgnorba.so.5
#18 0x805dddb in main ()
#19 0x8058ee5 in _start ()
A listing at #12:
534 # endif /* !HAVE_GETPWUID_R */
535
536 if (!pw)
537 {
538 setpwent ();
539 pw = getpwuid (getuid ());
540 endpwent ();
541 }
542 if (pw)
543 {
(that's from glib12)
This makes panel,gnome-session, etc all crash on start.
-current as of this morning.
-Seth
--
Brian [EMAIL PROTECTED][EMAIL PROTECTED]
http://www.freebsd-services.com/brian@[uk.]FreeBSD.org
Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: The sendmail discussion...
On Thursday 28 March 2002 06:39 am, Robert L Sowders wrote: | Greg is absolutely correct. | | These whiners, who constantly moan for code while never contributing any, | should contribute the code if they want it changed. | | Also I shudder to think that those who customize their systems would | actually learn how to use all the tools available to them to prevent a | makeworld from overwriting or undoing their customizations. :) I was sorta wondering about that . . . The whole mailwrapper takes care of this anyway, doesn't it? At least that's what it's there for . . . don't you just re-install the port and voila! life is good again? | I wish that we could assign a bitch rating to some of these emails. Say a | sliding bitch scale depending on how much code the bitchee has | contributed. Then they could easily be filtered to /dev/null. | Waddayathink? ;) So what you are saying is that you never want people to use (or at least to customize) FreeBSD unless they are FreeBSD developers? That's the most extreme version of we won't care about who uses it that I've ever heard. The fact is, it's a lot more convenient for all FreeBSD users if the user base is expanded because it makes hardware and software vendors pay more attention to FreeBSD. So *some* accomidation to people who are at least willing to get their hands dirty with scripts is in the interest of the entire FreeBSD community. Sure, you don't want to lose all the benefits of FreeBSD in a mad rush to accomodate the masses -- I left the Linux fold in part becuase I felt that the mainstream distributions, at least, were going too far to do that, but it's certainly possible to go too far in the other direction as well. | Much ado about nothing, so far, RTFM. | | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with unsubscribe freebsd-stable in the body of the message -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_mtxpool.c src/sys/sys kernel.h src/sys/vm vm_fault.c vm_glue.c vm_map.c vm_map.h vm_pageout.c vm_zone.c
Matthew Dillon [EMAIL PROTECTED] wrote:
:
:Hi,
:
:Sorry to unwantedly butt in, but the patch supplied by Seigo actually
:solved the vm_map.c locking problems which used to come up on my system.
:Just some info. :)
:
:Regards,
:
: -- Hiten Pandya
: -- [EMAIL PROTECTED]
It fixed some things, it broke some things. Pretty much standard
fare for anyone who has ever done work on the vm_map lock, including
yours truely. John Dyson couldn't get it right, David Greenman couldn't
get it right, I couldn't get it completely right... getting it to do
the right thing even under -stable is difficult, which is why I am
suggesting that it simply be made into an exclusive lock in -current.
In addition to the fact it doesn't actually serialize the general
modification of the vm_map {} structure itself, just certain kinds of
changes, so is easily a primary reason that the VM system as it stands now
is inherently single-threaded.
--
Brian Fundakowski Feldman \'[ FreeBSD ]''\
[EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \
Opinions expressed are my own. \,,\
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
On Friday 15 March 2002 08:53 pm, Kenneth Culver wrote:
| (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
| /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
|demand paged dynamically linked executable
|
| Now, if you'd like to talk Netscape into building a version intended for
| a version of FreeBSD newer than, say, 3 years, 3.5 months (approximately)
| old...
|
| I didn't realize anyone still used netscape 4.x. It's so disgustingly
| unstable and slow.
Well, the linux-netscape 4 is the only browser I know that can handle Java
pages on FreeBSD.
Are there others?
If you mean the FreeBSD-native netscape 4.x; yes, it's perfectly silly to run
*that*.
|
| Ken
|
|
| To Unsubscribe: send mail to [EMAIL PROTECTED]
| with unsubscribe freebsd-hackers in the body of the message
--
Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work)
Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal)
ME -- http://www.babbleon.org
http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
To this end, we would like to request that commits for the next 7 days to HEAD be made with special care. -CURRENT is in pretty good shape right now, so we're not requiring approval for all commits. I have a Perl-5.6.1 upgrade. Is that too risky? Apart from the perl stuff itself, there are some other makefiles and mtree things that need to be done. Also the ports will be affected (not by very much). It's probably worth holding off for now and committing it after the 7 days. The 2 months between then and the DP2 release can shake out any problems it causes. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
As discussed at BSDCon, the release engineers are committed to releasing a relatively stable snapshot of FreeBSD -CURRENT on or around April 1, 2002. Obviously, a lot of major components are still in progress, but a great deal of work has already been accomplished, and could benefit from the additional exposure that a polished snapshot with full package set and documentation will provide. I don't know if this is something worth making it the snapshot, but currently kde doesn't work due to binuntils update. It may work now after the most recent binutils update, but we have to recompile kde to see that I believe, andkdelibs cannot be compiled which builds kde-config which the rest of the kde meta-ports try to run. I think that last sentence is a huge run on and I by no means am trying to complain, just wondering if anyone thinks its important to make it on this snapshot. If you're referring to the problems loading libpng.so (and probably other shared libraries), I can confirm that it's been fixed now. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Is Adaptec ATA Raid Supported
I am looking for a mid-range Raid solution for my database server. I hate to put down a significant chunk of change for SCSI Raid for a website that still doesn't quite pay its bills. Now for my question. I was looking at an: Adaptec ATA RAID 2400A controller card. It is a four channel ATA/100 raid controller with up to 128MB onboard cache and it support Levels 0,1,0+1 and 5. Looks real promising, but I cannot see any support for it in ata-raid.[ch]. Will the current code support this card? Or are there plans to add it in the near future? tia, - brian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lomac
Logan weaponx [EMAIL PROTECTED] wrote: Is there a reason lomac_enable isn't in /etc/defaults/rc.conf? I've only had a brief look so excuse this email if i'm in error and the answer is glaringly obvious. It's mostly that it still needs several features of the kernel which aren't currently there to be fully-functionalI don't think there would be any harm in adding it, though, and saying as much in /etc/defaults/rc.conf :) -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT in pretty good shape, after all
- Original Message - From: Szilveszter Adam [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, February 24, 2002 1:04 PM Subject: Re: -CURRENT in pretty good shape, after all On Sun, Feb 24, 2002 at 06:22:11AM +0200, Giorgos Keramidas wrote: It does work perfectly nice for me too, here. I've been building worlds without a single problem ever since Feb 7, 2002. Oh, and since I like living in the edge, I erased my 4-STABLE installation on Feb 10, and formatted that partition. Now I use it as /c, a workspace where temporary development work is done. Well, just to put my Me too! here. I have been following 5.x for as long as it existed and during all this exercise, I have found it to be fairly useable at all times. There were some bumps along the road, but nothing that a careful study of this and other mailing lists would not have solved. In fact, ever since 5.x branched from 4.0 way back when:-) it was the only installation of FreeBSD that I had on my workstation. I wrote my university thesis on this machine, while religiously keeping up with the latest and greatest -CURRENT source, the box has served as a dialup and later as an ADSL gateway without problems. Of course, debugging code has slowed it down at times but that was expected. Although I do not consider myself a developer/programmer, I always tried to report problems in a useful way when found. It is just that I did not have a lot to do on this front:-) (Maybe I am the kind of user who should start using -CURRENT in greater numbers? OK, I'm here already:-) This machine is a PII-233 UP, with an Intel 440-LX based mobo and only IDE peripherals. It is no longer state of the art or even close, but, thanks to FreeBSD, it runs as snappy as ever. Thank you all, who have put efforts in making this happen! Indeed. It is really refreshing to see that, despite occasional ramblimngs and otbreaks of flame on the lists, the project really makes headway, especially looked at from a historical perspective. Keep up the good work! P.S.: This message is also test to see if the upgrade to the latest sendmail worked well:-) another me too I have had a 5.0 box running continuously for several months, I don't use the box much but I do use it a little at least a few times a day. It just sits there on my cable modem at home and I use it as a samba (pre-3.0beta) server for mp3's at home, or via http/ftp from work. It's been running seti@home since day one, I use it to test ssh and rsync procedures and other miscelaneous things where I need a unix box to try something on and don't want to use a customers machine. I have done a couple buildworlds and buildkernels but only a couple and not in months, but it went without a hitch. I have built a few ports like vnc and samba, again no hitches and again the results have also been running for months. there was a problem with my mouse for a while, I applied a patch from a post on this list, rebuilt and no more mouse problem. all in all, it's been just great for me even though it's a pretty old -CURRENT. oh and the hardware is just a crappy emachine with an amd k6-2 350 (running at 385) that was a desktop win98 machine at a customers that they threw away for being too old and slow. I just put in a new power supply and a little ram and it's been a damned fine freebsd box for me. neven gnome and enlightenment and gimp and netscape et al are fast enough to be useable, although I did disable gnome and E in favor of icewm just on general principle. Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/ +[+++[-]-]+..+.+++.-.[+---]++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB detach crashes possibly fixed
Paul van der Zwan [EMAIL PROTECTED] wrote:
On 14-Feb-2002 (08:29:50/GMT) Brian Fundakowski Feldman wrote:
Please try this change (already committed to -CURRENT) and let me
know if crashes due to detaching USB devices specifically have been
eliminated.
I cvsupped on Feb 14, 20:21 CET (GMT+1, Italian time), recompiled
both world kernel (yes, runned mergemaster also :-) and messages
show that device attach and detach (before I got only attach)
...kernel: uscanner0: EPSON Perfection1240, rev 1.00/1.14, addr 2
...kernel: uscanner0: at uhub0 port 1 (addr 2) disconnected
...kernel: uscanner0: detached
_BUT_
I lost /dev/speaker. I don't know if this is related to patch but
with my previous installed build (a bit old, of December 11, 2001)
I have those lines on /etc/usbd.conf:
attach /bin/chmod 666 /dev/${DEVNAME} echo L16cce /dev/speaker
detach echo L16eec /dev/speaker
and I got a small tune on attach but nothing on detach.
Now I am unable to play notes on /dev/speaker. Any hint?
As Terry notes, shouldn't possibly be related.
I have no crashes but the detach action is never executed when I switch off
my Sony camera ( it has never worked as far as I know)
Attach actions are executed fine..
Have you tried compiling in all available USB debugging support or seeing if
anyone else is using one like yours?
--
Brian Fundakowski Feldman \'[ FreeBSD ]''\
[EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \
Opinions expressed are my own. \,,\
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
USB detach crashes possibly fixed
Please try this change (already committed to -CURRENT) and let me know if crashes due to detaching USB devices specifically have been eliminated. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/usb.c.diff?r1=1.54r2=1.55f=h -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Saturday 02 February 2002 03:57 pm, Juha Saarinen wrote: On Sat, 2 Feb 2002, Brian T.Schellenberger wrote: No, it's not, because it still maintains a separation between system control (rc.conf) and application control (/var/packges). It's more like config.sys or something . . . Much more than that. The registry also stores dynamic data, such as performance counters. It's also remotable, for centralised management. No, no, I was saying that *rc.conf* was more like config.sys than the registry. The registry is a huge monolithic monstor of an abomination from hell. Not that I don't like it or anything :-) -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Saturday 02 February 2002 06:15 am, Terry Lambert wrote: Wilko Bulte wrote: I would add differences like: the M$ registry is bound to be corrupted, is only accessible by obscure tools, is for the best part not documented In other words why should FreeBSD adopt something like that? rc.conf is a registry in all but tools. 8-). No, it's not, because it still maintains a separation between system control (rc.conf) and application control (/var/packges). It's more like config.sys or something . . . -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Friday 01 February 2002 07:26 pm, Terry Lambert wrote: foo_enable=NO ipfilter_enable=YES firewall_enable=NO natd_enable=NO natd_interface=fxp0 inetd_enable=NO inetd_program=/usr/sbin/inetd foo_enable=YES/NO foo_enable=NO Who is a GTK hacker? Does someone want to write a registry editor program? Yuch. Why? The point of the program would be to edit the FreeBSD Registry, rc.conf, and make it look just like the Windows Registry in the editor, using _ as the implied path component/terminal component (key) seperator. You are surely insane. Or trying to make a point which isn't true, which is pretty similar. Then we can all be honest with ourselves that the only difference between it an the Windows Registry is that the Windows registry is accessible/modifiable from kernel mode, and the path component and key names. No, there's are enormous differences: - There's a well-known plain-text file so it can be readily backed up and restored. - There is not a single point of failure for all progams; it only controls basic system functions and services, it does not control applications, so if it fails, your applications aren't all screwed up, and if your applications screw up terribly they can't corrupt your basic system. Indeed, the lack of an API to *write* to /etc/rc.conf is one of it's greatest strengths: It is far less vulnerable to major corruption if things go nutty. You can start with: My Computer\HKEY_LOCAL_MACHINE\natd NameData --- - enable NO interface fxp0 My Computer\HKEY_LOCAL_MACHINE\inetd NameData --- - enable NO program /usr/sbin/inetd etc. If you want to get ambitious: o Make HKEY_LOCAL_MACHINE an alias for your node name, and include your node name in the list. o Call it localhost, if you are feeling too guilty about calling it HKEY_LOCAL_MACHINE. o Make the tool operate on node names other than localhost, so you can do remote administration of configuration files on a cluster of FreeBSD boxes o Add more subkeys; perhaps it should not be just My Computer\localhost\inetd but My Computer\localhost\rc.conf\inetd letting you fold in the other files, like the inetd.conf, into registry handlers, e.g.: My Computer\localhost\inetd.conf\telnet enable NO sockettype stream protocoltcp waitNO userroot program /usr/libexec/telnetd etc.. o Support sysctls in the HKEY_DYN_DATA and HKEY_CURRENT_CONFIG sections (for those that can go into loader.rc). Sure, people would be annoyed to find out that they had been moving towards an idea that Microsoft had developed, but wouldn't this be a fun tweak to people's tails? 8-) 8-) 8-) -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Friday 01 February 2002 08:38 pm, Terry Lambert wrote: Brian T.Schellenberger wrote: - There is not a single point of failure for all progams; it only controls basic system functions and services, it does not control applications, so if it fails, your applications aren't all screwed up, and if your applications screw up terribly they can't corrupt your basic system. firewall_enable=NO I wouldn't think of a firewall as an application program. I can be certain that installing or corrupting or otherwise screwing up my text editor, my image-editing program, by CD-management program, my financial program, my DVD-viewing program, my newsreader, or my browser won't break my firewall. That's the big drawback of the stupid registry idea. Indeed, the lack of an API to *write* to /etc/rc.conf is one of it's greatest strengths: It is far less vulnerable to major corruption if things go nutty. vi? sed? any text editor? Yes, but application programs aren't writing to it. You only write to it when you set down to do it. So vi acts like regedit, except that it's much easier to find things manipulate since you have the same interface to that file that you have to everything else. (For example, Linux maintains kernel options in much this same way, but it's *much* easier to just with an editable (commented) kernel config file; that's a big part of the reason I went back to FreeBSD. The lack of constraints on how one may interact with the rc.conf is one of its main weaknesses. A single missing quotation mark will result in an inaccessible system, if you don't have console access, and one that must be repaired, if you do. There's not even a virc equivalent to vipw, that can do a consistency check on the file to make sure it's sourceable by a shell script, before permitting the edits to replace the valid contents, and keep a backup of the previous file for you. I've never so messed myself up, but I can see where that would be a problem. *This* is a good idea, actually. Alternately, we can just call a spade a spade, and admit that what we have is a flat file registry, which pretends to be hierarchical by using _ as a hierachy delimiter for component seperation. I don't see that at all--the most distinctive characteristic to me of the Microsoft Windows Registry is that it tries to be a *single* place where *all* configuration information--both system and application--is written. If you ask Microsoft I'm pretty sure they'd tell you that's it's prime advantage and I claim that it's prime drawback. Either way, that's what most distinguishes it. Actually, this is a lot like the Manx subdirectory support in the shell program that came with the developement environment, and used topdir/subdir/finaldir as the name of the directory, and simply hid the names of all but the last component. 8-). Building this information into a directory hierarchy sounds clever but gives me nightmares in recalling the startup / daemon control in Linux (using the ATT scheme, I believe)--which sounds like a good idea in theory but I always found was an absolute nightmare in practice. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PPP Dial of External Modem Fails in 'Current'
I rebuilt 'Current' over the weekend with a make buildworld/install world and make buildkernel/install kernel and 'ppp -ddial papchap' gives the following error(s) when trying to dial an external modem: Warning set ifadr: Invalid command Warning set ifadr: Falied 1 Does anyone know what might be causing this ?? Sorry I'm a bit late in replying. The above command is ``set ifaddr'', not ``set ifadr'' :) Thanks, Glenn G. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
CD sysinstall broken (fix)
Sysinstall via the CD media (and probably other physical disc mediums) is
broken currently due to the devfs filesystem not being available at all
times in placesw here it is needed. I've changed the behavior in my
green_lomac branch to fix this, and would like if other people would verify
this indeed fixes the problem for them as well (I imagine it does) and does
what it should be expected to (which I also think it does).
Does this logic appear to be flawed in any cases? If all seems right, I
shall commit this to -CURRENT to unbreak CD installs.
//depot/user/green/lomac/usr.sbin/sysinstall/dist.c#2 (text+ko)
@@ -35,6 +35,8 @@
*/
#include sysinstall.h
+#include sys/param.h
+#include sys/mount.h
#include sys/time.h
#include signal.h
#include libutil.h
@@ -544,7 +546,7 @@
static Boolean
distExtract(char *parent, Distribution *me)
{
-int i,j, status, total, intr;
+int i,j, status, total, intr, unmounted_dev;
int cpid, zpid, fd2, chunk, numchunks;
char *path, *dist, buf[30];
const char *tmp;
@@ -684,6 +686,12 @@
total = 0;
(void)gettimeofday(start, (struct timezone *)0);
+ if (me[i].my_bit == DIST_BIN RunningAsInit !Fake) {
+ unmounted_dev = 1;
+ unmount(/dev, MNT_FORCE);
+ } else
+ unmounted_dev = 0;
+
/* We have one or more chunks, initialize unpackers... */
mediaExtractDistBegin(root_bias(me[i].my_dir), fd2, zpid, cpid);
@@ -810,6 +818,10 @@
*(me[i].my_mask) = ~(me[i].my_bit);
else
continue;
+ if (unmounted_dev) {
+ (void)mount(devfs, /dev, 0, NULL);
+ unmounted_dev = 0;
+ }
}
properties_free(dist_attr);
sigaction(SIGINT, old, NULL); /* Restore signal handler */
//depot/user/green/lomac/usr.sbin/sysinstall/install.c#2 (text+ko)
@@ -812,6 +812,8 @@
/* BOGON #1: Resurrect /dev after bin distribution screws it up */
dialog_clear_norefresh();
msgNotify(Remaking all devices.. Please wait!);
+ if (!Fake)
+ (void)unmount(/dev, MNT_FORCE);
if (vsystem(cd /dev; sh MAKEDEV all)) {
msgConfirm(MAKEDEV returned non-zero status);
return DITEM_FAILURE | DITEM_RESTORE;
@@ -1070,8 +1072,6 @@
command_sort();
command_execute();
-if (!mountfailed !Fake)
- unmount(/mnt/dev, MNT_FORCE);
dialog_clear_norefresh();
return DITEM_SUCCESS | DITEM_RESTORE;
}
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: CD-ROM installation of -CURRENT broken?
Bruce Evans [EMAIL PROTECTED] wrote: On Wed, 19 Dec 2001, Brian Fundakowski Feldman wrote: Does anyone know when installation of -CURRENT from CD-ROM got broken or a solution thereof? We end up having two problems: the fixit shell doesn't work, but before that an actual installation doesn't work because sysinstall's attempt to mount /dev/acd0c on /dist returns ENOENT. I havne't determined yet why this could be; anyone have clues? The 'c' partition of acd0 devices was broken for the non-DEVFS case in rev.104 of atapi-cd.c. (The errno for this is ENXIO.) DEVFS is not in GENERIC and make release doesn't seem to add it. Well, really, all we should care about is the devfs case since anything else is meant to be deprecated; I'd rather fix this at the source... DEVFS is no longer optional, so it is in GENERIC for certain. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
CD-ROM installation of -CURRENT broken?
Does anyone know when installation of -CURRENT from CD-ROM got broken or a solution thereof? We end up having two problems: the fixit shell doesn't work, but before that an actual installation doesn't work because sysinstall's attempt to mount /dev/acd0c on /dist returns ENOENT. I havne't determined yet why this could be; anyone have clues? -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current doesnt see ps2 port with acpi enabled on intel vc820
- Original Message - From: KT Sin [EMAIL PROTECTED] To: Jon Christopherson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 15, 2001 10:24 PM Subject: Re: current doesnt see ps2 port with acpi enabled on intel vc820 I have just compiled and installed -current from this morning 7AMPST, and have noticed that when acpi is enabled in loader.conf the OS does not see the ps2 mouse port. When I turn off ACPI the mouse port shows up fine. Other than not seeing the ps2 port when in ACPI enabled mode, the OS works without a hitch on my motherboard. Any ideas? IF this is a known problem please let me know, as I have been off this list for a month or so. I'm seeing the same problem on my MSI bookpc. For some reasons, the psm device will fail to get an IRQ when ACPI is enabled. Can you try the attached patch and see if it helps? Hey I had the same problem but I assumed it was because I was slightly overclocking an amd k6-2 500 to 550 on a cheap old e-machine via-based motherboard. I applied your patch and now my mouse works. thanks! blather although, partially in response to the mouse problem, I never use my kvm switch anymore anyways, just vnc on the rare occasion I feel like playing with x on this box. /blather Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/ +[+++[-]-]+..+.+++.-.[+---]++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ibcs
is anyone using ibcs on current ? Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/ +[+++[-]-]+..+.+++.-.[+---]++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
