Fwd: Problem with modern Postfix on 4.7
Begin forwarded message: From: Scott Harrison [EMAIL PROTECTED] Date: May 23, 2006 4:31:46 GMT+02:00 To: freebsd-stable@freebsd.org Subject: Problem with modern Postfix on 4.7 Hello, I am not sure if this is the proper place to ask. Please redirect as necessary. I have a FreeBSD 4.7 box that I have updated the ports files. I have tried to recompile Postfix with SASL2 and TLS and now my smtpd is crashing with a SIGBUS when a TLS connection comes in. Prior to upgrading the ports files all was working properly. I recompiled the projects that Postfix needed and the binary seems to be ok: mobius# ldd /usr/local/libexec/postfix/smtpd /usr/local/libexec/postfix/smtpd: libsasl2.so.2 = /usr/local/lib/libsasl2.so.2 (0x280a) libpam.so.1 = /usr/lib/libpam.so.1 (0x280b5000) libcrypt.so.2 = /usr/lib/libcrypt.so.2 (0x280bf000) libssl.so.4 = /usr/local/lib/libssl.so.4 (0x280d8000) libcrypto.so.4 = /usr/local/lib/libcrypto.so.4 (0x28112000) libpcre.so.0 = /usr/local/lib/libpcre.so.0 (0x28228000) libc.so.4 = /usr/lib/libc.so.4 (0x2823e000) mobius# ls -l /usr/local/lib/libsasl2.so.2 /usr/lib/libpam.so.1 / usr/lib/libcrypt.so.2 /usr/local/lib/libssl.so.4 /usr/local/lib/ libcrypto.so.4 /usr/local/lib/libpcre.so.0 /usr/lib/libc.so.4 -r--r--r-- 1 root wheel 574916 Oct 9 2002 /usr/lib/libc.so.4 -r--r--r-- 1 root wheel28432 Oct 9 2002 /usr/lib/libcrypt.so.2 -r--r--r-- 1 root wheel38396 Oct 9 2002 /usr/lib/libpam.so.1 -r--r--r-- 1 root wheel 1339626 May 22 19:53 /usr/local/lib/ libcrypto.so.4 -rwxr-xr-x 1 root wheel87652 May 22 20:41 /usr/local/lib/ libpcre.so.0 -rwxr-xr-x 1 root wheel91881 May 22 20:15 /usr/local/lib/ libsasl2.so.2 -r--r--r-- 1 root wheel 264102 May 22 19:53 /usr/local/lib/ libssl.so.4 mobius# Is there some issue with updating the ports files? Any other suggestions? TIA, It turns out that the openssl port is not building properly, getting lots of lines like this: libssl.a(ssl_asn1.o): In function `d2i_SSL_SESSION': ssl_asn1.o(.text+0x9f9): undefined reference to `memcpy' ssl_asn1.o(.text+0xa78): undefined reference to `memcpy' ssl_asn1.o(.text+0xb40): undefined reference to `memcpy' ssl_asn1.o(.text+0xcda): undefined reference to `time' ssl_asn1.o(.text+0x1140): undefined reference to `memcpy' libssl.a(bio_ssl.o): In function `ssl_read': bio_ssl.o(.text+0x201): undefined reference to `time' libssl.a(bio_ssl.o): In function `ssl_write': bio_ssl.o(.text+0x361): undefined reference to `time' libssl.a(bio_ssl.o): In function `ssl_ctrl': bio_ssl.o(.text+0x6d6): undefined reference to `time' And running make test results in a problem: starting big number library test, could take a while... test BN_add test BN_sub test BN_lshift1 test BN_lshift (fixed) test BN_lshift test BN_rshift1 test BN_rshift test BN_sqr Bus error (core dumped) *** Error code 138 Stop in /usr/ports/security/openssl/work/openssl-0.9.8a/test. *** Error code 1 Stop in /usr/ports/security/openssl/work/openssl-0.9.8a. *** Error code 1 Stop in /usr/ports/security/openssl. There was a suggestion on the web indicating that binutils is the problem and that that should be updated. However, I do not know the proper way to go about updating binutils. Can someone please tell me how to do it or point me to a resource that does? TIA, -- ·ѕђѪё ·ѣѺѦѕѩѯ Scott Harrison ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trouble with NFSd under 6.1-Stable, any ideas?
On Mon, May 22, 2006 at 05:43:32PM -0400, Rong-en Fan wrote:
On 5/14/06, Kris Kennaway [EMAIL PROTECTED] wrote:
On Sun, May 14, 2006 at 02:28:55PM -0400, Howard Leadmon wrote:
Hello All,
I have been running FBSD a long while, and actually running since the
5.x
releases on the server I am having troubles with. I basically have a
small
network and just use NIS/NFS to link my various FBSD and Solaris machines
together.
This has all been running fine up till a few days ago, when all of a
sudden
NFS came to a crawl, and CPU usage so high the box appears to freeze
almost.
When I had 6.1-RC running all seemed well, then came the announcement
for the
official 6.1 release, so I did the cvs updates, made world, kernel, and
ran
mergemaster to get everything up to the 6.1 stable version.
Now after doing this, something is wrong with NFS. It works, it will
return
information and open files, just it's very very slow, and while
performing a
request the CPU spike is astounding. A simple du of my home directory
can
take minutes, and machine all but locks up if the request is done over
NFS.
Here is top snip:
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU
COMMAND
497 root 1 40 1252K 780K - 2 50:42 188.48% nfsd
This is a nice IBM eServer with dual P4-XEON's and a couple GB or RAM
on a
disk array, and locally is screams, heck NFS used to scream till I
updated. I
am not really sure what info would be useful in debugging, so won't post
tons
of misc junk in this eMail, but if anyone has any ideas as to how best to
figure out and resolve this issue it would sure be appreicated...
Use tcpdump and related tools to find out what traffic is being sent.
Also verify that you did not change your system configuration in any
way: there have been no changes to NFS since the release, so it is
unclear why an update would cause the problem to suddenly occur.
Kris
Hi Kris and Howard,
As I posted few days ago, I have similar problems like Howard's
(some details in the thread 6.1-RELEASE, em0 high interrupt rate
and nfsd eats lots of cpu on stable@). After binary searching
the source tree, I found that
RELENG_6_1, 2006.04.30.03.57 ok
RELENG_6_1, 2006.04.30.04.00 bad
The only commit is kern/vfs_lookup.c, an MFC of rev 1.90 and 1.91.
With 04.30 03.57's source + manaully patched vfs_lookup.c rev 1.90,
the same problem occurs.
Let me refresh what problems I'm seeing
1. a client (no matter Linux 2.6.16 or FreeBSD 6.1) runs du on
a nfs directory
2. on server-side, nfsd starts to eats lots of CPU
3. the du finishes
4. on server-side, nfsd still eats lots of CPU, but there is no
nfs traffic. Wait for 5 minutes, you can still see that nfsd is
running and eats lots of CPU.
On FreeBSD 6.1R client, it uses UDP mount and fstab is like
rw,-L,nosuid,bg,nodev. On Linux cleint, it uses UDP mount and
fstab is like defaults,udp,hard,intr,nfsvers=3,rsize=8192,wsize=8192.
The server's kernel conf is at
http://www.rafan.org/FreeBSD/nfs/KERNEL
Some related configuration files:
/etc/export
/export/dir1 host1 host2...
/export/dir2 host1 host2...
/etc/rc.conf
nfs_server_enable=YES
nfs_server_flags=-u -t -n 16
mountd_enable=YES
mountd_flags=-r -l -n
rpc_lockd_enable=YES
rpc_statd_enable=YES
rpcbind_enable=YES
/etc/fstab:
/dev/... /export/dir1 ufs rw,nosuid,noexec 2 2
/dev/... /export/dir2 ufs rw,nosuid,noexec,userquota 2 2
The NFS server is also using amd to mount some backup directories
from another NFS server. the amd.conf is
[global]
browsable_dirs = yes
map_type = file
mount_type = nfs
auto_dir = /nfs
fully_qualified_hosts = no
log_file = syslog
nfs_proto = udp
nfs_allow_insecure_port = no
nfs_vers = 3
# plock = yes
selectors_on_default = yes
restart_mounts = yes
[/backup]
map_options = type:=direct
map_name = /etc/amd.direct
/etc/amd.direct:
/defaults
opts:=rw,grpid,resvport,vers=3,proto=udp,nosuid,nodev,rsize=8192,wsize=8192
backup type:=nfs;rhost:=nfs2;rfs:=/nfs2/${host}
If there are any thing I can provide to help tracking this down. Please
let me know. By the way, I tried with truss/kdump to see what happens
when nfsd eats lot of CPUs, but in vain. They do not return anything.
I tried your recipe on 7-CURRENT with locally exported fs, remounted
over nfs. I did not get the behaviour your described.
Could you, please, provide the backtrace for the nfsd that
eats the CPU (from the ddb). I think it would be helpful to get several
backtraces (i.e., bt nfsd pid, cont, bt nfsd pid ...) to
see where it running.
Also, just in case, does filesystem that is exported and shows problem,
have quotas enabled ? One line of your fstab has userquotas, other does not.
pgpbHTNNDGLgc.pgp
Description: PGP signature
Re: Fwd: Problem with modern Postfix on 4.7
Scott Harrison [EMAIL PROTECTED] writes: There was a suggestion on the web indicating that binutils is the problem and that that should be updated. However, I do not know the proper way to go about updating binutils. Can someone please tell me how to do it or point me to a resource that does? NOTE I haven't tried to understand all of your two posts. The easiest solution is probably to update FreeBSD 4.X using the official ways described in the handbook, I'd suggest using 4.11, as 4.10 is about to be discontinued, and kernel and base system security fixes are only provided for 4.10 and 4.11 at this time. The ports tree has been requiring FreeBSD 4.8 at a minimum for a very long time now, and I'd expect that even that it requires 4.11 soon enough. -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fwd: Problem with modern Postfix on 4.7
On Tue, May 23, 2006 at 11:02:38AM +0200, Matthias Andree wrote: Scott Harrison [EMAIL PROTECTED] writes: There was a suggestion on the web indicating that binutils is the problem and that that should be updated. However, I do not know the proper way to go about updating binutils. Can someone please tell me how to do it or point me to a resource that does? NOTE I haven't tried to understand all of your two posts. The easiest solution is probably to update FreeBSD 4.X using the official ways described in the handbook, I'd suggest using 4.11, as 4.10 is about to be discontinued, and kernel and base system security fixes are only provided for 4.10 and 4.11 at this time. The ports tree has been requiring FreeBSD 4.8 at a minimum for a very long time now, and I'd expect that even that it requires 4.11 soon enough. Or even better, upgrade to 6.x which is the current supported system. For those still on 4.x, please see http://www.freebsd.org/portmgr/policies_releng_4.html -erwin -- Erwin Lansing http://droso.org Security is like an onion. (o_ _o) It's made up of several layers \\\_\ /_///[EMAIL PROTECTED] And it makes you cry.) ([EMAIL PROTECTED] pgpIlTFLVCAB2.pgp Description: PGP signature
Re: Odd RS232 problem
On Saturday 13 May 2006 22:00, Holger Kipp wrote: First, make sure you have a dedicated IRQ for the card. Then, add options PUC_FASTINTR to your kernel config. This is impossible :( I can't change what the BIOS does, and rearranging the cards is not possible remotely :) I would hope that 9600 baud wouldn't be *too* fast for a 2GHz CPU :( If you encounter silo overflows, you might need to increase cp4ticks in sio.c, eg - cp4ticks = speed / 10 / hz * 4; + cp4ticks = speed / 10 / hz * 40; and/or you might want to change hz from 1000 back to 100. OK, I'll try it. Have you looked at the port speed and if it is changing or has different speeds on both ends? The card together with the modems were really trying very hard to get the data to the other side, and were very good at it, especially with smaller chunks (necessary for dialing and authentication). Problems then started with real traffic going over the line - and we didn't get any errors in messages... It is a fixed speed device so I don't think this is the problem. My impression is that serial io irq-handling on 6.x needs some improvement (personal feeling: it is much worse then on 4.x). Yes, I think the interrupt latency in 6.x is much higher. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp7bowKfteqb.pgp Description: PGP signature
Re: Odd RS232 problem
On Tue, 2006-May-23 19:23:20 +0930, Daniel O'Connor wrote: I would hope that 9600 baud wouldn't be *too* fast for a 2GHz CPU :( That depends on what else is sharing the IRQ. PLIP can give you 10's of msec of latency. PIO disks can also destroy latency as can NE2000-style NICs. -- Peter Jeremy pgpW6x4995kmg.pgp Description: PGP signature
Re: FreeBSD Security Survey
Quoting Paul Allen [EMAIL PROTECTED]: From Scott Long [EMAIL PROTECTED], Sun, May 21, 2006 at 11:44:27PM -0600: I share this frustration with you. I was once told that the pain in upgrading is due largely to a somewhat invisible difference between installing a pre-compiled package, and building+installing a port. In theory, if you stick to one method or the other, things will stay mostly consistent. But if you mix them, and particularly if you update the ports tree in the process, the end result is a bit more undefined. One thing that I wish for is that the ports tree would branch for releases, and that those branches would get security updates. I know that this would involve an exponentially larger amount of effort from the ports team, and I don't fault them for not doing it. Still, it would be nice to have. Huh? Really. What you say makes a certain amount of sense when pkg_add is used, but I haven't seen much evidence for problems with mixing ports and packages via portupgrade -P. The trouble comes not with packages but in the conflicting information between /var/db/pkg/ and the ports themselves. The former does not merely contain a stale version of the port dependency and origin information; it contains many snapshots of small slices of many different port dependency graphs (as the port tree evolves). Consistently using portupgade -rR, portinstall helps keep this under control but each pkg_add or make install in a port directory causes drift. Given that portupgrade is an optional tool and the handbook suggests the other form... well you see the trouble. But the situation is worse than this because of the manual interventions necessary to fixup the portsdb. These fixups easily create dependency graphs that never existed anywhere else before. Most often this happens because of ports being renamed, deleted, combined, etc--the trouble here is that the ports tree reveals no history about these actions. It is left to a program like portupgrade to heuristically guess!?! what has taken place. Now if you go through this process every week (every day?) usually the risk is small and it is obvious what to do, but this is not always so. Some speculation: I've always thought portupgrade did the Wrong Thing(tm) by consulting the dependency graph in /var/db. Better to merely learn which packages were installed and then exclusively use the port information... Maybe someone knows why that would be the wrong thing to do? May I insert a me too here? This (everything you've written here) has been my *only* reason for choosing not to upgrade immediately. I find the ease of using the ports system *glorious*, *_until_* it comes time to upgrade (installed ports). This is especially true when you have imposed subtle changes (inserted default options for the build/ install, created/ crafted ini/ conf files). Using make.conf *seemed* like the ultimate solution. That is, until you've found that you were on the leading edge of a major revision of a port, and those options are no longer supported, or have been renamed. Still, make.conf is a wonderful tool. But even w/o custom options/conf's inposed, upgrades through portupgrade (from my experience) is a trip to hell. That I never look forward to re-living/visiting. In short; there *must* be a better (less painful) way to handle upgrading the _installed_ ports. I only wish I could figure one out. Please note; this is a solicitation. ;) I am only adding (augmenting) to what Paul has stated here. (I build/manage some 50 FreeBSD boxes. So you can imagine the grief.) --Chris H. Paul ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Shameless self-promotion follows... ... or does it? - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / pgpRtA6dfllA3.pgp Description: PGP Digital Signature
Re: FreeBSD Security Survey
Quoting Ion-Mihai IOnut Tetcu [EMAIL PROTECTED]: On Mon, 22 May 2006 11:40:16 +0200 Marian Hettwer [EMAIL PROTECTED] wrote: ports tree in the process, the end result is a bit more undefined. One thing that I wish for is that the ports tree would branch for releases, and that those branches would get security updates. I know that this would involve an exponentially larger amount of effort from the ports team, and I don't fault them for not doing it. Still, it would be nice to have. I have to agree on that statement. I would love to see branched ports. This can get very important on servers, were you don't want to have major upgrades, but only security updates. I guess it's a question of manpower, hm? With the maintainers/commiters/physical_resources we have now this is impossible. Take a look at pav@'s PR stats page: http://www.oook.cz/bsd/prstats/ There are ~1000 new ports PRs per month. The PT Team has managed to close about the same number per month (fewer during the freeze, of course). Currently there are 551 open PRs. 238 in feedback state, etc. Would a survey help? As in ask the ports team and FreeBSD administrators? Maybe some will start to become port maintainer too, just to support the increased work on ports due to branching them... I would :) There are ~4300 unmaintained ports. Maybe you could start maintaining some of them _now_ ? This brings up a point I have been wanting to bring up for over a mos.; I adopted an orphaned port (contacted the owner, whom then relenquished ownership to me.). But found it _more_ than difficult to discover how to inform the fBSD port(s) system of it's new, *un*orphaned status. I read through the online doc's about it. But got dizzy with the circularness of it. Searching led to no _difinative_ answer(s) either. Is it still send pr just to update it's status? Couldn't there be an online form to change ownership/ stewardship? I *can* comprehend the send pr system. I simply can't understand how to change/ update ownership/ stewardship. Perhaps this is why so many of the orphaned ports remain in this state. --Chris H. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect BOFH excuse #146: Communications satellite used by the military for star wars -- Shameless self-promotion follows... ... or does it? - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / pgpSp33SjGs7X.pgp Description: PGP Digital Signature
Loading geom_eli in loader.conf disables psm0
To encrypt my home slice with geli I followed 17.16.2 Disk Encryption with geli: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html#AEN26326 As I prefer to have my home directory available after boot, I additionally added: geli_devices=ad0s1 geli_ad0s1_flags=-k /root/ad0s1.key to rc.conf and rebooted. geli worked, my mouse no longer did. psm0 got lost: --- dmesg-geli-enabled-in-loader.conf.txt Mon May 22 18:17:23 2006 +++ dmesg-without-geli-enabled-in-loader.conf.txt Mon May 22 18:21:33 2006 [...] @@ -76,7 +76,9 @@ atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] -acpi_ibm0: IBM ThinkPad ACPI Extras irq 12 on acpi0 +psm0: PS/2 Mouse irq 12 on atkbdc0 +psm0: [GIANT-LOCKED] +psm0: model Generic PS/2 mouse, device ID 0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ppc0: Standard parallel printer port port 0x3bc-0x3be irq 7 on acpi0 @@ -88,12 +90,13 @@ sio1: type 16550A battery0: ACPI Control Method Battery on acpi0 acpi_acad0: AC Adapter on acpi0 +acpi_ibm0: IBM ThinkPad ACPI Extras on acpi0 pmtimer0 on isa0 [...] After I removed 'geom_eli_load=YES' in loader.conf and rebooted psm0 was back and my mouse started to work again. I saw no geli regression either, I assume geom_eli.ko is loaded on demand by geli's rc script. [EMAIL PROTECTED] ~ $kldstat Id Refs AddressSize Name 1 25 0xc040 41309c kernel 21 0xc0814000 b880 unionfs.ko 31 0xc082 5760 if_tap.ko 41 0xc0826000 565c snd_ich.ko 52 0xc082c000 258d4sound.ko 61 0xc0852000 43f4 acpi_video.ko 73 0xc0857000 62fdcacpi.ko 81 0xc08ba000 21dacradeon.ko 92 0xc08dc000 10d80drm.ko 101 0xc08ed000 4c88 acpi_ibm.ko 113 0xc08f2000 215ccwlan.ko 121 0xc0914000 2ea0 wlan_wep.ko 131 0xc0917000 eec8 if_iwiNG.ko 143 0xc0926000 2e60 firmware.ko 151 0xc0929000 300fciwi_bss.ko 161 0xc095a000 9500 cpufreq.ko 171 0xc35a2000 b000 geom_eli.ko 181 0xc35c1000 19000crypto.ko 191 0xc35ad000 a000 zlib.ko My /boot/loader.conf: loader_logo=beastie loader_color=YES autoboot_delay=1 hw.ata.atapi_dma=1 radeon_load=YES acpi_video_load=YES acpi_ibm_load=YES wlan_load=YES wlan_wep_load=YES if_iwiNG_load=YES iwi_bss_load=YES cpufreq_load=YES snd_ich_load=YES if_tap_load=YES unionfs_load=YES #geom_eli_load=YES hw.psm.synaptics_support=1 [EMAIL PROTECTED] ~ $uname -a FreeBSD TP51.local 6.1-STABLE FreeBSD 6.1-STABLE #30: Mon May 22 15:52:13 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/THINKPAD i386 Fabian -- http://www.fabiankeil.de/ signature.asc Description: PGP signature
Re: Odd RS232 problem
On Tuesday 23 May 2006 19:45, Peter Jeremy wrote: On Tue, 2006-May-23 19:23:20 +0930, Daniel O'Connor wrote: I would hope that 9600 baud wouldn't be *too* fast for a 2GHz CPU :( That depends on what else is sharing the IRQ. PLIP can give you 10's of msec of latency. PIO disks can also destroy latency as can NE2000-style NICs. Hmm, well I just realised I don't actually know what it IS sharing an IRQ with as puc/sio don't say :( I don't have any ISA hardware or PIO disks in the system. I do have a parallel port which I am not using though. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpdhKNPj6pOg.pgp Description: PGP signature
Re: Odd RS232 problem
On Tuesday 23 May 2006 21:18, Daniel O'Connor wrote: On Tuesday 23 May 2006 19:45, Peter Jeremy wrote: On Tue, 2006-May-23 19:23:20 +0930, Daniel O'Connor wrote: I would hope that 9600 baud wouldn't be *too* fast for a 2GHz CPU :( That depends on what else is sharing the IRQ. PLIP can give you 10's of msec of latency. PIO disks can also destroy latency as can NE2000-style NICs. Hmm, well I just realised I don't actually know what it IS sharing an IRQ with as puc/sio don't say :( Duh I am blind.. It shares an IRQ with the RAID controller.. atapci0: Promise PDC20378 SATA150 controller port 0x7800-0x783f,0x7400-0x740f,0x7000-0x707f mem 0xfb30-0xfb300fff,0xfb20-0xfb21 irq 18 at device 8.0 on pci0 puc0: Dolphin Peripherals 4036 port 0x9400-0x941f irq 18 at device 13.0 on pci0 The disks are SATA150 though, no PIO here! -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpGlZnmfrjnF.pgp Description: PGP signature
Re: 6.1-stable crash
On 5/12/06, Vlad GALU [EMAIL PROTECTED] wrote: [...] Just for the record, this has just happened again. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Security Survey
Chris H. wrote: This brings up a point I have been wanting to bring up for over a mos.; I adopted an orphaned port (contacted the owner, whom then relenquished ownership to me.). But found it _more_ than difficult to discover how to inform the fBSD port(s) system of it's new, *un*orphaned status. I read through the online doc's about it. But got dizzy with the circularness of it. Searching led to no _difinative_ answer(s) either. Is it still send pr just to update it's status? Couldn't there be an online form to change ownership/ stewardship? I *can* comprehend the send pr system. I simply can't understand how to change/ update ownership/ stewardship. Perhaps this is why so many of the orphaned ports remain in this state. Open a PR and simply set MAINTAINER to your own address. Use category 'ports' and and class 'change-request'. Frank ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: generic_bcopy() corrupts backtrace?
On Sun, May 21, 2006 at 03:36:13PM -0400, Kris Kennaway wrote: On Sun, May 21, 2006 at 09:04:05PM +0200, Christian Brueffer wrote: Core and debug kernel are available, but the trace appears to be corrupted. Sorry to hijack your thread, but I'm also seeing corrupted backtraces from kgdb involving generic_bcopy(). Is there something about its asm implementation that confuses kgdb? Hmm, not sure. As far as i recall, all traces I got from kgdb during the last months were corrupted. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgpLTCypZoMkD.pgp Description: PGP signature
Re: FreeBSD Security Survey
Quoting Frank Steinborn [EMAIL PROTECTED]: Chris H. wrote: This brings up a point I have been wanting to bring up for over a mos.; I adopted an orphaned port (contacted the owner, whom then relenquished ownership to me.). But found it _more_ than difficult to discover how to inform the fBSD port(s) system of it's new, *un*orphaned status. I read through the online doc's about it. But got dizzy with the circularness of it. Searching led to no _difinative_ answer(s) either. Is it still send pr just to update it's status? Couldn't there be an online form to change ownership/ stewardship? I *can* comprehend the send pr system. I simply can't understand how to change/ update ownership/ stewardship. Perhaps this is why so many of the orphaned ports remain in this state. Open a PR and simply set MAINTAINER to your own address. Use category 'ports' and and class 'change-request'. Will do. Thank you very much for taking the time to respond. --Chris H. Frank ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / pgpVmvm0UfPIK.pgp Description: PGP Digital Signature
Re: Odd RS232 problem
At 05:53 AM 23/05/2006, Daniel O'Connor wrote: On Saturday 13 May 2006 22:00, Holger Kipp wrote: If you encounter silo overflows, you might need to increase cp4ticks in sio.c, eg - cp4ticks = speed / 10 / hz * 4; + cp4ticks = speed / 10 / hz * 40; and/or you might want to change hz from 1000 back to 100. OK, I'll try it. This fixes the overflows for me as well. I have a number of boxes out in the field running with this local modification (40 vs 4). Without it, I have problems running a PCI modem at speeds better than 9600 without causing overflows. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Trouble with NFSd under 6.1-Stable, any ideas?
If there are any thing I can provide to help tracking this down. Please let me know. By the way, I tried with truss/kdump to see what happens when nfsd eats lot of CPUs, but in vain. They do not return anything. I tried your recipe on 7-CURRENT with locally exported fs, remounted over nfs. I did not get the behaviour your described. As noted in my previous thread, I have another 6.1-RELEASE nfs server, which does not have this problem. Could you, please, provide the backtrace for the nfsd that eats the CPU (from the ddb). I think it would be helpful to get several backtraces (i.e., bt nfsd pid, cont, bt nfsd pid ...) to see where it running. I'm afraid that I can not do that. Last time I tried breaking into ddb (on 5.x), it hangs my serial console and the server is miles away :-( . Perhaps we can ask Howard to do that? I am more than willing to do that, as this machine runs here with me, so if needed I can easily get on a console, or perform a reboot. Can one of you shed a little light on exactly what I need to do, and how to do this? I ask as I have never used this ddb stuff, so not clue one on how to go about getting the information your looking to find. Guess I have been lucky, and just never had an issue that took things to this level. Also, just in case, does filesystem that is exported and shows problem, have quotas enabled ? One line of your fstab has userquotas, other does not. As to userquotas, I just tried accessing the NFS mounts here, as some have filesystems with quotas, and some don't, and both are exibiting the exact same problem. So using quotas is for sure not the problem, or should I say not the trigger to the problem. Regards, Rong-En Fan --- Howard Leadmon http://www.leadmon.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trouble with NFSd under 6.1-Stable, any ideas?
On 5/23/06, Konstantin Belousov [EMAIL PROTECTED] wrote:
On Mon, May 22, 2006 at 05:43:32PM -0400, Rong-en Fan wrote:
On 5/14/06, Kris Kennaway [EMAIL PROTECTED] wrote:
On Sun, May 14, 2006 at 02:28:55PM -0400, Howard Leadmon wrote:
Hello All,
I have been running FBSD a long while, and actually running since the
5.x
releases on the server I am having troubles with. I basically have a
small
network and just use NIS/NFS to link my various FBSD and Solaris machines
together.
This has all been running fine up till a few days ago, when all of a
sudden
NFS came to a crawl, and CPU usage so high the box appears to freeze
almost.
When I had 6.1-RC running all seemed well, then came the announcement
for the
official 6.1 release, so I did the cvs updates, made world, kernel, and
ran
mergemaster to get everything up to the 6.1 stable version.
Now after doing this, something is wrong with NFS. It works, it will
return
information and open files, just it's very very slow, and while
performing a
request the CPU spike is astounding. A simple du of my home directory
can
take minutes, and machine all but locks up if the request is done over
NFS.
Here is top snip:
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU
COMMAND
497 root 1 40 1252K 780K - 2 50:42 188.48% nfsd
This is a nice IBM eServer with dual P4-XEON's and a couple GB or RAM
on a
disk array, and locally is screams, heck NFS used to scream till I
updated. I
am not really sure what info would be useful in debugging, so won't post
tons
of misc junk in this eMail, but if anyone has any ideas as to how best to
figure out and resolve this issue it would sure be appreicated...
Use tcpdump and related tools to find out what traffic is being sent.
Also verify that you did not change your system configuration in any
way: there have been no changes to NFS since the release, so it is
unclear why an update would cause the problem to suddenly occur.
Kris
Hi Kris and Howard,
As I posted few days ago, I have similar problems like Howard's
(some details in the thread 6.1-RELEASE, em0 high interrupt rate
and nfsd eats lots of cpu on stable@). After binary searching
the source tree, I found that
RELENG_6_1, 2006.04.30.03.57 ok
RELENG_6_1, 2006.04.30.04.00 bad
The only commit is kern/vfs_lookup.c, an MFC of rev 1.90 and 1.91.
With 04.30 03.57's source + manaully patched vfs_lookup.c rev 1.90,
the same problem occurs.
Let me refresh what problems I'm seeing
1. a client (no matter Linux 2.6.16 or FreeBSD 6.1) runs du on
a nfs directory
2. on server-side, nfsd starts to eats lots of CPU
3. the du finishes
4. on server-side, nfsd still eats lots of CPU, but there is no
nfs traffic. Wait for 5 minutes, you can still see that nfsd is
running and eats lots of CPU.
On FreeBSD 6.1R client, it uses UDP mount and fstab is like
rw,-L,nosuid,bg,nodev. On Linux cleint, it uses UDP mount and
fstab is like defaults,udp,hard,intr,nfsvers=3,rsize=8192,wsize=8192.
The server's kernel conf is at
http://www.rafan.org/FreeBSD/nfs/KERNEL
Some related configuration files:
/etc/export
/export/dir1 host1 host2...
/export/dir2 host1 host2...
/etc/rc.conf
nfs_server_enable=YES
nfs_server_flags=-u -t -n 16
mountd_enable=YES
mountd_flags=-r -l -n
rpc_lockd_enable=YES
rpc_statd_enable=YES
rpcbind_enable=YES
/etc/fstab:
/dev/... /export/dir1 ufs rw,nosuid,noexec 2 2
/dev/... /export/dir2 ufs rw,nosuid,noexec,userquota 2 2
The NFS server is also using amd to mount some backup directories
from another NFS server. the amd.conf is
[global]
browsable_dirs = yes
map_type = file
mount_type = nfs
auto_dir = /nfs
fully_qualified_hosts = no
log_file = syslog
nfs_proto = udp
nfs_allow_insecure_port = no
nfs_vers = 3
# plock = yes
selectors_on_default = yes
restart_mounts = yes
[/backup]
map_options = type:=direct
map_name = /etc/amd.direct
/etc/amd.direct:
/defaults
opts:=rw,grpid,resvport,vers=3,proto=udp,nosuid,nodev,rsize=8192,wsize=8192
backup type:=nfs;rhost:=nfs2;rfs:=/nfs2/${host}
If there are any thing I can provide to help tracking this down. Please
let me know. By the way, I tried with truss/kdump to see what happens
when nfsd eats lot of CPUs, but in vain. They do not return anything.
I tried your recipe on 7-CURRENT with locally exported fs, remounted
over nfs. I did not get the behaviour your described.
As noted in my previous thread, I have another 6.1-RELEASE nfs server,
which does not have this problem.
Could you, please, provide the backtrace for the nfsd that
eats the CPU (from the ddb). I think it would be helpful to get several
backtraces (i.e., bt nfsd pid, cont, bt nfsd pid ...) to
see where it running.
I'm afraid that I can not do that. Last time I tried breaking into ddb (on 5.x),
it hangs my serial console and the server is miles away :-( . Perhaps we
Re: Trouble with NFSd under 6.1-Stable, any ideas?
On 5/23/06, Howard Leadmon [EMAIL PROTECTED] wrote: If there are any thing I can provide to help tracking this down. Please let me know. By the way, I tried with truss/kdump to see what happens when nfsd eats lot of CPUs, but in vain. They do not return anything. I tried your recipe on 7-CURRENT with locally exported fs, remounted over nfs. I did not get the behaviour your described. As noted in my previous thread, I have another 6.1-RELEASE nfs server, which does not have this problem. Could you, please, provide the backtrace for the nfsd that eats the CPU (from the ddb). I think it would be helpful to get several backtraces (i.e., bt nfsd pid, cont, bt nfsd pid ...) to see where it running. I'm afraid that I can not do that. Last time I tried breaking into ddb (on 5.x), it hangs my serial console and the server is miles away :-( . Perhaps we can ask Howard to do that? I am more than willing to do that, as this machine runs here with me, so if needed I can easily get on a console, or perform a reboot. Can one of you shed a little light on exactly what I need to do, and how to do this? I ask as I have never used this ddb stuff, so not clue one on how to go about getting the information your looking to find. Guess I have been lucky, and just never had an issue that took things to this level. At least you have to add the following to your kernel: options KDB options DDB Recompile it, reboot. You would better to setup a serial console so you can easily copy thing from ddb output. To do it, you have to put device sio in your kernel configuration and some files below: /boot.config -Dh /boot/loader.conf comconsole_speed=115200 machdep.conspeed=115200 /etc/ttys ttyd0 /usr/libexec/getty std.115200 cons25 on secure On the other machine, /etc/remote: com1:dv=/dev/cuad0:br#115200:pa=none: Then, use tip com1 to attach the nfs server. The above settings assume your serial console on nfs server is on COM1 and on the client side is also COM1. If that's not the case, please follow Handbook for howto setup a serial console other than COM1. To break into ddb, either use ctrl+alt+esc or send a BREAK (I think ^b will do) via serial line. After that, you should see db Then you first use ps to find out the nfsd pid (better to remember the pid which eats lots of cpu before enter ddb). After that, do what Konstantin suggests. I have never tried cont in db. I guess that will return the execution back to kernel and you need to break into ddb again to do another bt pid. By the way, could you verify that backing out vfs_lookup.c rev 1.90 helps in your situation? If not, maybe we are seeing different problems, and then I have to figure out how to make my serial console work here. Thanks, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Security Survey
On May 22, 2006, at 12:38 AM, Brent Casavant wrote: So, in short, that's why *I* rarely update ports for security reasons. Another valid reason is configuration management. We run web services, and in order to ensure nothing breaks, we have to use a fixed set of code. Upgrading any piece of that requires many steps, including verifying functionality and checking for regressions, etc. Basically we have to run our full regression tests on any changes, then roll them out in a controlled fashion minimizing down time.
Re: FreeBSD Security Survey
On May 22, 2006, at 6:45 AM, Steven Hartland wrote: On good example of portupgrade going off on one is a simple upgrade of mtr we dont install any X on our machines so mtr-nox11 is installed. Whenever I've tried portupgrade in the past its always trolled of and started downloading and build the behemoth that is X, CTRL+C hence always ensues and I forget about upgrading until I really HAVE to. Well, then you've misconfigured your portupgrade. It never does so for me because I have WITHOUT_X11 and WITHOUT_GUI set in /etc/ make.conf (why two knobs, I don't know, but many ports use WITHOUT_GUI instead of WITHOUT_X11).
mount_mfs
Hello, How create memory disk from /etc/fstab in FreeBSD 6 without soft-updates? As I can see it impossible. flag -S not allowed in compatibility mode, but by default disk created with soft-updates turned on. I see to ways to fix this problem: 1. In compatibility mode turn off soft-updates --- mdmfs.c.origTue May 23 19:38:26 2006 +++ mdmfs.c Tue May 23 19:43:42 2006 @@ -133,6 +133,7 @@ if (compat) usage(); compat = true; + softdep = false; break; case 'c': argappend(newfs_arg, -c %s, optarg); 2. In compatibility mode allow -S option --- mdmfs.c.origTue May 23 19:38:26 2006 +++ mdmfs.c Tue May 23 19:45:02 2006 @@ -205,8 +205,6 @@ free(set); break; case 'S': - if (compat) - usage(); softdep = false; break; case 's': -- WBR, Anton Yuzhaninov. P. S. Benchmark show that memory disk mounted in async mode work up to 30% faster when soft-updates turned off
quota and snapshots in 6.1-RELEASE
Hi, list. Some time ago quota and, AFAIR, snapshots in 6.1-RELEASE has deadlock problems. What the current situation with this? I'm ready to test patches, if needed. WBR -- Dmitriy Kirhlarov OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia P:+7 495 105 7247 ext.203 F:+7 495 105 7246 E:[EMAIL PROTECTED] OILspace - The resource enriched - www.oilspace.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota and snapshots in 6.1-RELEASE
On 5/23/06, Dmitriy Kirhlarov [EMAIL PROTECTED] wrote: Hi, list. Some time ago quota and, AFAIR, snapshots in 6.1-RELEASE has deadlock problems. What the current situation with this? I'm ready to test patches, if needed. WBR IIRC, there are some quota and snapshots changes merged in 6.1-STABLE after 6.1-RELEASE is releases. So I think you may want to try that. Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Trouble with NFSd under 6.1-Stable, any ideas?
Hello Rong-en, Thanks for the info on getting the debugger configured, and on the serial console. I will have to try and play with the serial console thing more, I just tried putting in the flags and the damn thing hung, I had to boot from CD and take the stuff back out. One thing you mention below that concerns me is that you have version 1.90 of the vfs_lookup.c file. I just did a less on /usr/src/sys/kern/vfs_lookup.c and I see the following: FreeBSD: src/sys/kern/vfs_lookup.c,v 1.80.2.7 2006/04/30 03:57:46 kris Exp I even did a cvsup (I use cvsup2.FreeBSD.org) to make sure I had the current stuff before rebuilding the kernel just now, and still I see the same thing. Is something fishy going on here, or did you by chance make a typo?? --- Howard Leadmon - [EMAIL PROTECTED] http://www.leadmon.net -Original Message- From: Rong-en Fan [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 23, 2006 10:19 AM To: Howard Leadmon Cc: Konstantin Belousov; Kris Kennaway; freebsd-stable@freebsd.org Subject: Re: Trouble with NFSd under 6.1-Stable, any ideas? On 5/23/06, Howard Leadmon [EMAIL PROTECTED] wrote: If there are any thing I can provide to help tracking this down. Please let me know. By the way, I tried with truss/kdump to see what happens when nfsd eats lot of CPUs, but in vain. They do not return anything. I tried your recipe on 7-CURRENT with locally exported fs, remounted over nfs. I did not get the behaviour your described. As noted in my previous thread, I have another 6.1-RELEASE nfs server, which does not have this problem. Could you, please, provide the backtrace for the nfsd that eats the CPU (from the ddb). I think it would be helpful to get several backtraces (i.e., bt nfsd pid, cont, bt nfsd pid ...) to see where it running. I'm afraid that I can not do that. Last time I tried breaking into ddb (on 5.x), it hangs my serial console and the server is miles away :-( . Perhaps we can ask Howard to do that? I am more than willing to do that, as this machine runs here with me, so if needed I can easily get on a console, or perform a reboot. Can one of you shed a little light on exactly what I need to do, and how to do this? I ask as I have never used this ddb stuff, so not clue one on how to go about getting the information your looking to find. Guess I have been lucky, and just never had an issue that took things to this level. At least you have to add the following to your kernel: options KDB options DDB Recompile it, reboot. You would better to setup a serial console so you can easily copy thing from ddb output. To do it, you have to put device sio in your kernel configuration and some files below: /boot.config -Dh /boot/loader.conf comconsole_speed=115200 machdep.conspeed=115200 /etc/ttys ttyd0 /usr/libexec/getty std.115200 cons25 on secure On the other machine, /etc/remote: com1:dv=/dev/cuad0:br#115200:pa=none: Then, use tip com1 to attach the nfs server. The above settings assume your serial console on nfs server is on COM1 and on the client side is also COM1. If that's not the case, please follow Handbook for howto setup a serial console other than COM1. To break into ddb, either use ctrl+alt+esc or send a BREAK (I think ^b will do) via serial line. After that, you should see db Then you first use ps to find out the nfsd pid (better to remember the pid which eats lots of cpu before enter ddb). After that, do what Konstantin suggests. I have never tried cont in db. I guess that will return the execution back to kernel and you need to break into ddb again to do another bt pid. By the way, could you verify that backing out vfs_lookup.c rev 1.90 helps in your situation? If not, maybe we are seeing different problems, and then I have to figure out how to make my serial console work here. Thanks, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Difference in slice numbering FreeBSD 4.x vs. 6.x?
It has been a long time, but today was a rainy day without plans, so now I'm following up on an old thread. On Tue, 21 Feb 2006 08:02:23 -0300 Giovanni P. Tirloni [EMAIL PROTECTED] wrote: I've moved hard disks around many times and this has never happened. Can you send us `fdisk /dev/ad0` from 4.11 and 6.0 so we can spot anything not normal ? I didn't have a live CD or fixit floppy at hand, so I just used the fdisk menu in systinstall (on the 6.1-RELEASE / i386 cd). It says that there are two slices: ad0s3 ad0s4 Does it still boot in the machine after we've booted in the laptop ? Nope, it acts the same there - the boot manager says F3 and F4 aout slices to boot from. Unfortunately, the only slice it will boot is F3, which now is FreeBSD 4.11. Alas, the machine used for testing is a amd64 one, and it will not boot 4.11 completely - it panics with a fatal trap 9 after a ad0 READ timeout and ata0: resetting devices .. I'll guess that it is something I have done, even if I can't figure out what. For the record, I just wiped all slices on the hard drive, installed FreeBSD 6.1-RELEASE (i386) on it, put it back into the laptop and it boots with no problem. The PC card controller in the laptop is still not detected, but that's another story. -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trouble with NFSd under 6.1-Stable, any ideas?
On 5/23/06, Howard Leadmon [EMAIL PROTECTED] wrote: Hello Rong-en, Thanks for the info on getting the debugger configured, and on the serial console. I will have to try and play with the serial console thing more, I just tried putting in the flags and the damn thing hung, I had to boot from CD and take the stuff back out. One thing you mention below that concerns me is that you have version 1.90 of the vfs_lookup.c file. I just did a less on /usr/src/sys/kern/vfs_lookup.c and I see the following: FreeBSD: src/sys/kern/vfs_lookup.c,v 1.80.2.7 2006/04/30 03:57:46 kris Exp I even did a cvsup (I use cvsup2.FreeBSD.org) to make sure I had the current stuff before rebuilding the kernel just now, and still I see the same thing. Is something fishy going on here, or did you by chance make a typo?? Sorry for the confusion. rev 1.90 is the number for -HEAD. To back out this MFC'ed change for RELENG_6_1, please cvsup to RELENG_6_1 date=2006.04.30.03.57.00. Then you should see it is 1.80.2.6 2006/03/31 07:39:24 kris To verify the effect of this revision. Please run RELENG_6_1 with 2006.04.30.03.57.00 and 2006.04.30.04.00.00. Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota and snapshots in 6.1-RELEASE
Rong-en Fan wrote: On 5/23/06, Dmitriy Kirhlarov [EMAIL PROTECTED] wrote: Hi, list. Some time ago quota and, AFAIR, snapshots in 6.1-RELEASE has deadlock problems. What the current situation with this? I'm ready to test patches, if needed. WBR IIRC, there are some quota and snapshots changes merged in 6.1-STABLE after 6.1-RELEASE is releases. So I think you may want to try that. Thats correct. I have been meaning to test these, but not had the time to do so yet. If you can, update to -STABLE and give it a test. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota and snapshots in 6.1-RELEASE
Quoting Mike Jakubik [EMAIL PROTECTED]: IIRC, there are some quota and snapshots changes merged in 6.1-STABLE after 6.1-RELEASE is releases. So I think you may want to try that. Thats correct. I have been meaning to test these, but not had the time to do so yet. If you can, update to -STABLE and give it a test. I have been running the fixes without problems since this weekend, but I was only bitten by the previous bugs maybe once or twice a week, even though I used snapshots and quotas extensively. If my system manages to stay up at least two weeks it is most likely fixed. :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota and snapshots in 6.1-RELEASE
Mike Jakubik wrote: Rong-en Fan wrote: On 5/23/06, Dmitriy Kirhlarov [EMAIL PROTECTED] wrote: Hi, list. Some time ago quota and, AFAIR, snapshots in 6.1-RELEASE has deadlock problems. What the current situation with this? I'm ready to test patches, if needed. WBR IIRC, there are some quota and snapshots changes merged in 6.1-STABLE after 6.1-RELEASE is releases. So I think you may want to try that. Thats correct. I have been meaning to test these, but not had the time to do so yet. If you can, update to -STABLE and give it a test. I had a motherboard die in a server on Sunday. It is running FreeBSD 5.4-RELEASE and the only hardware they had to replace it with was an Athlon64 CPU and a motherboard with an ATI chipset. With that board and 5.4, it will only boot in Safe Mode, but then the hard drives are running at very slow speeds. It completely locked up earlier today and they had to do a hard reboot (with no errors on the screen or in /var/log/messages). My plan was to have them fully upgrade the server tonight to a new box (with the same Athlon64 and mobo with ATI chipset since that's all they have), and do a fresh install of 6.1-RELEASE because a very similar board with the same chipset was reported to work in 6.0. Every machine I have or work on runs FreeBSD, but this is the only one that needs quotas because it runs cPanel for customers. I am not sure all the details about the problems with quotas, so will running 6.1-RELEASE with quotas cause problems for sure? If so, any suggestions on what to do given my situation? Would 6.0 be any better? I'd like to have the latest version because doing updates properly remotely is difficult, but if it is not going to work then I may have to use 6.0 if that will work or figure something else out hardware wise. Thanks -Mark -- GnuPG Public Key: http://www.mkproductions.org/mk_pubkey.asc Internet Radio: Party107 (Trance/Electronic) - http://www.party107.com Rock 101.9 The Edge (Rock) - http://www.rock1019.net IRC: MIXXnet IRC Network - irc.mixxnet.net (Nick: MIXX941) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
PostgreSQL uses more memory on 6.1?
I just upgraded from 6-STABLE as of 2006-02-18 to 6-STABLE as of 2006-05-21, and was surprised to find that PostgreSQL wouldn't start because it couldn't allocate enough shared memory. Thing is, I didn't make a single hardware change during the reboot and didn't upgrade any ports on the machine. My emergency fix was to edit postgresql.conf to change shared_buffers from 8192 to 2048. Unfortunately, that seems to be hurting performance - I'm getting annoying deadlocks at 4AM whenever multiple daemons start their overnight batch runs. Has anyone else seen this behavior when upgrading from 6.0 to 6.1? Any ideas for a fix? I apologize for not having a logfiles, but I was pretty much in a panic to get it back up and running ASAP and didn't think about it until it was too late. -- Kirk Strauser ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quota and snapshots in 6.1-RELEASE
On Tue, May 23, 2006 at 03:18:25PM -0500, Mark Kane wrote: Mike Jakubik wrote: Rong-en Fan wrote: On 5/23/06, Dmitriy Kirhlarov [EMAIL PROTECTED] wrote: Hi, list. Some time ago quota and, AFAIR, snapshots in 6.1-RELEASE has deadlock problems. What the current situation with this? I'm ready to test patches, if needed. WBR IIRC, there are some quota and snapshots changes merged in 6.1-STABLE after 6.1-RELEASE is releases. So I think you may want to try that. Thats correct. I have been meaning to test these, but not had the time to do so yet. If you can, update to -STABLE and give it a test. I had a motherboard die in a server on Sunday. It is running FreeBSD 5.4-RELEASE and the only hardware they had to replace it with was an Athlon64 CPU and a motherboard with an ATI chipset. With that board and 5.4, it will only boot in Safe Mode, but then the hard drives are running at very slow speeds. It completely locked up earlier today and they had to do a hard reboot (with no errors on the screen or in /var/log/messages). My plan was to have them fully upgrade the server tonight to a new box (with the same Athlon64 and mobo with ATI chipset since that's all they have), and do a fresh install of 6.1-RELEASE because a very similar board with the same chipset was reported to work in 6.0. Every machine I have or work on runs FreeBSD, but this is the only one that needs quotas because it runs cPanel for customers. I am not sure all the details about the problems with quotas, so will running 6.1-RELEASE with quotas cause problems for sure? If so, any suggestions on what to do given my situation? Would 6.0 be any better? I'd like to have the latest version because doing updates properly remotely is difficult, but if it is not going to work then I may have to use 6.0 if that will work or figure something else out hardware wise. If you use snapshots with your quotas, update to 6.1-STABLE. If you don't use snapshots, 6.1-R should be fine. This was discussed in excruciating depth a few weeks back, so please read the archives for more. Kris pgpbDarKh9pca.pgp Description: PGP signature
Re: PostgreSQL uses more memory on 6.1?
On May 23, 2006, at 1:31 PM, Kirk Strauser wrote: I just upgraded from 6-STABLE as of 2006-02-18 to 6-STABLE as of 2006-05-21, and was surprised to find that PostgreSQL wouldn't start because it couldn't allocate enough shared memory. Thing is, I didn't make a single hardware change during the reboot and didn't upgrade any ports on the machine. My emergency fix was to edit postgresql.conf to change shared_buffers from 8192 to 2048. Unfortunately, that seems to be hurting performance - I'm getting annoying deadlocks at 4AM whenever multiple daemons start their overnight batch runs. Has anyone else seen this behavior when upgrading from 6.0 to 6.1? Any ideas for a fix? I apologize for not having a logfiles, but I was pretty much in a panic to get it back up and running ASAP and didn't think about it until it was too late. -- Kirk Strauser You need to adjust the shared memory segments allowed by the kernel; see /usr/ports/databases/postgresqlyour-version-server/pkg-message- server for what to add to your kernel config. Most likely, you forgot to move over your kernel customizations to your new kernel...? -Marshall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL uses more memory on 6.1?
On Tuesday 23 May 2006 15:37, Marshall Pierce wrote: You need to adjust the shared memory segments allowed by the kernel; see /usr/ports/databases/postgresqlyour-version-server/pkg-message-server for what to add to your kernel config. Most likely, you forgot to move over your kernel customizations to your new kernel...? Nope, I took care of that: /etc/sysctl.conf: kern.ipc.semmap=256 kern.ipc.shmmax=268435456 /boot/loader.conf kern.ipc.semmni=256 kern.ipc.semmns=512 kern.ipc.semmnu=256 Furthermore, neither of those files (or even my kernel config file) changed between the previous reboot and the one that installed 6.1. At any rate, the kern.ipc.shmmax is much, much greater than the 64MB that I'd been using before for shared_buffers (8192 buffers * 8 KB/buffer). -- Kirk Strauser ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL uses more memory on 6.1?
You need to adjust the shared memory segments allowed by the kernel; see /usr/ports/databases/postgresqlyour-version-server/pkg-message-server for what to add to your kernel config. Most likely, you forgot to move over your kernel customizations to your new kernel...? Nope, I took care of that: /etc/sysctl.conf: kern.ipc.semmap=256 kern.ipc.shmmax=268435456 /boot/loader.conf kern.ipc.semmni=256 kern.ipc.semmns=512 kern.ipc.semmnu=256 Furthermore, neither of those files (or even my kernel config file) changed between the previous reboot and the one that installed 6.1. At any rate, the kern.ipc.shmmax is much, much greater than the 64MB that I'd been using before for shared_buffers (8192 buffers * 8 KB/buffer). He probably meant the following kernel-settings: options SHMMAXPGS=393216 options SEMMNI=240 options SEMMNS=1440 options SEMUME=240 options SEMMNU=720 Those are for my quad-opteron server with 8 GB RAM. Adjust accordingly. Did you compile a custom-build-kernel or GENERIC? regards Claus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL uses more memory on 6.1?
On Tuesday 23 May 2006 04:58 pm, Kirk Strauser wrote: On Tuesday 23 May 2006 15:37, Marshall Pierce wrote: You need to adjust the shared memory segments allowed by the kernel; see /usr/ports/databases/postgresqlyour-version-server/pkg-message- server for what to add to your kernel config. Most likely, you forgot to move over your kernel customizations to your new kernel...? Nope, I took care of that: /etc/sysctl.conf: kern.ipc.semmap=256 kern.ipc.shmmax=268435456 /boot/loader.conf kern.ipc.semmni=256 kern.ipc.semmns=512 kern.ipc.semmnu=256 Furthermore, neither of those files (or even my kernel config file) changed between the previous reboot and the one that installed 6.1. At any rate, the kern.ipc.shmmax is much, much greater than the 64MB that I'd been using before for shared_buffers (8192 buffers * 8 KB/buffer). kern.ipc.shmmaxpgs? Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL uses more memory on 6.1?
On Tuesday 23 May 2006 16:05, Claus Guttesen wrote: He probably meant the following kernel-settings: options SHMMAXPGS=393216 options SEMMNI=240 options SEMMNS=1440 options SEMUME=240 options SEMMNU=720 Those are for my quad-opteron server with 8 GB RAM. Adjust accordingly. Did you compile a custom-build-kernel or GENERIC? I hadn't compiled any of those into my custom kernel, as per some now long-forgotten web page that said I should use the sysctls to reach the same effect. What I'd *really* like to find is an explanation of how to set those numbers. I'm using a single Xeon with 3GB of RAM and have no idea how high to set those, or whether a particular value is too high. Then again, once I figure it out I guess I should have a fair amount of job security. :-) -- Kirk Strauser ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL uses more memory on 6.1?
On Tuesday 23 May 2006 05:13 pm, Jung-uk Kim wrote: On Tuesday 23 May 2006 04:58 pm, Kirk Strauser wrote: On Tuesday 23 May 2006 15:37, Marshall Pierce wrote: You need to adjust the shared memory segments allowed by the kernel; see /usr/ports/databases/postgresqlyour-version-server/pkg-messag e- server for what to add to your kernel config. Most likely, you forgot to move over your kernel customizations to your new kernel...? Nope, I took care of that: /etc/sysctl.conf: kern.ipc.semmap=256 kern.ipc.shmmax=268435456 /boot/loader.conf kern.ipc.semmni=256 kern.ipc.semmns=512 kern.ipc.semmnu=256 Furthermore, neither of those files (or even my kernel config file) changed between the previous reboot and the one that installed 6.1. At any rate, the kern.ipc.shmmax is much, much greater than the 64MB that I'd been using before for shared_buffers (8192 buffers * 8 KB/buffer). kern.ipc.shmmaxpgs? I meant 'kern.ipc.shmall', which used to be 'kern.ipc.shmmaxpgs'. :-( Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL uses more memory on 6.1?
On Tuesday 23 May 2006 05:19 pm, Jung-uk Kim wrote: On Tuesday 23 May 2006 05:13 pm, Jung-uk Kim wrote: On Tuesday 23 May 2006 04:58 pm, Kirk Strauser wrote: On Tuesday 23 May 2006 15:37, Marshall Pierce wrote: You need to adjust the shared memory segments allowed by the kernel; see /usr/ports/databases/postgresqlyour-version-server/pkg-mess ag e- server for what to add to your kernel config. Most likely, you forgot to move over your kernel customizations to your new kernel...? Nope, I took care of that: /etc/sysctl.conf: kern.ipc.semmap=256 kern.ipc.shmmax=268435456 /boot/loader.conf kern.ipc.semmni=256 kern.ipc.semmns=512 kern.ipc.semmnu=256 Furthermore, neither of those files (or even my kernel config file) changed between the previous reboot and the one that installed 6.1. At any rate, the kern.ipc.shmmax is much, much greater than the 64MB that I'd been using before for shared_buffers (8192 buffers * 8 KB/buffer). kern.ipc.shmmaxpgs? I meant 'kern.ipc.shmall', which used to be 'kern.ipc.shmmaxpgs'. Okay, I don't know what I am talking about here. It is still kern.ipc.shmmaxpgs to set it. In fact, I found a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=75542 However, it seems rwatson closed wrong one at the time. :-( Sorry for the noise, Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL uses more memory on 6.1?
On Tuesday 23 May 2006 16:19, Jung-uk Kim wrote: I meant 'kern.ipc.shmall', which used to be 'kern.ipc.shmmaxpgs'. :-( That did it! Bumping kern.ipc.shmall to 65536 got me back up and running with enough shared_memory to get my jobs done. -- Kirk Strauser ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.1-stable crash
Am I the only one who sees the oxymoronity in 6.1-stable crash? On 23 May 2006, at 11:53 AM, Vlad GALU wrote: On 5/12/06, Vlad GALU [EMAIL PROTECTED] wrote: [...] Just for the record, this has just happened again. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL uses more memory on 6.1?
Kirk Strauser wrote: On Tuesday 23 May 2006 16:19, Jung-uk Kim wrote: I meant 'kern.ipc.shmall', which used to be 'kern.ipc.shmmaxpgs'. :-( That did it! Bumping kern.ipc.shmall to 65536 got me back up and running with enough shared_memory to get my jobs done. Having not so long ago been caught by this myself, I think the relationship between shmmax and shmall is worth clarifying: $ sysctl -d kern.ipc.shmall kern.ipc.shmall: Maximum number of pages available for shared memory $ sysctl -d kern.ipc.shmmax kern.ipc.shmmax: Maximum shared memory segment size So to run 1 Postgres installation with 128Mb of shared memory: kern.ipc.shmall=32768 kern.ipc.shmmax=134217728 However suppose you want to run 2 Postgres installations, each using 128Mb of shared memory: kern.ipc.shmall=65536 kern.ipc.shmmax=134217728 i.e. maximum system wide shared memory is 65536*4096 = 256Mb, but the maximum size any single segment can be is 128Mb. Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
internal compiler error: segmentation fault: 11
Hello, I'm trying to compile 6.0-stable on a release box, prior to upgrade. I've tried several times and all end with an internal compiler error: segmentation fault: 11. And then i'm told to submit a bug report. My problem is when this occurs it's not always at the same spot or the same file. One time it even core dumped, though only once. At this point i would appreciate any suggestions, i'm hoping this is not the indicator of a problem. Thanks. Dave. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: internal compiler error: segmentation fault: 11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, May 23, 2006 at 09:03:06PM -0400, Dave wrote: Hello, I'm trying to compile 6.0-stable on a release box, prior to upgrade. I've tried several times and all end with an internal compiler error: segmentation fault: 11. And then i'm told to submit a bug report. My problem is when this occurs it's not always at the same spot or the same file. One time it even core dumped, though only once. Unfortunately, it's often indicative of hardware failure. See http://www.freebsd.org./doc/en_US.ISO8859-1/books/faq/troubleshoot.html#SIGNAL11 It's the classic hardware indicator, dying at random points in the build. Good luck. Hardware troubleshooting is often a major pain in the neck. - -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Willy: What are you gonna' do with him, anyway? Spike: I'm thinkin' maybe dinner and a movie. I don't want to rush into anything. I've been hurt, you know. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEc7S1+lTVdes0Z9YRAsVSAJ9hwEZkyyWBIQMbdwzLvKXQnYN83wCgsHmm xkJK0VRRz7da9WHu0kYgDKw= =zCqB -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: internal compiler error: segmentation fault: 11
On Tue, May 23, 2006 at 09:03:06PM -0400, Dave wrote: Hello, I'm trying to compile 6.0-stable on a release box, prior to upgrade. I've tried several times and all end with an internal compiler error: segmentation fault: 11. And then i'm told to submit a bug report. My problem is when this occurs it's not always at the same spot or the same file. One time it even core dumped, though only once. This is a prime-indicator of dodgy memory. -- Jonathan Chen [EMAIL PROTECTED] -- A person should be able to do a small bit of everything, specialisation is for insects ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
amd64/97019: Cannot load the kernel after installation on Supermicro H8DAR-T
To whom it may concern: I was informed to make a post regarding problem report 97019 (http://www.freebsd.org/cgi/query-pr.cgi?pr=97019.) According to my experiences, both i386 and am64 installations produce the same result. Although the workaround works perfectly, I suppose this post needs to get done. Before I start on the details, I need to clarify the problem report a tad. Before: Fix 1) Load fixit image with installation cd-rom and switch to holographic shell (CTRL-ALT-F4) 2) mount /dev/ad4s1a to any directory of your choice (e.g. mount /dev/ad4s1a /mnt.) 2) copy /dist/kernels/install.sh to the above partition just mounted. 3) edit the install.sh and change the line that says /$[some variable]-/boot to the newely mounted parition /boot (e.g. /mnt/boot) 4) change to the /dist/kernels directory and run the install.sh from your mounted drive with kernel kernel arguments (e.g. cd /dist/kernels /mnt/install.sh kernel kernel) After corrections made: Fix 1) Load fixit image with installation cd-rom and switch to holographic shell (CTRL-ALT-F4) 2) mount /dev/ad4s1a to any directory of your choice (e.g. mount /dev/ad4s1a /mnt.) 3) env DESTDIR=/mnt /dist/6.1-RELEASE/kernels/install.sh GENERIC 4) mv /mnt/boot/GENERIC /mnt/boot/kernel 5) umount /mnt 6) reboot Some details: Motherboard is Supermicro. The model is H8DAR-T (taken directly from motherboard) It has the Marvel SATA Controller with a 250 Gigabyte Western Digital Hard Drive. Attached are the output files for the 'pciconf -l -v' and 'dmesg' commands. I apologize for any errors (on my part) or if I have missed anything. Just let me know. -=-Thanks in Advance -=-Greg Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-RELEASE #0: Sun May 7 04:04:14 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Opteron(tm) Processor 246 (2004.55-MHz K8-class CPU) Origin = AuthenticAMD Id = 0xf5a Stepping = 10 Features=0x78bfbff AMD Features=0xe0500800 real memory = 1073676288 (1023 MB) avail memory = 1024700416 (977 MB) ACPI APIC Table: ioapic1: Changing APIC ID to 6 ioapic1: WARNING: intbase 40 != expected base 24 ioapic2: Changing APIC ID to 7 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard ioapic1 irqs 40-46 on motherboard ioapic2 irqs 47-53 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x5008-0x500b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci3: on pcib1 atapci0: port 0xb800-0xb8ff mem 0xfea0-0xfeaf irq 42 at device 3.0 on pci3 ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 ata5: on atapci0 pci0: at device 1.1 (no driver attached) pcib2: at device 2.0 on pci0 pci2: on pcib2 bge0: mem 0xfe8f-0xfe8f irq 49 at device 3.0 on pci2 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:30:48:57:03:40 bge1: mem 0xfe8e-0xfe8e irq 50 at device 3.1 on pci2 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:30:48:57:03:41 pci0: at device 2.1 (no driver attached) pcib3: at device 6.0 on pci0 pci1: on pcib3 ohci0: mem 0xfe7fe000-0xfe7fefff irq 19 at device 0.0 on pci1 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfe7fd000-0xfe7fdfff irq 19 at device 0.1 on pci1 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered pci1: at device 4.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 7.1 on pci0 ata0: on atapci1 ata1: on atapci1 pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: 2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: 16550A-compatible COM port port
Re: internal compiler error: segmentation fault: 11
Jonathan Chen wrote: On Tue, May 23, 2006 at 09:03:06PM -0400, Dave wrote: Hello, I'm trying to compile 6.0-stable on a release box, prior to upgrade. I've tried several times and all end with an internal compiler error: segmentation fault: 11. And then i'm told to submit a bug report. My problem is when this occurs it's not always at the same spot or the same file. One time it even core dumped, though only once. This is a prime-indicator of dodgy memory. Yeah - but it can easily be power supply or motherboard age. I suffered the latter late last year with a Tyan Thunder LE, I'm using the same power supply and memory in a Supermicro P3TDER and it is rock solid. Best wishes Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Increase in panics under 6.1
hi all, I've seen an increase in panics since upgrading to 6.1 (I'm tracking RELENG_6). 6.1-Release seemed ok, but since updating kernel/world to more recent updates, I've been having lockups on resume. I'm using a Thinkpad z60M with ACPI enabled. Info on the machine can be found here: http://www.meijome.net/files/freebsd/ayiin_20060524/ The new panic i'm getting is: --- Dump header from device /dev/ad0s1g Architecture: i386 Architecture Version: 2 Dump Length: 1072168960B (1022 MB) Blocksize: 512 Dumptime: Fri May 19 21:49:56 2006 Hostname: ayiin.x Magic: FreeBSD Kernel Dump Version String: FreeBSD 6.1-STABLE #3: Tue May 16 23:35:52 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AYIIN Panic String: sleeping thread Dump Parity: 2510391376 Bounds: 0 Dump Status: good --- I have also have hard locks using DRI with Radeon - on 6.0 it used to just disable itself. no kernel dump in this case Locks due to attempting to use iwi after a resume are as bad as during 6.0 How can I help to diagnose / test these issues? ( If there is a solution, i wouldn't mind having it :-) ) thanks!! Beto ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: internal compiler error: segmentation fault: 11
On Tue, May 23, 2006 at 09:03:06PM -0400, Dave wrote: Hello, I'm trying to compile 6.0-stable on a release box, prior to upgrade. I've tried several times and all end with an internal compiler error: segmentation fault: 11. And then i'm told to submit a bug report. My problem is when this occurs it's not always at the same spot or the same file. One time it even core dumped, though only once. At this point i would appreciate any suggestions, i'm hoping this is not the indicator of a problem. It's almost certainly hardware failure. Google for more information. Kris pgpVmcU00z3pd.pgp Description: PGP signature
Re: Increase in panics under 6.1
On Wed, May 24, 2006 at 11:56:59AM +1000, Norberto Meijome wrote: hi all, I've seen an increase in panics since upgrading to 6.1 (I'm tracking RELENG_6). 6.1-Release seemed ok, but since updating kernel/world to more recent updates, I've been having lockups on resume. I'm using a Thinkpad z60M with ACPI enabled. Info on the machine can be found here: http://www.meijome.net/files/freebsd/ayiin_20060524/ The new panic i'm getting is: --- Dump header from device /dev/ad0s1g Architecture: i386 Architecture Version: 2 Dump Length: 1072168960B (1022 MB) Blocksize: 512 Dumptime: Fri May 19 21:49:56 2006 Hostname: ayiin.x Magic: FreeBSD Kernel Dump Version String: FreeBSD 6.1-STABLE #3: Tue May 16 23:35:52 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AYIIN Panic String: sleeping thread Dump Parity: 2510391376 Bounds: 0 Dump Status: good --- So what is the traceback? See the developers handbook for more information. Kris pgpVdSXjcJeYp.pgp Description: PGP signature
