7.2 serial console/getty problem
Howdy, I'm having some issues getting a working serial console on a 7.2-amd64 system (Dell PE 2970). Everything is running at 9600bps to keep things simple (BIOS, loader, getty). Normal DB-9 null cable to another host. /etc/ttys has getty on ttyd0 with the std.9600 gettytab entry and vt100 terminal type. The following works fine: -Console redirection via Dell's BIOS (I can enter setup, navigate BIOS, enter RAID config, etc.) -Boot loader (can enter boot params, select boot options, etc.) -Boot messages (displays fine) However once the machine boots and getty has control, things get a bit odd. I've tested this with various hosts using minicom and conserver (conserver.com). No problems with my other hosts running older versions of FreeBSD with the same settings (9600, 8N1, hw flow control). If I just hit enter, I get a response like this: n~:oommv64(jkoomimnnwwou})(|t}}t9- It does not vary - always the same string. However, if I hit CTRL-D, then I get a normal prompt: FreeBSD/amd64 (bigmail.bway.net) (ttyd0) login: If at the login: prompt I just hit enter again without typing a username, I get the same garbled output. CTRL-D again gives me a proper prompt. Once I'm logged-in, there seem to be no issues. vi, top and other things that rely on the terminal being sane work fine. Any ideas? Thanks, Charles ___ Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best Internet - www.bway.net sp...@bway.net - 212.655.9344 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-RELEASE completed...
On Thu, Nov 26, 2009 at 09:57:58PM -0800, Gary Kline wrote: Altho I am still some time from having my migration from the 1998 Kayak - 2009 Dell done and working, will it be possible to upgrade my 32bit 7.2-R, p4 to a 64bit 8.0? It is possible, but not easy. Upgrading from 7.x to 8.0 on the same architecture is not that hard IMHO. Upgrading from i386 to amd64 on the same release is doable but tricky; you need a spare root partition to install the amd64 binaries. Combining these two sounds like a big can of worms to me. My advice would be _not_ to do it. It would be far easier to just install 8.0 on the new machine and migrate your data and configuration files. You are going to have to build your ports from scratch anyway, because you're switching to another architecture and another major release. As far as I know, the on-disk filesystem format hasn't changed. (unless your old machine is still running UFS1. The default now is UFS2) There are a couple of differences between 7.x and 8.0; * The USB stack has been rewritten. I've had to change the following in /etc/devfs.rules: replace add path 'usb*' mode 0660 group usb with add path 'usb/*' mode 0660 group usb * The name of the tty devices has changed in /etc/ttys; ttydN - ttyuN (impacts /etc/ttys) * There have been a lot of changes in the kernel configuration. If you want a custom kernel, start anew from the 8.0 GENERIC kernel so you don't miss anything. * A lot of changes as well in /etc/src.conf (the file that defines which parts of the system are built from source) * Network cards show up in dmesg and ifconfig, but not as devices in /dev (but that could be a configuration error on my part.) All my configuration files are kept in a directory that is under revision control by git(1), so I could show you exactly what changes I've made. would get that clear as a first step. My Intell duo-core is very fast; would moving to the 64-bit system be a net gain or loss [in performance]. There is no clear gain or loss answer to that one. It depends on the workload you are running. On the plus size, amd64 has a lot more general registers available in the CPU than i386. On the other hand, the binaries are bigger. Since you're switching to another CPU, things like cache size will have a major inpact. WRT single versus multi cores, my impression has been that the individual cores in a multi-core intel CPU are somewhat slower that the core of a similarly clocked single-core CPU. (based on some informal testing I've done with povray). If your workloads are capable of running on multiple cores (e.g. make jobs, different programs running concurrently) there will be a significant speed increase. You only _need_ amd64 if you are running out of address space on the i386 architecture. Having said that, I've been running amd64 on my desktop since 5.3-RELEASE more or less because I can, and it has worked fine ever since. Be aware though that there are a few (most binary) ports that do not work on amd64. You can see that in the port Makefiles by looking for things like NOT_FOR_ARCHS and ONLY_FOR_ARCHS. HTH, Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpBcwHXv1PX9.pgp Description: PGP signature
Re: 7.2 serial console/getty problem
On Fri, Nov 27, 2009 at 02:45:39AM -0500, Charles Sprickman wrote: Howdy, I'm having some issues getting a working serial console on a 7.2-amd64 system (Dell PE 2970). Everything is running at 9600bps to keep things simple (BIOS, loader, getty). Normal DB-9 null cable to another host. /etc/ttys has getty on ttyd0 with the std.9600 gettytab entry and vt100 terminal type. The following works fine: -Console redirection via Dell's BIOS (I can enter setup, navigate BIOS, enter RAID config, etc.) -Boot loader (can enter boot params, select boot options, etc.) -Boot messages (displays fine) However once the machine boots and getty has control, things get a bit odd. I've tested this with various hosts using minicom and conserver (conserver.com). No problems with my other hosts running older versions of FreeBSD with the same settings (9600, 8N1, hw flow control). If I just hit enter, I get a response like this: n~:oommv64(jkoomimnnwwou})(|t}}t9- It does not vary - always the same string. However, if I hit CTRL-D, then I get a normal prompt: FreeBSD/amd64 (bigmail.bway.net) (ttyd0) login: If at the login: prompt I just hit enter again without typing a username, I get the same garbled output. CTRL-D again gives me a proper prompt. Once I'm logged-in, there seem to be no issues. vi, top and other things that rely on the terminal being sane work fine. Any ideas? The only idea I have is one which pertains to flow control, or lack there-of. Prior to logging in, flow control isn't used. Marcel Moolenaar told me about this when I complained that occasionally on serial console, prior to logging in, that characters could be lost, even when using hardware flow control (CTS/RTS). I initially thought the problem was induced by uart(4) (which I was trying out when I noticed the problem), but it happens on sio(4) as well. Example of what I'm referring to on a (RELENG_7 box; /etc/ttys uses std.115200; serial adapters are absolute 100% correct and wired for hardware CTS/RTS), where all I'm doing is hitting Enter: FreeBSD/amd64 (horus.sc1.parodius.com) (ttyd0) login: FreeBSD/amd64 (horus.sc1.parodius.com) (ttyd0) login: ) login: (horus.sc1.parodius.com) (ttyd0) login: FreeBSD/amd64 (horus.sc1.parodius.com) (ttyd0) login: ) login: (horus.sc1.parodius.com) (ttyd0) login: Note that the way the text messes up is consistent. Again, this only happens prior to logging in. And yes, if I press EOF[*], I get a proper OS string and prompt. Maybe somehow this is what you're experiencing but manifesting itself differently (visually)? I could be totally off base but it's the only thing I can think of. I haven't tried RELENG_8 on a box with serial console, so I can't say whether or not the new tty code in RELENG_8 somehow addresses this; Ed Schouten would have to comment on that. [*] -- Be aware that as of this writing, 8.0-RELEASE (and presently RELENG_8) does have a problem with printing the EOF character (^D) once logged in. Example: log in, run cat, hit ^D, and you'll actually see Caret-D printed (vs. on previous FreeBSD releases, where ^D wouldn't be shown). This is a bug in 8.x which Ed has since fixed, but the code hasn't been MFC'd yet (but will be soon): http://koitsu.wordpress.com/2009/10/12/testing-out-freebsd-8-0-rc1/ http://koitsu.wordpress.com/2009/11/02/testing-out-freebsd-8-0-rc2/ -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-RELEASE completed...
yep. have upgraded to 8.0-RELEASE on a number of servers and it is very boring. this is a feature. thanks all. randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
8.0: buildworld fails /usr/src/lib/libc/stdlib/Makefile.inc
I just csupped with tag=RELENG_8 but can't complete make buildworld. I'm starting from 7.1-PRERELEASE (roughly Nov 18, 2008) Any suggestions would be appreciated! -- stage 2.1: cleaning up the object tree -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION=FreeBSD 7.1-PRERELEASE i386 700112 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 /usr/obj/usr/src/make.i386/make -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp par-cleandir === share/info (cleandir) === lib (cleandir) === lib/csu/i386-elf (cleandir) rm -f crt1.o crti.o crtn.o gcrt1.o rm -f .depend GPATH GRTAGS GSYMS GTAGS === lib/libc (cleandir) /usr/src/lib/libc/stdlib/Makefile.inc, line 19: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 -- G. Paul Ziemba FreeBSD unix: 6:56AM up 1 day, 12:08, 4 users, load averages: 0.04, 0.02, 0.03 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
The press release (was: Re: 8.0-RELEASE completed...)
On Thu, 26 Nov 2009, Ken Smith wrote: Just a quick note in case there are people here who aren't subscribed to the freebsd-announce@ mailing list. We have completed the 8.0-RELEASE cycle. Details about the release are available from the main web site, in particular the announcement itself is available here: http://www.freebsd.org/releases/8.0R/announce.html Thanks for all the help with testing during the release process, as well as your continued support of FreeBSD. For those wanting to do advocacy work for the release, in addition to the release announcement and highly detail release notes, there's also a press release: http://www.freebsd.org/releases/8.0R/pressrelease.html It is a bit more verbose and salesy than the announcement, but a lot shorter than the release notes. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0: buildworld fails /usr/src/lib/libc/stdlib/Makefile.inc
On Fri, Nov 27, 2009 at 02:59:12PM +, G. Paul Ziemba wrote: I just csupped with tag=RELENG_8 but can't complete make buildworld. I'm starting from 7.1-PRERELEASE (roughly Nov 18, 2008) Any suggestions would be appreciated! Just thinking oud loud, but I have seen this kind of thing happen as well when I didn't make clean ; rm -rf /usr/obj before cvsup'ing to the next major release. I build a world and kernel today of RELENG_8 today without problems. Marco -- Success is having to worry about every damn thing in the world, except money. - Johnny Cash ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0: buildworld fails /usr/src/lib/libc/stdlib/Makefile.inc
ma...@tols.org (Marco van Tol) writes: On Fri, Nov 27, 2009 at 02:59:12PM +, G. Paul Ziemba wrote: I just csupped with tag=RELENG_8 but can't complete make buildworld. I'm starting from 7.1-PRERELEASE (roughly Nov 18, 2008) Any suggestions would be appreciated! Just thinking oud loud, but I have seen this kind of thing happen as well when I didn't make clean ; rm -rf /usr/obj before cvsup'ing to the next major release. Ah! That fixed it. Thanks! -- G. Paul Ziemba FreeBSD unix: 8:01AM up 1 day, 13:13, 4 users, load averages: 1.12, 0.95, 0.57 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
route(8) and show/sticky/... Re: 8.0-RELEASE completed...
Hi! Just a quick note in case there are people here who aren't subscribed to the freebsd-announce@ mailing list. We have completed the 8.0-RELEASE cycle. Details about the release are available from the main web site, in particular the announcement itself is available here: http://www.freebsd.org/releases/8.0R/announce.html Thanks! One question: http://www.freebsd.org/releases/8.0R/relnotes-detailed.html says: -- The route(8) utility now supports show, weights, and sticky commands. For more details, see the route(8) manual page. -- I do not have those things in my man page or route(8) command ? -- p...@opsec.eu+49 171 310137211 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-RELEASE completed...
Hi Ken, Ken Smith wrote: http://www.freebsd.org/releases/8.0R/announce.html Just a small typo on that page - not a big deal: The press release contains more information on this relese. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
PUC Serial I/O problem - copy of gnats-filed bug report (as discussed previously)
This is pretty serious folks - as noted below I have tried several options including limiting FIFO depth with the flags with no result. The PUC-based ports are basically useless under 8.x as a consequence. I can reproduce this lockup within 15-30 minutes every time. Submitter-Id: current-users Originator:Karl Denninger Organization: Karls Sushi and Packet Smashers Confidential: no FreeBSD PRs are public data Synopsis: Serial I/O is terminally screwed under 8.x. Severity: serious Priority: high Category: i386 Class: sw-bug Release: FreeBSD 8.0-STABLE i386 Environment: System: FreeBSD FS.denninger.net 8.0-STABLE FreeBSD 8.0-STABLE #3: Fri Nov 27 08 :32:51 CST 2009 k...@fs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP i386 puc0: Oxford Semiconductor OX16PCI954 UARTs port 0x4060-0x407f,0x4040-0x405f m em 0x94503000-0x94503fff,0x94502000-0x94502fff irq 16 at device 0.0 on pci3 puc0: [FILTER] uart2: 16550 or compatible on puc0 uart2: [FILTER] uart3: 16550 or compatible on puc0 uart3: [FILTER] uart4: 16550 or compatible on puc0 uart4: [FILTER] uart5: 16550 or compatible on puc0 uart5: [FILTER] p...@pci0:3:0:0:class=0x070006 card=0x1415 chip=0x950a1415 rev=0x00 hdr=0x00 bar [10] = type I/O Port, range 32, base 0x4060, size 32, enabled bar [14] = type Memory, range 32, base 0x94503000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0x4040, size 32, enabled bar [1c] = type Memory, range 32, base 0x94502000, size 4096, enabled cap 01[40] = powerspec 1 supports D0 D2 D3 current D0 # # SMP -- Generic kernel configuration file for FreeBSD/i386 SMP #Use this for multi-processor machines # # $FreeBSD: src/sys/i386/conf/SMP,v 1.5.6.1 2005/09/18 03:37:58 scottl Exp $ include GENERIC ident KSD-SMP # To make an SMP kernel, the next line is needed #optionsSMP # Symmetric MultiProcessor Kernel # # We also need the firewall, divert, and PPS_SYNC (for the GPS) options # options IPFIREWALL options IPDIVERT options PPS_SYNC # # Rate-shaping requirements # options DUMMYNET options HZ=1000 #optionsSYSVSHM # # Local stuff # device rp # Comtrol Rocketport Board device sound # Generic sound card drivers #device ubsa# USB Serial Adapters #device ucom #device uftdi #device uplcom device umct device puc Description: Serial I/O fails with a lockup after a variable amount of time. Modem-controlled ports are succeptible, especially those that require tight adherence to that capability. There is no reset possible without rebooting the machine. Attempts to probe the port by stopping the running process(es) and re-initializing them fail. This IDENTICAL board in the IDENTICAL machine was functioning properly under 7.x over the space of about a year under extremely heavy use. As soon as 8.x-RC2 was loaded, and subsequently with the released version (as seen above) it failed and has remained dead. The custom kernel with PPS_SYNC is present as one of the ports (on the motherboard) is used for a GPS clock under ntpd. This port is operating fine - it is relatively low-traffic, of course, containing only timecode. Another port used to talk to an APC UPS (again, low traffic) is also ok. All ports in use for Hylafax, however, lock up as described above. Attempting to limit FIFO depth with 0x100 or 0x200 flags on the ports has no effect. How-To-Repeat: Put a puc style board in the machine, set up hylafax, send a few dozen faxes. The driver will wedge. Fix: how to correct or work around the problem, if known (multiple lines) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PUC Serial I/O problem - copy of gnats-filed bug report (as discussed previously)
Karl Denninger wrote: This is pretty serious folks - as noted below I have tried several options including limiting FIFO depth with the flags with no result. The PUC-based ports are basically useless under 8.x as a consequence. I can reproduce this lockup within 15-30 minutes every time. Submitter-Id: current-users Originator:Karl Denninger Organization: Karls Sushi and Packet Smashers Confidential: no FreeBSD PRs are public data Synopsis: Serial I/O is terminally screwed under 8.x. Severity: serious Priority: high Category: i386 Class: sw-bug Release: FreeBSD 8.0-STABLE i386 Environment: System: FreeBSD FS.denninger.net 8.0-STABLE FreeBSD 8.0-STABLE #3: Fri Nov 27 08 :32:51 CST 2009 k...@fs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP i386 puc0: Oxford Semiconductor OX16PCI954 UARTs port 0x4060-0x407f,0x4040-0x405f m em 0x94503000-0x94503fff,0x94502000-0x94502fff irq 16 at device 0.0 on pci3 puc0: [FILTER] uart2: 16550 or compatible on puc0 uart2: [FILTER] uart3: 16550 or compatible on puc0 uart3: [FILTER] uart4: 16550 or compatible on puc0 uart4: [FILTER] uart5: 16550 or compatible on puc0 uart5: [FILTER] p...@pci0:3:0:0:class=0x070006 card=0x1415 chip=0x950a1415 rev=0x00 hdr=0x00 bar [10] = type I/O Port, range 32, base 0x4060, size 32, enabled bar [14] = type Memory, range 32, base 0x94503000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0x4040, size 32, enabled bar [1c] = type Memory, range 32, base 0x94502000, size 4096, enabled cap 01[40] = powerspec 1 supports D0 D2 D3 current D0 # # SMP -- Generic kernel configuration file for FreeBSD/i386 SMP #Use this for multi-processor machines # # $FreeBSD: src/sys/i386/conf/SMP,v 1.5.6.1 2005/09/18 03:37:58 scottl Exp $ include GENERIC ident KSD-SMP # To make an SMP kernel, the next line is needed #optionsSMP # Symmetric MultiProcessor Kernel # # We also need the firewall, divert, and PPS_SYNC (for the GPS) options # options IPFIREWALL options IPDIVERT options PPS_SYNC # # Rate-shaping requirements # options DUMMYNET options HZ=1000 #optionsSYSVSHM # # Local stuff # device rp # Comtrol Rocketport Board device sound # Generic sound card drivers #device ubsa# USB Serial Adapters #device ucom #device uftdi #device uplcom device umct device puc Description: Serial I/O fails with a lockup after a variable amount of time. Modem-controlled ports are succeptible, especially those that require tight adherence to that capability. There is no reset possible without rebooting the machine. Attempts to probe the port by stopping the running process(es) and re-initializing them fail. This IDENTICAL board in the IDENTICAL machine was functioning properly under 7.x over the space of about a year under extremely heavy use. As soon as 8.x-RC2 was loaded, and subsequently with the released version (as seen above) it failed and has remained dead. The custom kernel with PPS_SYNC is present as one of the ports (on the motherboard) is used for a GPS clock under ntpd. This port is operating fine - it is relatively low-traffic, of course, containing only timecode. Another port used to talk to an APC UPS (again, low traffic) is also ok. All ports in use for Hylafax, however, lock up as described above. Attempting to limit FIFO depth with 0x100 or 0x200 flags on the ports has no effect. How-To-Repeat: Put a puc style board in the machine, set up hylafax, send a few dozen faxes. The driver will wedge. Fix: how to correct or work around the problem, if known (multiple lines) For what its worth, USB-based serial adapters also fail in the same way, but faster (they have NEVER been reliable in this regard, and this hasn't improved) -- Karl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PUC Serial I/O problem - copy of gnats-filed bug report (as discussed previously)
On Fri, Nov 27, 2009 at 12:54:17PM -0600, Karl Denninger wrote: For what its worth, USB-based serial adapters also fail in the same way, but faster (they have NEVER been reliable in this regard, and this hasn't improved) There must be a regression of some kind, given that some FreeBSD developers have stated in the past that FTDI-based USB serial adapters work great: http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041615.html Original thread: http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041610.html -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PUC Serial I/O problem - copy of gnats-filed bug report (as discussed previously)
Jeremy Chadwick wrote: On Fri, Nov 27, 2009 at 12:54:17PM -0600, Karl Denninger wrote: For what its worth, USB-based serial adapters also fail in the same way, but faster (they have NEVER been reliable in this regard, and this hasn't improved) There must be a regression of some kind, given that some FreeBSD developers have stated in the past that FTDI-based USB serial adapters work great: http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041615.html Original thread: http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041610.html I don't know where works great has come from. Certainly not my experience in heavy use. For non-modem-control heavy use, it works ok. I use an 8-port fanout on 7.x to drive process control and it's stable. However, for heavy modem use (e.g. Hylafax) it has NEVER been stable - although in 8.x it won't even manage to send ONE 10-page fax most of the time, where under 7.x it would randomly fail in that use. Then again the puc() driver based serial I/O was completely stable under 7.x and now, with the new architecture it will get one or two jobs through it before it blows up. -- Karl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-RELEASE completed...
Roland Smith rsm...@xs4all.nl writes: It is possible, but not easy. Upgrading from 7.x to 8.0 on the same architecture is not that hard IMHO. Upgrading from i386 to amd64 on the same release is doable but tricky; you need a spare root partition to install the amd64 binaries. Not at all, just make a backup of /etc, extract the amd64 dist on top of your existing system, then restore whichever parts of /etc got clobbered. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
8.0 installworld fails in /usr/src/lib/csu/i386-elf cc: not found
I was just upgrading from 7.2 to 8.0 using RELENG_8 and everything went well until I did the installworld. Below is the error. -Troy -- Installing everything -- cd /usr/src; make -f Makefile.inc1 install === share/info (install) === lib (install) === lib/csu/i386-elf (install) cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c crt1.c cc: not found *** Error code 127 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Exit 1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0 installworld fails in /usr/src/lib/csu/i386-elf cc: not found
cc is installed and I can execute it. I don't have any unique cc variables being set in make.conf either. -Troy On Fri, Nov 27, 2009 at 02:33:38PM -0600, Troy wrote: I was just upgrading from 7.2 to 8.0 using RELENG_8 and everything went well until I did the installworld. Below is the error. -Troy -- Installing everything -- cd /usr/src; make -f Makefile.inc1 install === share/info (install) === lib (install) === lib/csu/i386-elf (install) cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c crt1.c cc: not found *** Error code 127 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Exit 1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
heap limits: mmap(2) vs. break(2) on i386
Hi, I am trying to figure out why java fails to start with 1024MB of heap on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are set to 2GB. Here is my limits: Resource limits (current): cputime infinity secs filesize infinity kB datasize 2097152 kB stacksize 65536 kB coredumpsize infinity kB memoryuseinfinity kB memorylocked infinity kB maxprocesses 5547 openfiles 2 sbsize infinity bytes vmemoryuse infinity kB Running ktrace I see: 9154 java CALL mmap(0,0x4400,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_NORESERVE|MAP_ANON,0x,0,0) 9154 java RET mmap -1 errno 12 Cannot allocate memory 9154 java CALL write(0x1,0xbf9fe378,0x2b) 9154 java GIO fd 1 wrote 43 bytes Error occurred during initialization of VM I made a small program that uses malloc(3) to allocate the same amount of memory, and that works nicely, ktrace reveals why: 10108 a.outCALL mmap(0,0x4400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0x,0,0) 10108 a.outRET mmap -1 errno 12 Cannot allocate memory 10108 a.outCALL break(0x4c10) 10108 a.outRET break 0 So the question is: why does mmap() fails while essentially the same sbrk() request succeeds? This is really bad since, while native FreeBSD programs can work around this by using malloc(3), Linux programs and software that knows nothing about intricate details of the FreeBSD VM (i.e. Java) will fail miserably. I tried increasing vm.max_proc_mmap to 2147483647 from default 49344, but it did not do any good. mmap() still fails with the request of this size. I have seen several threads on the issue over the years, but still no resolution. It seems that only plausible solution is to limit heap size in java, which may not work for all cases. Funny thing is that the first sentence of the sbrk(2) manual page says: The brk() and sbrk() functions are legacy interfaces from before the advent of modern virtual memory management. Yet, legacy interfaces seems to do much better job than modern virtual memory management interfaces! -Maxim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0 installworld fails in /usr/src/lib/csu/i386-elf cc: not found
On Fri, Nov 27, 2009 at 03:07:05PM -0600, Troy wrote: cc is installed and I can execute it. I don't have any unique cc variables being set in make.conf either. Shot in the dark: are you using the -j argument during make installworld (not buildworld)? If so, don't do that. Otherwise, try moving make.conf aside and see if things improve. One thing at a time... :-) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0-RELEASE completed...
On Fri, Nov 27, 2009 at 09:22:01PM +0100, Dag-Erling Sm?rgrav wrote: Roland Smith rsm...@xs4all.nl writes: It is possible, but not easy. Upgrading from 7.x to 8.0 on the same architecture is not that hard IMHO. Upgrading from i386 to amd64 on the same release is doable but tricky; you need a spare root partition to install the amd64 binaries. Not at all, just make a backup of /etc, extract the amd64 dist on top of your existing system, then restore whichever parts of /etc got clobbered. DES -- Dag-Erling Smørgrav - d...@des.no Thanks, gentlemen. Mostly, my post was just a pondering; wondering if it might be better to re-do stuff now, But then my new server still isn't finished and probably won't be until next week. So best to stick with what I'm familar with. gary -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org The 7.31a release of Jottings: http://jottings.thought.org/index.php ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
stable/8/UPDATING - no mention of 8.0 release
iH, Been updating my src via svn and following stable/8. Looking at the UPDATING file, it does not mention '8.0-RELEASE' Did it just not make it in there yet? http://svn.freebsd.org/viewvc/base/stable/8/UPDATING?view=markup vs. http://svn.freebsd.org/viewvc/base/release/8.0.0/UPDATING?view=markup It just confused me for awhile after I did a 'svn up' and did not see the release notes... [for the 7.X series, both stable/ and release/ mention the release in UPDATING] ]Peter[ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0 installworld fails in /usr/src/lib/csu/i386-elf cc: not found
Tried to move make.conf aside and it did not help. I am not using -j in the installworld command. Any other thoughts? I'm in a bind with my upgrade without being able to do 'make installworld' On 11/27/2009 3:42 PM, Jeremy Chadwick wrote: On Fri, Nov 27, 2009 at 03:07:05PM -0600, Troy wrote: cc is installed and I can execute it. I don't have any unique cc variables being set in make.conf either. Shot in the dark: are you using the -j argument during make installworld (not buildworld)? If so, don't do that. Otherwise, try moving make.conf aside and see if things improve. One thing at a time... :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
