Re: 5.0-RC1: X server crash
On Mon, Dec 16, 2002 at 03:54:27AM +0100, Harald Hanche-Olsen wrote: (This is the last of my current batch of 5.0-RC1 problems.) Yeah, I know, X server problems ought to be reported to the XFree maintainers. Is there any interest for details of it here? The synopsis: The X server crashes under 5.0-RC1 where it runs fine with the exact same configuration under 4.7-RELEASE. It says Fatal server error: Caught signal 10. Server aborting and then dmesg output says it dies with signal 6 and dumping core. But I can't find any core dump lying around anywhere. I'll forward XFree86.0.log and config files if anybody here wants them, but in the interest of keeping unwanted list traffic down, I'll lay low until anybody requests this data. I'll include this line though: (--) PCI:*(1:0:0) ATI Radeon Mobility M7 LW rev 0, Mem @ 0xe000/27, 0xfcff/16, I/O @ 0xc000/8 The machine is a Dell Inspiron 4150. I use the same machine under 5.0-CURRENT (RC etc.). I used to have hangs under X, but since I removed Load dri from /etc/X11/XF86Config, it is OK. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
busdma documentation
Hi all, is there any documentation on the FreeBSD-busdma stuff? FreeBSD seems differ substantially from NetBSD in this regard. As far as I understand FreeBSD uses an older version. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fatal: ssh_msg_send: write
hi, I not sure in recent commits, but I have same error after finishing each command which connects to my -CURRENT's sshd (mostly scp). My -CURRENT is about month old :-( On Sun, Dec 15, 2002 at 11:26:41PM -0600, Christopher Schulte wrote: At 08:31 PM 12/15/2002 -0800, David Yeske wrote: Anyone else having issues with sshd on current? Dec 15 23:23:24 stuff sshd[843]: fatal: ssh_msg_send: write Yup, on a userland I built today. I see a few sshd commits yesterday, relating to pam. Probably broke thereabouts... ? -- Christopher Schulte http://www.schulte.org/ Do not un-munge my @nospam.schulte.org email address. This address is valid. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Re[2]: 80386 out of GENERIC
At 4:45 PM -0800 2002/12/15, Avleen Vig wrote: How difficult would the following be to develop, in your opinion? A boot disk image (like the sets of images on the website tm) that will boot on 386's as well as more modern CPU's that can newfs and disklabel your drives, download the source, and let you compile from that point. How many uninterrupted days/weeks would you be willing to allow a make world to run? something to compile with - which can be downloaded with the source all precompile so the do work on all x86 CPU's. If you're compiling the code (as would be necessary, since 386-compatible code would not be included in any of the regular binaries), then there is no such thing as pre-compiled anything. Morever, the concept of compiling something is mutually exclusive to getting a pre-compiled copy of that same something. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Posix Semaphores in -CURRENT
Terry Lambert wrote:
Joe Kelsey wrote:
/* name must start with a '/' but not contain one. */
if (*name != '/' || len 2 || index(name + 1, '/') != NULL) {
free(ret, M_SEM);
return (EINVAL);
}
The comment makes it look like this code allows a 14-character named
semaphore which *must* start with a slash and cannot contain embedded
slashes. In other words, it does *not* conform to pathname semantics.
OK, this is a bug. The semantics don't conform to POSIX.
...
I rather imagine the correct thing to do is to root it in the FS,
and, without a leading '/', treat it as relative to the process
current directory.
Basically, this is not a two line fix... it's a lot of work, to
get a filesystem object to use.
I think that it *is* a two-line fix. Remove the maximum length (or
impose a maximum length of MAX_PATHNAMELEN), and simply remove the whole
'/' checking. Then, the private namespace correctly emulates posix
semantics, except for the rooted versus relative stuff, which would be
*really* hard to do in a private namespace and of questionable value anyway.
/Joe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: fatal: ssh_msg_send: write
On Mon, Dec 16, 2002 at 02:35:48PM +0200, Alexey Zelkin wrote: I not sure in recent commits, but I have same error after finishing each command which connects to my -CURRENT's sshd (mostly scp). My -CURRENT is about month old :-( On Sun, Dec 15, 2002 at 11:26:41PM -0600, Christopher Schulte wrote: At 08:31 PM 12/15/2002 -0800, David Yeske wrote: Anyone else having issues with sshd on current? Dec 15 23:23:24 stuff sshd[843]: fatal: ssh_msg_send: write Yup, on a userland I built today. I see a few sshd commits yesterday, relating to pam. Probably broke thereabouts... ? Here is a full log of fresh -current's /usr/sbin/sshd -d -d -d (I tried to login from 4.7-S to my -current box) Any idea? debug1: sshd version OpenSSH_3.5p1 FreeBSD-20021029 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from XXX.XXX.XX.2 port 4828 debug1: Client protocol version 2.0; client software version OpenSSH_3.4p1 FreeBSD-20020702 debug1: match: OpenSSH_3.4p1 FreeBSD-20020702 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.5p1 FreeBSD-20021029 debug3: privsep user:group 22:22 debug2: Network child is on pid 601 debug1: permanently_set_uid: 22/22 debug3: preauth child monitor started debug1: list_hostkey_types: ssh-dss debug1: SSH2_MSG_KEXINIT sent debug3: mm_request_receive entering debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED] debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED] debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: client-server aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: server-client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug3: mm_request_send entering: type 0 debug3: monitor_read: checking request 0 debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI debug3: mm_answer_moduli: got parameters: 1024 2048 8192 debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug3: mm_request_send entering: type 1 debug3: mm_choose_dh: remaining 0 debug2: monitor_read: 0 used once, disabling now debug3: mm_request_receive entering debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 118/256 debug1: bits set: 1629/3191 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1606/3191 debug3: mm_key_sign entering debug3: mm_request_send entering: type 4 debug3: monitor_read: checking request 4 debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: mm_answer_sign debug3: mm_request_receive_expect entering: type 5 debug3: mm_answer_sign: signature 0x80762c0(55) debug3: mm_request_receive entering debug3: mm_request_send entering: type 5 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug2: monitor_read: 4 used once, disabling now debug1: kex_derive_keys debug3: mm_request_receive entering debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug3: Trying to reverse map address XXX.XXX.XX.2. debug1: userauth-request for user XXX service ssh-connection method none debug1: attempt 0 failures 0
Re: busdma documentation
On Mon, Dec 16, 2002 at 01:12:33PM +0100, Harti Brandt wrote the words in effect of: Hi all, is there any documentation on the FreeBSD-busdma stuff? FreeBSD seems differ substantially from NetBSD in this regard. As far as I understand FreeBSD uses an older version. Hello Harti, I recentley started writing a bus_dma manual page, and also adding bits from the NetBSD manual page. You can view a copy which gets updated about every day or two: [1] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.txt [2] http://www.unixdaemons.com/~hiten/work/misc/bus_dma.9.patch Yes, FreeBSD does use an old version of bus_dma, but things are being ported as needed AFAIK. For example, it would be good to have the BUS_SPACE_DEBUG functionality ported to our bus_space/dma implementation -- I am working on this at the moment; and also the naming o some flags, like BUS_DMAMEM_NOSYNC, which is BUS_DMA_COHERENT on NetBSD. I was gonna compose a mail to Warner about this, but now its being asked on a list, I am letting it out. :) There is also stuff about bounce thresholds, and the nature of DMA transfers (i.e. BUS_DMA_READ/WRITE) which needs to be ported. Once step at a time, and hopefully I will have all this done. If I get enough time after this, I will be doing an article on bus_dma, but not sure yet. NOTE: The above copy is work in progress -- the man page conversion should be finished hopefully by end of this week. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Re[2]: 80386 out of GENERIC
On 14-Dec-2002 Alex wrote: Dear/Beste phk, Saturday, December 14, 2002, 10:14:20 PM, you wrote: In message [EMAIL PROTECTED], Alex writes: Dear/Beste Johnson, I read this on the advocacy list. Tuesday, November 19, 2002, 7:56:44 PM, you wrote: Support for the 80386 processor has been removed from the GENERIC kernel. The default FreeBSD kernel is now more optimized for modern CPUs. No longer do you have to settle for performance draining compatibility with hardware you haven't owned in a decade. I don't feel this is a good decision. (I still have a 486, act as a small server and a 286 witch is in storage) This basally means that any one who doesn't have the latest processor can't install FreeBSD. No it doesn't mean that. FreeBSD still runs on all 386 family CPUs, the only difference is that if you want to run it on a 80386 you need to enable an option in your kernel config file. It will out of the box run on 486 and anything later. It means that you can not install FreeBSD on a 386 unless you have a 486+ machine that can compile a new FreeBSD system and have a way to get that version to the 386. My assumption was for such case. Lets say a home user with a pentium II with Windows 98 and his old 386 as a FreeBSD server. 5.0 will be too slow to be useful on an 80386. Better off running 4.x or 2.2.x on a real 80386. Seriously. Also, if/when KSE fully matures the new thread library will need to use special instructions that are only present on the 486 and above (the same instructions (cmpxchg) that are the reason GENERIC doesn't include 80386 by default anymore). Emulating those instructions on a 80386 is expensive and requires kernel privilege, thus someone would have to add support to the kernel to trap the illegal instruction fault on a 80386 and then emulate the instruction. Thus, it's going to be _really_ slow on a 80386. FreeBSD 2.2.x and 4.x are stable and tested OS platforms and I think that for an 80386 they are a much better platform than 5.x or other future versions of FreeBSD will ever be. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
On 15-Dec-2002 Terry Lambert wrote: Alex wrote: It means that you can not install FreeBSD on a 386 unless you have a 486+ machine that can compile a new FreeBSD system and have a way to get that version to the 386. Yes, this is true. Several of us were annoyed by the change, which appeared at the time to have been done solely to handle the fact that the newly installed device /dev/random sucked too much CPU time to work on a 386. The /dev/random code has since improved to not suck so much CPU time, but the 386 code was not reenabled. The best answer out there is the majority has spoken, with the idea being that if you are deploying on 386 hardware, you are an embedded systems vendor, and are willing to live with the process effectively being a cross-compilation. This has nothing to do with /dev/random. Please stop with the constant FUDing Terry. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
On 15-Dec-2002 Nate Lawson wrote: On Sun, 15 Dec 2002, Erik Trulsson wrote: The only remotely good reason I have heard for removing support for 386 in the default configuration is that having it in would pessimize performance too much for more modern CPUs. How valid that reason is I cannot judge, but I guess it is possible. Could someone enlighten me as to why we don't leave 386 support in for the boot kernel so the floppies will at least boot? Note that performance shouldn't be an issue when installing. After you reboot after you install the kernel you just installed won't boot. Pretty pointless. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC1: No /dev/card0
On Mon, Dec 16, 2002 at 03:41:55AM +0100, Harald Hanche-Olsen wrote: Despite the following lines in dmesg... cbb0: TI1420 PCI-CardBus Bridge at device 1.0 on pci2 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 cbb1: TI1420 PCI-CardBus Bridge at device 1.1 on pci2 cardbus1: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 ...no /dev/card0 (or /dev/card1) appears, and so pccardc and pccardd fail. Shouldn't this be automatic, or did I miss something? NEWCARD doesn't use pccardd or pccardc. devd replaces the part of pccardd that isn't in the kernel. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg48843/pgp0.pgp Description: PGP signature
Re: ipfw userland breaks again.
On Sun, Dec 15, 2002 at 08:47:23PM +, Nik Clayton wrote: On Sun, Dec 15, 2002 at 11:08:01AM -0800, Matthew Dillon wrote: : ::This is complete BULLSHIT, Warner. : :Your attitude it totally unacceptible. Learn to play well with :others, or get the fuck out of the project. Really? You think I should learn to play well with others? You think it's appropriate to request that I spend a man week rewriting an API? You really do? You think it's appropriate to bring up a bogus security issue when its obvious that no security issue exists, abusing your power in that manner is playing well with others? This is Warner of core? I think it's more appropriate if you put options IPFIREWALL_DEFAULT_TO_ACCEPT on any boxes where you're running test code. That's much more acceptable than committing a kludge with a poor choice of name after minimal discussion when efforts would be better spent working on other rough edges in the run up to 5-release. There were times, even within RELENG_4 lifecycle, when IPFW ABI was broken, making it really hard to remotely upgrade IPFW boxes, as we're required to boot with the new kernel before doing an installworld. It once costed me about 12 hours of downtime of our Australian production box. This is from the -STABLE's UPDATING: 20010109: ipfw interface changed. Make sure that the userland and kernel match or you won't have the firewall rules you think you do. 19990620: IPFW uid/gid-based filtering support has been committed. This breaks binary compatibility with previous copies of ipfw(8). Any utilities using the ioctl()s of ipfw (especially ipfw(8)) need to be recompiled with the newest headers installed. 19980725: The ipfw interface to the kernel has changed. You will need to recompile ipfw programs for the new kernel. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg48844/pgp0.pgp Description: PGP signature
Re: ipfw userland breaks again.
On Sat, Dec 14, 2002 at 02:09:13PM -0800, Matthew Dillon wrote: : :On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote: : then, as usual, IPFW with the new kernel and : old world fails utterly and now the fragging machine can't access the : :Hear hear!! I am tempted to have /sbin/ipfw moved to src/sys. How about something like this (patch enclosed). If there are no objections I will commit it along with a documentation update, and maybe also add some RC code give the sysad a chance to ipfw unbreak if ipfw otherwise fails during the boot sequence. Matt, How this could be helpful in a remote upgrade scenario that has IPFW ABI incompatibility issues? One alternative approach would be to not compile IPFW into a kernel but rather have it loaded as a module. Then, you install new kernel, edit out ipfw_enable=YES for the time being, reboot with the new kernel, installworld, edit ipfw_enable=YES back in, reboot, and you're done. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg48845/pgp0.pgp Description: PGP signature
Re: su(1) problem on -current
On Sun, 15 Dec 2002, David Malone wrote: On Sun, Dec 15, 2002 at 08:00:55PM +, Gavin Atkinson wrote: Confirmed. in su.c it seems that pam_authenticate is returning PAM_AUTH_ERR, when it presumably should not be doing so. Try getting rid of the auth_as_self in /etc/pam.d/su for the pam_wheel module. This fixes it. Although I don't understand why this wasn't needed until recently. Is there any reason to have the default pam su config contain auth_as_self? It just seems to introduce yet another (and quite annoying) incompatibility between 4.x and 5.x without achieving anything obvious. Maybe we could get auth_as_self removed from pam_wheel in /etc/pam.d/su? Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
On Saturday 14 December 2002 08:53 pm, Terry Lambert wrote: The best answer out there is the majority has spoken, with the idea being that if you are deploying on 386 hardware, you are an embedded systems vendor, and are willing to live with the process effectively being a cross-compilation. Okay, here's a compromise solution for all those people still needing 386 support out of the box: make a 5.0-mini-386.iso image. p.s. I somehow suspect that embedded systems vendors aren't installing from the CDROM. David To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
Yes, and then make 5.0-useless-Tandy1000.iso for the other 8 guys that could use it. -Craig - Original Message - From: Johnson David [EMAIL PROTECTED] To: Terry Lambert [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, December 16, 2002 12:55 Subject: Re: 80386 out of GENERIC On Saturday 14 December 2002 08:53 pm, Terry Lambert wrote: The best answer out there is the majority has spoken, with the idea being that if you are deploying on 386 hardware, you are an embedded systems vendor, and are willing to live with the process effectively being a cross-compilation. Okay, here's a compromise solution for all those people still needing 386 support out of the box: make a 5.0-mini-386.iso image. p.s. I somehow suspect that embedded systems vendors aren't installing from the CDROM. David To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC1: X server crash
On Mon, Dec 16, 2002 at 10:08:55AM +0100, Marc Fonvieille wrote: I use the same machine under 5.0-CURRENT (RC etc.). I used to have hangs under X, but since I removed Load dri from /etc/X11/XF86Config, it is OK. Please, try to run the memtest program (it's in the ports tree): i had a SERIOUS problem of memory corruption with my laptop (PIII, Intel815E, ATI Radeon M6, etcetc) with STABLE when i loaded the agp module. I reported this problem to the drm maintainer but he was unable to solve it... =P Run the memtest for a bit, and then report the result, maybe there's a strange bug floating around, or maybe i'm just drunk... =) -- Paolo Italian FreeBSD User Group: http://www.gufi.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
On Mon, Dec 16, 2002 at 09:55:14AM -0800, Johnson David said: Okay, here's a compromise solution for all those people still needing 386 support out of the box: make a 5.0-mini-386.iso image. p.s. I somehow suspect that embedded systems vendors aren't installing from the CDROM. why is this an issue? 1) supporting every computer made since 1964 is NetBSD's job, not FreeBSD's. 2) I'm scared that 5.0 is going to be unpleasantly slow on my p2-366, let alone a 386. 3) if you feel compelled to run old hardware, why not shell out $30 for a 486 system? for $50 you can get a Pentium 166. :-) I'm really keen to see FreeBSD move *forward*. chris --- Chris Doherty chris [at] randomcamel.net I think, said Christopher Robin, that we ought to eat all our provisions now, so we won't have so much to carry. -- A. A. Milne --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
On Mon, 16 Dec 2002, Ruslan Ermilov wrote: On Sat, Dec 14, 2002 at 02:09:13PM -0800, Matthew Dillon wrote: : :On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote: : then, as usual, IPFW with the new kernel and : old world fails utterly and now the fragging machine can't access the : :Hear hear!! I am tempted to have /sbin/ipfw moved to src/sys. How about something like this (patch enclosed). If there are no objections I will commit it along with a documentation update, and maybe also add some RC code give the sysad a chance to ipfw unbreak if ipfw otherwise fails during the boot sequence. Matt, How this could be helpful in a remote upgrade scenario that has IPFW ABI incompatibility issues? One alternative approach would be to not compile IPFW into a kernel but rather have it loaded as a module. Then, you install new kernel, edit out ipfw_enable=YES for the time being, reboot with the new kernel, installworld, edit ipfw_enable=YES back in, reboot, and you're done. I think having ipfw as a module doesn't get you fwd or divert. (I may be wrong) Cheers, -- Ruslan ErmilovSysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ARLA 0.35.11 on FreeBSD 5.0-RC1
At 4:15 PM +0100 12/15/02, Petr Holub wrote: Hi, I tried to compile arla 0.35.11 on FreeBSD 5.0-RC1. First I got following error: checking for memcpy in kernel... yes checking if vnode_if.h needs to be built... configure: error: unable to find any vnode_if script So I have linked -su-2.05b# ln -s /sys/i386/compile/EVENSTAR/vnode_if.h /usr/include/vnode_if.h Then configre and make proceeds until it stops on error shown below my signature. Can anybody help? I believe arla needs to have some effort put into it to get it working on -current. I started looking into that about six to eight months ago, but ran into a streak of bad luck trying to do anything at all with -current, and eventually gave up. That wasn't arla's fault, I was just having a string of bad luck. Now that I'm having much better luck with -current, I haven't had the time to go back and look into arla. Also, since that time there has been a fair amount of progress with openafs support for freebsd, and for my own purposes that would be an easier sell to my managers anyway. [not that I have openafs working on -current either, but I do hope to get to that soon...] When I was looking into this, I was talking with Andrea Campi about some changes he had for arla on -current. He was also very busy at the time, but maybe he still has that around. (I'm in the middle of upgrading shuffling my hardware around, and I think I lost my copy of those arla changes in the process of that shuffling). -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : I suppose it would be a good idea to include an alternatvie i386 : kernel on the CD-ROM. There may be a space issue, of course. How : many people participating in this thread have an i386 with at least 12 : MB of memory and intended to try 5.0 on it? How many of those don't : have a machine to bootstrap off? 12MB? The last time I tried on a 16MB machine, it core dumped because it ran out of memory. I had to put 24MB in the machine before it would work (I couldn't try 20MB due to onhand SIMMs). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:How this could be helpful in a remote upgrade scenario that has :IPFW ABI incompatibility issues? : :One alternative approach would be to not compile IPFW into a :kernel but rather have it loaded as a module. Then, you :install new kernel, edit out ipfw_enable=3DYES for the time :being, reboot with the new kernel, installworld, edit :ipfw_enable=3DYES back in, reboot, and you're done. : : :Cheers, :--=20 :Ruslan Ermilov Sysadmin and DBA, Well, the basic problem is that you don't actually know when the IPFW API is going to break. I do incremental upgrades most of the time and IPFW breaks maybe once every 5 upgrades. So for a manual upgrade it can be a severe inconvenience to have to deal with the possibility every time you upgrade. For an automated upgrade one can always automate and 'ipfw unbreak' (or 'ipfw open' as John just suggested to me) is not needed. What this patch does is allow you to upgrade via a serial console normally, without having to pay particular attention to IPFW, and if the IPFW API happens to break you can then simply 'ipfw unbreak' to get access to the network and then fix whatever broke. The only viable alternative that I've heard so far on the lists, other then 'Matt should rewrite the API so it doesn't break' is to have the installkernel and installworld targets check for ipfw incompatibility and install the new ipfw. Of course, this doesn't help if you have to revert the kernel. I still prefer the failsafe my solution supplies. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
bpf lock order reversal
Just had this lock order reversal on a late-november kernel. Haven't seen it mentioned before. Dec 16 19:07:15 epsilon kernel: rl0: promiscuous mode enabled Dec 16 19:07:15 epsilon kernel: lock order reversal Dec 16 19:07:15 epsilon kernel: 1st 0xc0429cc0 bpf global lock (bpf global lock) @ /usr/src/sys/net/bpf.c:375 Dec 16 19:07:15 epsilon kernel: 2nd 0xc296b9c4 rl0 (network driver) @ /usr/src/sys/pci/if_rl.c:1753 Dec 16 19:07:15 epsilon kernel: rl0: promiscuous mode disabled Is there any way I can set my machine to drop to debugger on any lock order reversal _other_ than sound-related LOR's? I realise these reversals are not as useful without a traceback, but as I use thismachine for playing audio Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SMP kernel on 5.0-release ISO's?
On Mon, 16 Dec 2002 14:44:57 -0500 Garance A Drosihn [EMAIL PROTECTED] wrote: Hi, ISO's? Do people think that would be a useful item to include? Yes and no, let me explain. The first thing I do just after I install FreBSD on a box (given it has enough cpu power) is rebuild world and kernel after tweaking /etc/make.conf. So I set the appropriate CPUTYPE flags and rebuild everything. As long as there's enough spare space to include an extra SMP-enabled kernel, I'm all for it, but my wild guess is that most people running SMP systems either rebuild their kernel for SMP + custom settings and/or rebuild world after install. I was thinking of just having a /boot/kernel-smp directory, for people to load in if they want to try it. I just want it on the CD's, it doesn't need to be automatically installed. If there's free space on the first CD, I'd say go for it. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk Of course it runs NetBSD! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC1: X server crash
On Mon, Dec 16, 2002 at 07:07:01PM +0100, Paolo Pisati wrote: Please, try to run the memtest program (it's in the ports tree): i had a SERIOUS problem of memory corruption with my laptop (PIII, Intel815E, ATI Radeon M6, etcetc) with STABLE when i loaded the agp module. I reported this problem to the drm maintainer but he was unable to solve it... =P Run the memtest for a bit, and then report the result, maybe there's a strange bug floating around, or maybe i'm just drunk... =) We talked about a problem between X and -CURRENT, we had no problem with -STABLE. Btw I don't see how memtest can report memory corruption, I thought it was to test hardware problem. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: ffs_blkfree: freeing free block
Hi,
I got a panic today which occured during a background fsck, after a hard-reboot
of the system. The dump from gdb is attached and I can, of course, provide more
infos if needed.
-- Aurelien
Script started on Mon Dec 16 22:08:36 2002
[m[27m[Jnebula# [K[39C/usr/src/sys/i386/compile/NEBULA[71Dggdb -k
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd.
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /boot/kernel/kenre rnel
(kgdb) core-file /var/crash/vmcore.6
panic: from debugger
panic messages:
---
dev = ad0s1f, block = 1088, fs = /tmp
panic: ffs_blkfree: freeing free block
panic: from debugger
Uptime: 50s
Dumping 123 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc021c4de in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc021c723 in panic () at ../../../kern/kern_shutdown.c:517
#3 0xc013c232 in db_panic () at ../../../ddb/db_command.c:450
#4 0xc013c1b2 in db_command (last_cmdp=0xc03a0620, cmd_table=0x0,
aux_cmd_tablep=0xc039b14c, aux_cmd_tablep_end=0xc039b150)
at ../../../ddb/db_command.c:346
#5 0xc013c2c6 in db_command_loop () at ../../../ddb/db_command.c:472
#6 0xc013efba in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc0335c82 in kdb_trap (type=3, code=0, regs=0xc850da4c)
at ../../../i386/i386/db_interface.c:166
#8 0xc0346a3f in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1061658176, tf_esi = 256, tf_ebp
= -934225256, tf_isp = -934225288, tf_ebx = 0, tf_edx = 0, tf_ecx = -1069391136,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070375132, tf_cs = 8, tf_eflags =
646, tf_esp = -1069985075, tf_ss = -1070066800})
at ../../../i386/i386/trap.c:603
#9 0xc0337468 in calltrap () at {standard input}:98
#10 0xc021c70b in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:503
#11 0xc02d908a in ffs_blkfree (fs=0xc18f3000, devvp=0xc191dce4, bno=1088,
size=16384, inum=1088) at ../../../ufs/ffs/ffs_alloc.c:1771
#12 0xc02e85bf in indir_trunc (freeblks=0xc1b39100, dbn=4288, level=0, lbn=12,
countp=0xc850dc10) at ../../../ufs/ffs/ffs_softdep.c:2603
#13 0xc02e8065 in handle_workitem_freeblocks (freeblks=0xc1b39100, flags=0)
---Type return to continue, or q return to quit---
at ../../../ufs/ffs/ffs_softdep.c:2469
#14 0xc02e528a in process_worklist_item (matchmnt=0x0, flags=0)
at ../../../ufs/ffs/ffs_softdep.c:745
#15 0xc02e4fd0 in softdep_process_worklist (matchmnt=0x0)
at ../../../ufs/ffs/ffs_softdep.c:624
#16 0xc026fa0e in sched_sync () at ../../../kern/vfs_subr.c:1751
#17 0xc0208dc4 in fork_exit (callout=0xc026f720 sched_sync, arg=0x0,
frame=0x0) at ../../../kern/kern_fork.c:872
(kgdb) quit
msg48859/pgp0.pgp
Description: PGP signature
Re: 5.0-RC1 install: disklabel editor
Date: Mon, 16 Dec 2002 03:25:39 +0100 From: Harald Hanche-Olsen [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] For some reason, I can't find a way to create a swap partition using the disklabel editor - other than by using Auto Defaults - and then I can't see any way to adjust the size of the resulting swap partition. This never was a problem with 4.x as far as I can remember...? (After first discovering this, I figured maybe if I left the pre-existing b partition as none, the install scripts would be smart enough to use it as swap. No way. And after the scripts complained, and I had been back through the disklabel editor again, installation failed with Error mounting /mnt/dev/ad0s3f on /mnt/usr: No such file or directory while the other console said newfs:/mnt/dev/ad0s3f: No such file or directory After which it went ahead and installed anyway, only to fill up the root file system, of course. I don't see any response, but I don't think that this has changes since V4. (But I may be mis-remembering. In any case, in the disklabel screen down-arrow until you get to the partition you want to use as swap. Note the size and press 'D' to delete it. Then up-arrow to the entry at the top of the screen for the slice the swap will be created in. Press 'C', enter the value for the size of the swap space, press enter, and then select Swap. Bingo! You have swap. Also, if you want the partition initialized, don't forget to toggle the newfs tag with 'T'. (And, of course, make sure root is big enough for 5.0.) Fortunately it is not too hard to steal a bit of swap to make root larger. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 'I want to apologize'
Ha ha. -Matt Matthew Dillon [EMAIL PROTECTED] :From [EMAIL PROTECTED] Mon Dec 16 14:00:03 2002 :... :Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) : by hub.freebsd.org (Postfix) with ESMTP : id D49B837B401; Mon, 16 Dec 2002 13:59:20 -0800 (PST) :Received: from gator.darkhorse.com (mail.darkhorse.com [209.95.33.140]) : by mx1.FreeBSD.org (Postfix) with ESMTP : id 5C37943EDC; Mon, 16 Dec 2002 13:59:20 -0800 (PST) : (envelope-from [EMAIL PROTECTED]) :Received: from [207.236.15.9] (account [EMAIL PROTECTED]) : by gator.darkhorse.com (CommuniGate Pro WebUser 3.5.9) : with HTTP id 9513340; Mon, 16 Dec 2002 13:58:55 -0800 :From: Matt Dillon [EMAIL PROTECTED] :Subject: I want to apologize :To: [EMAIL PROTECTED] :Cc: [EMAIL PROTECTED] :X-Mailer: CommuniGate Pro Web Mailer v.3.5.9 :Date: Mon, 16 Dec 2002 13:58:55 -0800 :Message-ID: [EMAIL PROTECTED] :MIME-Version: 1.0 :Content-Type: text/plain; charset=ISO-8859-1; format=flowed :Content-Transfer-Encoding: 8bit :Sender: [EMAIL PROTECTED] :List-ID: freebsd-hackers.FreeBSD.ORG :List-Archive: http://docs.freebsd.org/mail/ (Web Archive) :List-Help: mailto:[EMAIL PROTECTED]?subject=help (List Instructions) :List-Subscribe: mailto:[EMAIL PROTECTED]?subject=subscribe%20freebsd-hackers :List-Unsubscribe: mailto:[EMAIL PROTECTED]?subject=unsubscribe%20freebsd-hackers :X-Loop: FreeBSD.ORG :Precedence: bulk : :Hey dudes, I want to apologize for being a total *asshole* :wrt the ipfw thingie. Sorry. I know my patch was shit :anyway, and that ipfw blows dead goats when compared to :ipf, but even with that in mind, I had to pull a deraadt, :sorry. I'm so sorry. I mean, I've had my commit bit taken :away many times already, and yet I'm stupid enough to keep :with the same attitude. Damn, : :Yours, : Matthew. :_ :For the best comics, toys, movies, and more, :please visit http://www.tfaw.com/?qt=wmf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC1: X server crash
On Mon, Dec 16, 2002 at 09:55:09PM +0100, Marc Fonvieille wrote: We talked about a problem between X and -CURRENT, we had no problem with -STABLE. A problem that MAYBE is still present even in CURRENT, don't you think? As i said, i don't have my laptop right now, so i couldn't test CURRENT on it ( but i'll do it ASAP ), and i was looking for someone else with the same problem... Btw I don't see how memtest can report memory corruption, I thought it was to test hardware problem. hardware problem? VERY strange, cause IF i load the agp module i got errors from memtest, system freezecrash, then if i disable the agp module, memtest reports 0 errors (even after hourshours of test), no crashfreeze, etcetc As you can it doesn't look like an hardware problem, i think it's a FreeBSD-related problem, probably toggled by the agp drm stuff more when i'll get my laptop back... -- Paolo Italian FreeBSD User Group: http://www.gufi.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC1: X server crash
On Mon, Dec 16, 2002 at 11:25:05PM +0100, Paolo Pisati wrote: On Mon, Dec 16, 2002 at 09:55:09PM +0100, Marc Fonvieille wrote: We talked about a problem between X and -CURRENT, we had no problem with -STABLE. A problem that MAYBE is still present even in CURRENT, don't you think? Once again, I was not talking about the same problem as yours. As i said, i don't have my laptop right now, so i couldn't test CURRENT on it ( but i'll do it ASAP ), and i was looking for someone else with the same problem... Btw I don't see how memtest can report memory corruption, I thought it was to test hardware problem. hardware problem? VERY strange, cause IF i load the agp module i got errors from memtest, system freezecrash, then if i disable the agp module, memtest reports 0 errors (even after hourshours of test), no crashfreeze, etcetc As you can it doesn't look like an hardware problem, i think it's a FreeBSD-related problem, probably toggled by the agp drm stuff You missed my point, memtest is a test for hardware. From memtest site: memtest is a utility for testing the memory subsystem in a computer to determine if it is faulty. It's to test if your ram is bad, not to see a software problem. The memtest crash may come from a totally different reason and could occur in other situation. In fact you should fill a PR with all infos about your problem. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
On Monday, 16 December 2002 at 12:02:10 -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: I suppose it would be a good idea to include an alternatvie i386 kernel on the CD-ROM. There may be a space issue, of course. How many people participating in this thread have an i386 with at least 12 MB of memory and intended to try 5.0 on it? How many of those don't have a machine to bootstrap off? 12MB? Last known safe value. The last time I tried on a 16MB machine, it core dumped because it ran out of memory. I had to put 24MB in the machine before it would work (I couldn't try 20MB due to onhand SIMMs). Ah, good info. OK, how many 24 MB 80386 machines have you (pl) ever seen? How many do you have? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC1: compat4x
On Mon, Dec 16, 2002 at 03:37:58AM +0100, Harald Hanche-Olsen wrote: Shouldn't libposix1e.so.2 have been part of the compat4x package? I came across at least one program that uses it. Send me a list of what needs to be added, and I can look into it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC1 install: disklabel editor
+ Kevin Oberman [EMAIL PROTECTED]: | In any case, in the disklabel screen down-arrow until you get to the | partition you want to use as swap. Note the size and press 'D' to | delete it. Then up-arrow to the entry at the top of the screen for the | slice the swap will be created in. Press 'C', enter the value for the | size of the swap space, press enter, and then select Swap. Bingo! | You have swap. This fits my memory too, but now after entering the size, I get directly to the question on naming the mount point. Before that, if I remember right, there used to be a question whether I wanted swap or a file system. That question no longer appears. - Harald To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
In message [EMAIL PROTECTED], Johnson David writes: On Saturday 14 December 2002 08:53 pm, Terry Lambert wrote: The best answer out there is the majority has spoken, with the idea being that if you are deploying on 386 hardware, you are an embedded systems vendor, and are willing to live with the process effectively being a cross-compilation. Okay, here's a compromise solution for all those people still needing 386 support out of the box: make a 5.0-mini-386.iso image. Sure, send us the necessary patches to do so and we'll look at it. Poul-Henning PS: If you are asking _us_ to spend _our_ time doing this: Forget it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC1: No /dev/card0
+ Brooks Davis [EMAIL PROTECTED]: | On Mon, Dec 16, 2002 at 03:41:55AM +0100, Harald Hanche-Olsen wrote: | ...no /dev/card0 (or /dev/card1) appears, and so pccardc and pccardd | fail. Shouldn't this be automatic, or did I miss something? | | NEWCARD doesn't use pccardd or pccardc. devd replaces the part of | pccardd that isn't in the kernel. Oh duh, that one passed me by. Whether it's unfinished documentation or I just didn't see it, I don't know. Anyway, without running any daemon (not even devd), I insert my memory cards (adapters holding CF and SM cards) and they just magically appear as /dev/ad4. Thanks! - Harald To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC1: X server crash
+ Marc Fonvieille [EMAIL PROTECTED]: | I use the same machine under 5.0-CURRENT (RC etc.). I used to have | hangs under X, but since I removed | | Load dri | | from /etc/X11/XF86Config, it is OK. Didn't make an iota of difference for me. + Paolo Pisati [EMAIL PROTECTED]: | Please, try to run the memtest program (it's in the ports tree): | i had a SERIOUS problem of memory corruption with | my laptop (PIII, Intel815E, ATI Radeon M6, etcetc) with STABLE | when i loaded the agp module. It reports no trouble. It only wants to do 32 MB, but no problem there at all. - Harald To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0 performance (was: 80386 out of GENERIC)
On Monday, 16 December 2002 at 10:09:48 -0800, Chris Doherty wrote: 2) I'm scared that 5.0 is going to be unpleasantly slow on my p2-366, let alone a 386. I'm running it diskless on a K6/233. I'm surprised how snappy it is. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
unrar doesn't work under current
Trying to extract a single or multi volume archive doesn't work. Same archive can be extracted fine with unrar under 4.7-STABLE. My -CURRENT from 10 day ago. Tryed to remove and rebuild unrar without luck. rar on -CURRENT also works. Any idea? -8-[ from 4.7-STABLE ]-8- # date sample # rar a sample.rar sample # ll sample* -rw-r--r-- 1 root staff 29 Dec 17 01:35 sample -rw-r--r-- 1 root staff 103 Dec 17 01:35 sample.rar # unrar t sample.rar UNRAR 3.10 beta 1 freeware Copyright (c) 1993-2002 Eugene Roshal Testing archive sample.rar Testing sampleOK All OK -8-[ from 5.0-CURRENT, same file ]-8- # uname -v FreeBSD 5.0-RC #47: Sun Dec 8 18:09:42 CET 2002 ... # unrar t sample.rar UNRAR 3.10 beta 1 freeware Copyright (c) 1993-2002 Eugene Roshal Cannot open sample.rar No files to extract # rar t sample.rar RAR 3.00Copyright (c) 1993-2002 Eugene Roshal14 May 2002 Shareware version Type RAR -? for help Testing archive sample.rar Testing sampleOK All OK -8- Also note that installing rar after unrar overwrite .../bin/unrar :( # cd /usr/ports/archivers grep ^bin/unrar *rar*/pkg-plist rar/pkg-plist:bin/unrar unrar/pkg-plist:bin/unrar TIA, Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC1 install: disklabel editor
Date: Tue, 17 Dec 2002 00:39:32 +0100 From: Harald Hanche-Olsen [EMAIL PROTECTED] + Kevin Oberman [EMAIL PROTECTED]: | In any case, in the disklabel screen down-arrow until you get to the | partition you want to use as swap. Note the size and press 'D' to | delete it. Then up-arrow to the entry at the top of the screen for the | slice the swap will be created in. Press 'C', enter the value for the | size of the swap space, press enter, and then select Swap. Bingo! | You have swap. This fits my memory too, but now after entering the size, I get directly to the question on naming the mount point. Before that, if I remember right, there used to be a question whether I wanted swap or a file system. That question no longer appears. Very odd. I am running RC1 and I did exactly what I recommended with no problem. Since I was using the existing space, I just did CEnter and the window offering the Swapfile option appeared. I just tried it again on my RC1 system and it worked as I described. ? R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 performance (was: 80386 out of GENERIC)
On 2002-12-17 10:57, Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: On Monday, 16 December 2002 at 10:09:48 -0800, Chris Doherty wrote: 2) I'm scared that 5.0 is going to be unpleasantly slow on my p2-366, let alone a 386. I'm running it diskless on a K6/233. I'm surprised how snappy it is. I still have the Pentium 133 with 64 MB or memory that I used to run 5.0-CURRENT until a few weeks ago. I haven't got any real numbers, but the general `feel' of the system was pretty good. Trying to build world kernel on a 386 though... now that's a very different story! :) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
writing to mbr under GEOM
What's the status of the issue where devices with open partitions can't have their boot sectors written to? I know phk@ was working on it a while back but it's something I'd like to see fixed soon, maybe before release? ~ 9:14PM % sudo fdisk -B ad0 fdisk: can't open device /dev/ad0 fdisk: cannot open disk /dev/ad0: Operation not permitted zsh: 13660 exit 1 sudo fdisk -B ad0 ~ 9:25PM % sudo fdisk -i ad0 fdisk: can't open device /dev/ad0 fdisk: cannot open disk /dev/ad0: Operation not permitted zsh: 13661 exit 1 sudo fdisk -i ad0 -- Ray Kohler [EMAIL PROTECTED] When you have an efficient government, you have a dictatorship. -- Harry Truman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Reboot failure and dmesg corruption
Hi everyone! I recently installed 5.0-CURRENT-20021215-JPSNAP from current.freebsd.org and two small problems have come to light. Firstly my box (a P2-350 Compaq Deskpro) refuses to reboot. When I issue a 'shutdown -r now' the system gets as far as displaying the system uptime and then seems to stop. The monitor goes into powersaving but the machine never reboots, and I need to hit the power button to get it to reboot. I tried disabling ACPI by adding hint.acpi.0.disabled=1 to /boot/device.hints but it made no difference. Secondly when I first installed -current onto this machine (DP1 I think) I had a strange problem where the system's dmesg becomes corrupted. This problem is still present and seems to be able to appear and dssappear. Here is an exerpt from dmesg where the corruption suddenly appeared : uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0x2020-0x203f irq 11 at device 20.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 20.3 (no driver attached) orm0: Option ROMs at ikmem 0xe-0xe7fff,0xc-0xc7fff on isa0 pmtimer0 on isa0 atkbdc0:Keyboard controller (i8042) !t port 0x64,0x60 onisa\^P atkbd08 AT Keyboard blags0x1 irq 1 on adjbdc0 kbd0 at atkbd0 fdc0: Enhanced floppy conTroller (I82077, FE72065 or alone `t port 0x3f7,0x2f0-0x3f4 )rq 6 drq 2 on isa0 fdb0: FIFO enabled, 8 b\^Xtes thR%shmld fd0: 144\^P-K@ 3.% dpive on fdc0 drive\^P Both of these problems have been reported to -current before but never with any resolution. As we near 5.0-REL, I thought I would check again if anyone has any ideas on what might be wrong. Many thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 performance (was: 80386 out of GENERIC)
Read the top of /usr/src/UPDATING Explains most of the slow problems. At 03:45 AM 12/17/2002 +0200, Giorgos Keramidas wrote: On 2002-12-17 10:57, Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: On Monday, 16 December 2002 at 10:09:48 -0800, Chris Doherty wrote: 2) I'm scared that 5.0 is going to be unpleasantly slow on my p2-366, let alone a 386. I'm running it diskless on a K6/233. I'm surprised how snappy it is. I still have the Pentium 133 with 64 MB or memory that I used to run 5.0-CURRENT until a few weeks ago. I haven't got any real numbers, but the general `feel' of the system was pretty good. Trying to build world kernel on a 386 though... now that's a very different story! :) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
In message: [EMAIL PROTECTED]
Matthew Dillon [EMAIL PROTECTED] writes:
: Here's a new patch. But there isn't much of a point if we do not
: also disallow ipfw DELETE and FLUSH. And the pipe config commands
: as well as anything else that changes the firewall state. Firewalls
: are there to protect the systems behind them. I think deleting the
: rule that, say, prevents spoofing is as bad as adding a rule that
: allows everything through :-(
This comment got me thinking. The thinking lead to a lot of looking
at code between compiles today, and more this evening. It would
appear that the test that was there was sufficient to deal with the
cases that I was worried about. Revisiting the change:
- if (sopt-sopt_name == IP_FW_ADD ||
+ if (sopt-sopt_name == IP_FW_ADD || sopt-sopt_name == IP_FW_UNBREAK ||
(sopt-sopt_dir == SOPT_SET sopt-sopt_name != IP_FW_RESETLOG)) {
Earlier, we only allow IP_FW_{ADD,UNBREAK,RESETLOG,FLUSH,DELETE} for
SOPT_SET requests and IP_FW_ADD (and a few others) for SOPT_GET
requests. Since GET + ADD is only case that isn't a SET that changes
things, the == SOPT_SET takes care of the case that you added.
For a while I thought one could do nasty things based on GET + FLUSH,
say, but in raw_ip.c, we do the proper checks before calling
ip_fw_ctl_ptr().
So it looks like this code is subtle enough to have fooled both of
us. This one change isn't needed for this patch.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic: ffs_blkfree: freeing free block
In the last episode (Dec 16), Aurelien Nephtali said: Hi, I got a panic today which occured during a background fsck, after a hard-reboot of the system. The dump from gdb is attached and I can, of course, provide more infos if needed. Me too. My info attached as well; almost identical stack trace. Kernel was built from sources cvsupped just after 2002/12/15 17:41:07 PST. (Why in the heck are all the timestamps in commitlogs in PST??) -- Dan Nelson [EMAIL PROTECTED] GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: page fault panic messages: --- panic: ffs_blkfree: freeing free block cpuid = 1; lapic.id = boot() called on cpu#1 Uptime: 1m24s pfs_vncache_unload(): 1 entries remaining Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = fault virtual address = 0x18 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02a70a4 stack pointer = 0x10:0xd4859ccc frame pointer = 0x10:0xd4859ce4 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 = 26 (irq11: dc0) trap number = 12 panic: page fault cpuid = 1; lapic.id = boot() called on cpu#1 Uptime: 1m25s Dumping 512 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at ../../../kern/kern_shutdown.c:232 232 dumping++; #0 doadump () at ../../../kern/kern_shutdown.c:232 #1 0xc020c806 in boot (howto=260) at ../../../kern/kern_shutdown.c:364 #2 0xc020ca49 in panic () at ../../../kern/kern_shutdown.c:517 #3 0xc02b3048 in ffs_blkfree (fs=0xc2d2b000, devvp=0xc2d52a8c, bno=1896, size=8192, inum=1896) at ../../../ufs/ffs/ffs_alloc.c:1771 #4 0xc02c0395 in indir_trunc (freeblks=0xc3009d00, dbn=3696, level=0, lbn=12, countp=0xd483bc40) at ../../../ufs/ffs/ffs_softdep.c:2603 #5 0xc02bff14 in handle_workitem_freeblocks (freeblks=0xc3009d00, flags=0) at ../../../ufs/ffs/ffs_softdep.c:2469 #6 0xc02bd829 in process_worklist_item (matchmnt=0x0, flags=0) at ../../../ufs/ffs/ffs_softdep.c:745 #7 0xc02bd5dc in softdep_process_worklist (matchmnt=0x0) at ../../../ufs/ffs/ffs_softdep.c:624 #8 0xc0250b97 in sched_sync () at ../../../kern/vfs_subr.c:1751 #9 0xc01fd5ac in fork_exit (callout=0xc025094c sched_sync, arg=0x0, frame=0xd483bd48) at ../../../kern/kern_fork.c:872
Re: 80386 out of GENERIC
I have a 486 running as a firewall. I honestly didn't even think about trying 5.0 on that thing, forget a 386. So you don't get upset when Windows XP requires a Pentium two million with a bejigabyte of RAM but you complain when 5.0 Won't run on a 386? Adam In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : I don't feel this is a good decision. (I still have a 486, act as a : small server and a 286 witch is in storage) This basally means that : any one who doesn't have the latest processor can't install FreeBSD. : : No it doesn't mean that. : : FreeBSD still runs on all 386 family CPUs, the only difference is that : if you want to run it on a 80386 you need to enable an option in : your kernel config file. : : It will out of the box run on 486 and anything later. One problem with most 386 boxes is that they have very little memory. sysinstall is a big, bloated pig dog these days that takes more RAM than most 386 boxes have. This is true also for many 486 boxes too. So even if 386 stuff were in the default kernel, you'd likely have other issues in making sysinstall work and have to do custom hacking... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Adam Migus Network Associates Laboratories (http://www.nailabs.com) TrustedBSD (http://www.trustedbsd.org) | The Power To Secure To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC1: X server crash
On Mon, Dec 16, 2002 at 09:55:09PM +0100, Marc Fonvieille wrote: On Mon, Dec 16, 2002 at 07:07:01PM +0100, Paolo Pisati wrote: Please, try to run the memtest program (it's in the ports tree): i had a SERIOUS problem of memory corruption with my laptop (PIII, Intel815E, ATI Radeon M6, etcetc) with STABLE when i loaded the agp module. I reported this problem to the drm maintainer but he was unable to solve it... =P Run the memtest for a bit, and then report the result, maybe there's a strange bug floating around, or maybe i'm just drunk... =) We talked about a problem between X and -CURRENT, we had no problem with -STABLE. Btw I don't see how memtest can report memory corruption, I thought it was to test hardware problem. It is. Memtest will not tell you squat about this (unless you have real memory faults .. ). -- Regards Cliff Sarginson The Netherlands [ This mail has been checked as virus-free ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Sysinstall [ was Re: 5.0-RC1 install: disklabel editor ]
On Tue, Dec 17, 2002 at 12:39:32AM +0100, Harald Hanche-Olsen wrote: + Kevin Oberman [EMAIL PROTECTED]: | In any case, in the disklabel screen down-arrow until you get to the | partition you want to use as swap. Note the size and press 'D' to | delete it. Then up-arrow to the entry at the top of the screen for the | slice the swap will be created in. Press 'C', enter the value for the | size of the swap space, press enter, and then select Swap. Bingo! | You have swap. This fits my memory too, but now after entering the size, I get directly to the question on naming the mount point. Before that, if I remember right, there used to be a question whether I wanted swap or a file system. That question no longer appears. Yes and yes. With a fresh install I noted you do not get the Q about swap/fs. I noted as well you get swap if you select auto. I noted as well that if the sysinstall happens to find a swap area from a previous area it shows it as such, but will not use it without delete/create. Sysinstall is busted in other areas as well. Select all no-longer puts ticks in the boxes, if you tick each seperately it asks you every time if you want to install the ports, after every tick, and once again at the end. When I tried to configure an X-Server, it took me to the X-Client menu...sysinstall if that is posible has become more than a PITA than it always has been. -- Regards Cliff Sarginson The Netherlands [ This mail has been checked as virus-free ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SCSI Bios complaints and Disk Slices
Hi, I installed a second SCSI disk on a system. For testing I installed Windows .. fine, I installed Linux .. fine. Then I installed FreeBSD...fine *but* the SCSI BIOS on bootup complains that the disk geometry is all cockeyed, and it looks that way from what it says. It warns any non-DOS O/S may have problems using it. Well I have had no problems, and fdisk makes no complaints. What has happened to upset the SCSI BIOS ? The thing it seems to hate is that it is getting 63 heads reported instead of 64. It is a Tekram 390 U/W controller, with an IBM 18MB U160 disk. There have never been any other complaints about the 1st SCSI disk. Diagnostics show no problems. -- Regards Cliff Sarginson The Netherlands [ This mail has been checked as virus-free ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 performance (was: 80386 out of GENERIC)
On Tue, Dec 17, 2002 at 03:45:22AM +0200, Giorgos Keramidas wrote: On 2002-12-17 10:57, Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: On Monday, 16 December 2002 at 10:09:48 -0800, Chris Doherty wrote: 2) I'm scared that 5.0 is going to be unpleasantly slow on my p2-366, let alone a 386. I'm running it diskless on a K6/233. I'm surprised how snappy it is. I still have the Pentium 133 with 64 MB or memory that I used to run 5.0-CURRENT until a few weeks ago. I haven't got any real numbers, but the general `feel' of the system was pretty good. Trying to build world kernel on a 386 though... now that's a very different story! :) Yup. But the slowness people are noting in general is explained in UPDATING, and is quite understandable at this point in 5.0's evolution. It certainly takes a *lot* longer than 4.7 (test machine 1GHZ Pentium III, 512MB memory, SCSI disk). Also didn't someone mention that GCC has got slower anyway ? -- Regards Cliff Sarginson The Netherlands [ This mail has been checked as virus-free ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: swapoff code comitted.
Thus spake Christian Brueffer [EMAIL PROTECTED]: How about renaming swapon(8) into swapctl(8) after this function enhancement? This name reflects it's purpose much better and would be consistent with the other BSDs. It would be trivial to change the name, although I don't see what it buys you. NetBSD changed the name because they wanted to be able to set swap device priority and do other things through the same interface. From previous conversations, I gather that swap device priority is not a particularly desired feature for FreeBSD, and it would probably require rewriting the entire swap subsystem again in any case. Unless you intend to extend the interface further, having swapctl seems to me like changing mount/umount to mountctl. That's not to say I'm opposed to the idea, just that I don't care one way or the other. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lock order reversals in sys_pipe.c and kern_sig.c
[2002-12-04 15:12] Alfred Perlstein said: | * Lars Eggert [EMAIL PROTECTED] [021204 15:04] wrote: | | FYI, just got a similar one yesterday on an up-to-date -current: | | lock order reversal | 1st 0xc784d700 pipe mutex (pipe mutex) @ /usr/src/sys/kern/sys_pipe.c:465 | 2nd 0xc0513840 sigio lock (sigio lock) @ /usr/src/sys/kern/kern_sig.c:2225 | | Since no one has given me the traceback based on the patch I posted | earlier I have ceased to care about the problem. If someone | seriously cares they will run with my patch and post a backtrace. Running java _always_ causes one lock order warning -- and only one, AFAICT, after having the system up for a few days; successive execs of the java binary do not cause the warning. thanks brent brent@scratch$ uname -a FreeBSD scratch.rcfile.org 5.0-CURRENT FreeBSD 5.0-CURRENT #15: Mon Dec 16 23:22:55 EST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SCRATCH i386 brent@scratch$ javavm -version lock order reversal 1st 0xc504b280 pipe mutex (pipe mutex) @ /usr/src/sys/kern/sys_pipe.c:465 2nd 0xc051d660 sigio lock (sigio lock) @ /usr/src/sys/kern/kern_sig.c:2225 Debugger(witness_lock) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db trace Debugger(c0494b35,c051d660,c04cb89d,c04cb89d,c04ce124) at Debugger+0x54 witness_lock(c051d660,8,c04ce124,8b1,c504b280) at witness_lock+0x667 _mtx_lock_flags(c051d660,0,c04ce124,8b1,c4f29d10) at _mtx_lock_flags+0xb1 pgsigio(c4f29da8,17,0,1ad,c0598898) at pgsigio+0x30 pipe_read(c4f21690,e0297c7c,c52a7200,0,c4de0c40) at pipe_read+0x596 dofileread(c4de0c40,c4f21690,3,bfbff0a7,1) at dofileread+0xd2 read(c4de0c40,e0297d10,c04e77be,407,3) at read+0x6b syscall(2f,2f,2f,281d9c02,bfbff0c0) at syscall+0x28e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (3, FreeBSD ELF32, read), eip = 0x280c6993, esp = 0xbfbff08c, ebp = 0xbfbff0e8 --- db continue java version 1.3.1-p7 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-p7-root-021107-04:35) Classic VM (build 1.3.1-p7-root-021107-04:35, green threads, nojit) brent@scratch$ -- Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing. -- Duane Allman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ia64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Mon Dec 16 22:07:52 PST 2002 -- === xe /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/ia64/src/sys/geom/geom_gpt.c: In function `g_gpt_taste': /home/tinderbox/ia64/src/sys/geom/geom_gpt.c:165: warning: assignment from incompatible pointer type *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
12MB? The last time I tried on a 16MB machine, it core dumped because it ran out of memory. I had to put 24MB in the machine before it would work (I couldn't try 20MB due to onhand SIMMs). Uhh, I think we should move forward, like everyone else says. I mean, I don't throw computers away, but all my 486's have died now, RIP... Having said that, to the best of my knowledge, there's still a scavenged P-90 with two 3Com NIC's bridging two LANs and acting as an internal router between them after two companies (one of which I used to work at) merged 5 years ago, and they wanted to access the private Frame Relay from their own LAN. It's running FreeBSD 2.2.x on an 80MB HDD with no swap (it was a *very* tight squeeze), and got upgraded to 5MB of RAM (it was installed with 4MB) after the guy running it decided to enable NIS and found it wouldn't work without a little more memory... Heh. I guess that's progress for ya. :) Cheers, AS msg48889/pgp0.pgp Description: PGP signature
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Mon Dec 16 21:39:05 PST 2002 -- Kernel build for GENERIC completed on Mon Dec 16 22:30:35 PST 2002 -- Kernel build for LINT started on Mon Dec 16 22:30:36 PST 2002 -- === vesa Makefile, line 5401: warning: duplicate script for target geom_bsd.o ignored Makefile, line 5404: warning: duplicate script for target geom_mbr.o ignored /local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:131: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbexec.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbhistry.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbinput.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbstats.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbxface.c:127: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/hwgpe.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfname.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfobj.c:126: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/rsdump.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utclib.c:129: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utdebug.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieattach': /local0/scratch/des/src/sys/dev/ie/if_ie.c:778: warning: assignment discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieget': /local0/scratch/des/src/sys/dev/ie/if_ie.c:1147: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type
Re: 5.0 performance (was: 80386 out of GENERIC)
At 5:58 AM +0100 12/17/02, Cliff Sarginson wrote: Also didn't someone mention that GCC has got slower anyway ? gcc is slower at compiling things. This is very noticeable when you're doing a buildworld. The code which gcc 3.2.1 produces does not seem any slower than the code produced by gcc 2.95.4 (the version in freebsd-stable). -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 performance (was: 80386 out of GENERIC)
On Tuesday 17 December 2002 12:19 am, Garance A Drosihn wrote: At 5:58 AM +0100 12/17/02, Cliff Sarginson wrote: Also didn't someone mention that GCC has got slower anyway ? gcc is slower at compiling things. This is very noticeable when you're doing a buildworld. The code which gcc 3.2.1 produces does not seem any slower than the code produced by gcc 2.95.4 (the version in freebsd-stable). Actually, in my benchmarks here, the same code tends to yield much faster executables under gcc3, particularly in C++. But these are limited benchmarks (primarily of KDE and my own applications). I'm willing to trade some time on the compile (which, with any luck, happens only once) in exchange for speed in the application (which I may use every day)! :-) -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unrar doesn't work under current
On Tue, Dec 17, 2002 at 01:44:44AM +0100, Riccardo Torrini wrote: Trying to extract a single or multi volume archive doesn't work. Same archive can be extracted fine with unrar under 4.7-STABLE. My -CURRENT from 10 day ago. Tryed to remove and rebuild unrar without luck. rar on -CURRENT also works. Any idea? [...] # uname -v FreeBSD 5.0-RC #47: Sun Dec 8 18:09:42 CET 2002 ... # unrar t sample.rar UNRAR 3.10 beta 1 freeware Copyright (c) 1993-2002 Eugene Roshal Cannot open sample.rar No files to extract [...] I tried to reproduce this but could not with these two versions of unrar: UNRAR 3.00 freeware (from source) UNRAR 3.10 beta 1 freeware (from ports) The output of ktrace/kdump or truss would be useful in investigating this. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
On Mon, Dec 16, 2002 at 09:05:40AM +1030, Greg 'groggy' Lehey wrote: On Saturday, 14 December 2002 at 20:53:05 -0800, Terry Lambert wrote: Alex wrote: It means that you can not install FreeBSD on a 386 unless you have a 486+ machine that can compile a new FreeBSD system and have a way to get that version to the 386. Yes, this is true. Several of us were annoyed by the change, which appeared at the time to have been done solely to handle the fact that the newly installed device /dev/random sucked too much CPU time to work on a 386. That's an interesting apparition. In fact, it was done because the locking primitives for i386 are so different from those for later machines that they would significantly slow down all i[3]86 kernels. Since that's the vast majority, it doesn't make sense. I suppose it would be a good idea to include an alternatvie i386 kernel on the CD-ROM. There may be a space issue, of course. How many people participating in this thread have an i386 with at least 12 MB of memory and intended to try 5.0 on it? How many of those don't have a machine to bootstrap off? Having only alternative i386 kernel is not enough while userland stuff is still compiled for i486. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg48894/pgp0.pgp Description: PGP signature
Re: unrar doesn't work under current
On Tue, Dec 17, 2002 at 06:33:04PM +1100, Tim Robbins wrote:
On Tue, Dec 17, 2002 at 01:44:44AM +0100, Riccardo Torrini wrote:
Trying to extract a single or multi volume archive doesn't work.
Same archive can be extracted fine with unrar under 4.7-STABLE.
My -CURRENT from 10 day ago. Tryed to remove and rebuild unrar
without luck. rar on -CURRENT also works. Any idea?
[...]
# uname -v
FreeBSD 5.0-RC #47: Sun Dec 8 18:09:42 CET 2002 ...
# unrar t sample.rar
UNRAR 3.10 beta 1 freeware Copyright (c) 1993-2002 Eugene Roshal
Cannot open sample.rar
No files to extract
[...]
I tried to reproduce this but could not with these two versions of unrar:
UNRAR 3.00 freeware (from source)
UNRAR 3.10 beta 1 freeware (from ports)
The output of ktrace/kdump or truss would be useful in investigating this.
It fails on ref5:
[~/ports/archivers/unrar] edwin@ref5work/unrar/unrar t ../rar/sample.rar
UNRAR 3.10 beta 1 freeware Copyright (c) 1993-2002 Eugene Roshal
Cannot open ../rar/sample.rar
No files to extract
[~/ports/archivers/unrar] edwin@ref5
Think it has something to do with this one:
46353 unrarCALL open(0xbfbf98e3,0,0xbef6d8)
46353 unrarNAMI ../rar/sample.rar
46353 unrarRET open 3
46353 unrarCALL flock(0x3,0x6)
46353 unrarNAMI /var/run/lock
46353 unrarRET flock -1 errno 45 Operation not supported
46353 unrarCALL close(0x3)
46353 unrarNAMI /var/run/lock
46353 unrarRET close 0
46353 unrarCALL write(0x2,0xbfbed670,0x1e)
46353 unrarGIO fd 2 wrote 30 bytes
Cannot open ../rar/sample.rar
That's in file.cpp:73, LOCK_EX is in /usr/include/fcntl.h
Haven't looked at the rest.
Edwin
--
Edwin Groothuis |Personal website: http://www.MavEtJu.org
[EMAIL PROTECTED]|Weblog: http://www.mavetju.org/weblog/weblog.php
bash$ :(){ :|:};: | Interested in MUDs? http://www.FatalDimensions.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
