ipoptions sysctl option
Hi I read the pdf detailing new changes in 5.3 networking and noticed a new sysctl variable is added 'net.inet.ip.process_options' Here is the description. IP Options do not have any practical use today. The only useful application is RR (Record Route) where it remembers the last 8 hops the packet traversed through. That allows you to check parts of the path back to you. IP options processing is rather expensive because the packet header has to be modified and expanded. In addition the only other use is to circumvent or trick firewalls thus it is normally blocked there. The options are these: (By: andre) # sysctl net.inet.ip.process_options=0 Possible Modes: net.inet.ip.process_options=0 Ignore IP options and pass pkts unmodfied net.inet.ip.process_options=1 Process all IP options (default) net.inet.ip.process_options=2 Reject all pkts with IP options with ICMP IPv4 Processing As it says above mine is set to 1 the default, would setting it to 0 help with things like DDOS attacks because it is processing less and what side affects if any could I expect from ignoring ip options? thanks Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
apache+mod_ssl signal 4
Hi I Installed a fresh apache-moddssl port (using portinstall www/apache13-modssl) When i start apache using apachectl start everything works just fine, but when i try apachectl startssl i have some errors i have no idea what to do with httpd-error log gives me : [Fri Apr 1 11:40:24 2005] [info] mod_unique_id: using ip addr 127.0.0.1 [Fri Apr 1 11:40:25 2005] [info] (2)No such file or directory: make_sock: for port 443, setsockopt: (SO_ACCEPTFILTER) [Fri Apr 1 11:40:25 2005] [info] (2)No such file or directory: make_sock: for port 80, setsockopt: (SO_ACCEPTFILTER) system logs gives me : pid 62364 (httpd), uid 0: exited on signal 4 (core dumped) Apr 1 11:48:45 www kernel: pid 62364 (httpd), uid 0: exited on signal 4 (core dumped) i run gdb httpd httpd.core in /usar/local ang got : ... Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x28474fe5 in RSA_new_method () from /lib/libcrypto.so.3 (gdb) where #0 0x28474fe5 in RSA_new_method () from /lib/libcrypto.so.3 #1 0x28474d2e in RSA_new () from /lib/libcrypto.so.3 #2 0x28493aa6 in RSAPrivateKey_asn1_meth () from /lib/libcrypto.so.3 #3 0x284a24e0 in ASN1_item_ex_new () from /lib/libcrypto.so.3 #4 0x284a22c0 in ASN1_item_ex_new () from /lib/libcrypto.so.3 #5 0x2849cf20 in ASN1_item_ex_d2i () from /lib/libcrypto.so.3 #6 0x2849c785 in ASN1_item_d2i () from /lib/libcrypto.so.3 #7 0x28493b25 in d2i_RSAPrivateKey () from /lib/libcrypto.so.3 #8 0x2837bc73 in ssl_init_TmpKeysHandle () from /usr/local/libexec/apache/libssl.so #9 0x2837b752 in ssl_init_Module () from /usr/local/libexec/apache/libssl.so #10 0x08056e50 in ap_init_modules () #11 0x080611a0 in standalone_main () #12 0x08061ab2 in main () www# uname -a FreeBSD www.bmby.co.il 5.3-RELEASE-p5 FreeBSD 5.3-RELEASE-p5 #2: Tue Feb 22 16:47:08 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BMBY-STABLE i386 Please help if you can Thanks -- Uzi Klein BMBY Software Systems Ltd P: +972 4 959 79 89 F: +972 3 617 93 36 http://www.bmby.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
updating from 5.2.1 to RELENG_5
As per subject, I need to do this urgently, but with minimum downtime. Will it be ok just to cvsup, rebuild kernel and world, mergemaster, (etc) like any normal update? Or do I have to do a reinstall? Any help appreciated. Regards, Philip Brennan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel NTP flipping between FLL and PLL modes
My 5.x machines are regularly reporting that the kernel is flipping between FLL and PLL mode (as shown by STA_MODE in syslog messages). This isn't occuring on my 4.x machines (they typically report 2040 then 2041 and stay indefinitely in that mode). Any suggestions as to why this is happening? (And how I can stop it regularly flipping) A fairly typical set of syslog entries looks like: Apr 1 00:15:16 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 00:32:22 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 01:23:36 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 01:40:42 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 10:09:10 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 10:26:14 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 12:59:58 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 13:51:14 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 16:07:48 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 16:59:06 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 19:15:42 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 19:49:48 fwall2 ntpd[407]: kernel time sync enabled 2001 -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
USB-BT sockets error
Hello When I try to use rfcomm_sppd -a Mts-freeze -t /dev/ttyp6, I receive an error: Could not connect socket. Connection refused. What that mean? FreeBSD Release 5.3 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: updating from 5.2.1 to RELENG_5
* Phil Brennan [EMAIL PROTECTED] [20050401 12:19]: Will it be ok just to cvsup, rebuild kernel and world, mergemaster, (etc) like any normal update? Or do I have to do a reinstall? Read UPDATING (all of it). Read UPDATING (all of it). Did you notice the 20041001 entry? You should be able to use libmap.conf to work around it until you recompile all your ports. qvb -- pica ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: updating from 5.2.1 to RELENG_5
On Fri, Apr 01, 2005 at 11:20:09AM +0100, Phil Brennan wrote: As per subject, I need to do this urgently, but with minimum downtime. Will it be ok just to cvsup, rebuild kernel and world, mergemaster, (etc) like any normal update? Or do I have to do a reinstall? Any help appreciated. There were some problems with this particular upgrade (though I've forgotten if it all took place after 5.3BETA7 or even before that. Also, many of the issues were in ports rather than base system, having to do with some updates to gcc and libpthreads. I have a page where I mentioned this towards the bottom at http://home.nyc.rr.com/computertaijutsu/cvsup.html (the page is dated, but it does cover that particular upgrade, which is one reason I leave it up.) You also might want to take a look around Freebsdforums.org, there were a few threads on it. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Xander: Just because you're better than us doesn't mean you can be all superior. pgpOXExBsWHau.pgp Description: PGP signature
USB device causes kernel panic
Hi folks, I have a XS-Drive Pro VP300 (Vosonic) here which runs fine as USB1 device, but completely screws up my system when pluggeg into a USB2 port. I'm running (%:~)- uname -a FreeBSD arc.pmp.uni-hannover.de 5.3-STABLE FreeBSD 5.3-STABLE #2: Thu Dec 9 12:00:08 CET 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARC i386 My pci devices are [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x07351039 rev=0x01 hdr=0x00vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS 735 Host-to-PCI Bridge' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x00011039 rev=0x00 hdr=0x01vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS 530 Virtual PCI-to-PCI bridge (AGP)' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:2:0: class=0x060100 card=0x chip=0x00081039 rev=0x00 hdr=0x00vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS PCI to ISA Bridge (LPC Bridge)' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:2:2: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x07 hdr=0x00vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5597/8 Universal Serial Bus Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:2:3: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x07 hdr=0x00vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5597/8 Universal Serial Bus Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:2:5: class=0x010180 card=0x55131039 chip=0x55131039 rev=0xd0 hdr=0x00vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5513 EIDE Controller (A,B step)' class= mass storage subclass = ATA [EMAIL PROTECTED]:2:7: class=0x040100 card=0x030013f6 chip=0x70121039 rev=0xa0 hdr=0x00vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS7012 PCI Audio Accelerator' class= multimedia subclass = audio [EMAIL PROTECTED]:3:0: class=0x02 card=0x09001039 chip=0x09001039 rev=0x90 hdr=0x00vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS900 Fast Ethernet/Home Networking Ctrlr' class= network subclass = ethernet [EMAIL PROTECTED]:11:0: class=0x01 card=0x78619004 chip=0x61789004 rev=0x03 hdr=0x00vendor = 'Adaptec Inc' device = 'AIC-7861 AHA-2940AU PCI SCSI Controller' class= mass storage subclass = SCSI [EMAIL PROTECTED]:15:0: class=0x010400 card=0x100113c1 chip=0x100113c1 rev=0x01 hdr=0x00vendor = '3ware Inc.' device = '7000 series ATA-100 Storage Controller' class= mass storage subclass = RAID [EMAIL PROTECTED]:19:0: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x50 hdr=0x00vendor = 'VIA Technologies Inc' device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)' class= serial bus subclass = USB [EMAIL PROTECTED]:19:1: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x50 hdr=0x00vendor = 'VIA Technologies Inc' device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)' class= serial bus subclass = USB [EMAIL PROTECTED]:19:2: class=0x0c0320 card=0x12340925 chip=0x31041106 rev=0x51 hdr=0x00vendor = 'VIA Technologies Inc' device = 'VT6202 USB 2.0 Enhanced Host Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:0:0: class=0x03 card=0x4c431019 chip=0x59641002 rev=0x01 hdr=0x00vendor = 'ATI Technologies Inc.' device = 'Radeon 9200 Radeon 9200 SE Series' class= display subclass = VGA [EMAIL PROTECTED]:0:1: class=0x038000 card=0x4c421019 chip=0x5d441002 rev=0x01 hdr=0x00vendor = 'ATI Technologies Inc.' device = 'Radeon 9200 SE Series - Secondary (RV280)' class= display When booting and plugging in the device afterwards I see the following messages: Copyright (c) 1992-2004 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 5.3-STABLE #2: Thu Dec 9 12:00:08 CET 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 2400+ (1991.54-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x681 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMO V,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc040AMIE,DSP,3DNow! real memory = 805240832 (767 MB) avail memory = 778158080 (742 MB) netsmb_dev: loaded npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: AMIINT SiS735XX on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU (3 Cx states) on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: SiS 735 host to
Re: Kernel NTP flipping between FLL and PLL modes
On Apr 1, 2005, at 05:45, Peter Jeremy wrote: Any suggestions as to why this is happening? (And how I can stop it regularly flipping) I don't think this is really an issue. It may be annoying to see it in the logs, but NTPv4 uses each algorithm when it's appropriate to get the most accurate time. Since network conditions change, the way NTP has to deal with them changes since it queries other NTP servers over the network. This was actually freebsd-questions last year and one response pointed to this paper: http://www.eecis.udel.edu/~mills/database/papers/allan.pdf You may want to check-out the the netgroup comp.protocols.time.ntp if you want to ask the experts (and authors) on NTP. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB device causes kernel panic
At 07:39 AM 01/04/2005, Gerrit Kühn wrote: Hi folks, I have a XS-Drive Pro VP300 (Vosonic) here which runs fine as USB1 device, but completely screws up my system when pluggeg into a USB2 port. I'm running (%:~)- uname -a FreeBSD arc.pmp.uni-hannover.de 5.3-STABLE FreeBSD 5.3-STABLE #2: Thu Dec 9 12:00:08 CET 2004 Hi, Try updating to the latest RELENG_5. There have been a lot of USB bug fixes since Dec. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB device causes kernel panic
On Fri, 01 Apr 2005 08:05:47 -0500 Mike Tancsa [EMAIL PROTECTED] wrote about Re: USB device causes kernel panic: MT (%:~)- uname -a MT FreeBSD arc.pmp.uni-hannover.de 5.3-STABLE FreeBSD 5.3-STABLE #2: Thu MT Dec 9 12:00:08 CET 2004 MT Try updating to the latest RELENG_5. There have been a lot of USB bug MT fixes since Dec. Ok, I'll do that (and be back with the results probably on Monday). Thanks for the hint. cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
Hi, At 14:04 01/04/2005, David Magda wrote: On Apr 1, 2005, at 05:45, Peter Jeremy wrote: Any suggestions as to why this is happening? (And how I can stop it regularly flipping) I don't think this is really an issue. [etc] I think this is an issue: - As stated, machines running 4.x don't seem to do it - In addition to the mode schizophrenia, undex 5.3 I'm also seeing resets of several seconds which don't happen on identical hardware running 4.11 in the same rack. Yes I know the clock drifts will be different, but ntp.drift is very close on the two boxen. I believe something's broken. More datapoints: - I'm seeing it under 5.3R both on i386 and amd64 but not i386/4.11 on the same LAN - I'm not seeing it on 5.1R on a remote system -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: updating from 5.2.1 to RELENG_5
On Apr 1, 2005 12:49 PM, Joan Picanyol i Puig [EMAIL PROTECTED] wrote: * Phil Brennan [EMAIL PROTECTED] [20050401 12:19]: Will it be ok just to cvsup, rebuild kernel and world, mergemaster, (etc) like any normal update? Or do I have to do a reinstall? Read UPDATING (all of it). Read UPDATING (all of it). Yes, I always read it. Did you notice the 20041001 entry? You should be able to use libmap.conf to work around it until you recompile all your ports. Yes, it referrs to compat4x libraries. Not an issue for me, since I'm upgrading from 5.2.1 to RELENG_5. Regarding libmap, yes I have used it before. Basically, I'm looking for advice from people who have done this particular upgrade. Its an upgrade that should be straightforward. I was only wondering if there were any extra little gotchas that I should consider. Thanks for all the replies so far. Regards, Philip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_5, snapshots and disk lock time
On Thu, Mar 31, 2005 at 06:32:27PM -0800, Dave Knight wrote: That document also says: As is detailed in the operational information below, snapshots are definitely alpha-test code and are NOT yet ready for production use. Is this the current opinion of snapshots ? Not really, you just have to be aware of the inbuilt limitations, as you are. Kris pgpjiMVMzx2q4.pgp Description: PGP signature
5.3 STABLE to 5.4-PRERELEASE
Hello everybody, I had 5.3 STABLE. Did cvsup as I always do with *default tag=RELENG_5 That should leave the server in STABLE, should not it? Here is the problem. #cvsup -g /etc/cvsupfile #make buildworld #make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=INET #make -DALWAYS_CHECK_MAKE installkernel KERNCONF=INET #make installworld #reboot After rebooting and telneting to the server I saw FreeBSD 5.4-PRERELEASE (INET) #4: Thu Mar 31 20:41:59 EST 2005 Where is it coming from? Does anyone else have had the same problem? Thank you for your help in advance. Irina ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3 STABLE to 5.4-PRERELEASE
Hello everybody, I had 5.3 STABLE. Did cvsup as I always do with *default tag=RELENG_5 That should leave the server in STABLE, should not it? Here is the problem. #cvsup -g /etc/cvsupfile #make buildworld #make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=INET #make -DALWAYS_CHECK_MAKE installkernel KERNCONF=INET #make installworld #reboot After rebooting and telneting to the server I saw FreeBSD 5.4-PRERELEASE (INET) #4: Thu Mar 31 20:41:59 EST 2005 Where is it coming from? Does anyone else have had the same problem? Thank you for your help in advance. Irina Hi Irina. A quick read through www.freebsd.org/handbook would tell you why this is.basicly if you wanted 5.3-P? You should use RELENG_5_3 -- Ísak Ben. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3 STABLE to 5.4-PRERELEASE
On Fr, 1.04.2005, 16:59, Irina sagte: Hello everybody, Hi there, I had 5.3 STABLE. Did cvsup as I always do with *default tag=RELENG_5 After rebooting and telneting to the server I saw FreeBSD 5.4-PRERELEASE (INET) #4: Thu Mar 31 20:41:59 EST 2005 Where is it coming from? Does anyone else have had the same problem? That's no Problem. There is no RELENG_5_4 yet, so RELENG_5 is now 5.4-PRERELEASE. Everything's normal ;) don't worry ... before 5.4-PRERELEASE my 5-STABLE box was 5.3-STABLE... so I guess, as soon as RELENG_5_4 is branched, you'll get something like 5.4-STABLE when cvsup'ing to RELENG_5 Thank you for your help in advance. :) best regards, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Adaptec 3210S, 4.9-STABLE, corruption when disk fails
From: Uwe Doering [mailto:[EMAIL PROTECTED]
...
As far as I understand this family of controllers the OS
drivers aren't involved at all in case of a disk drive
failure. It's strictly the controller's business to deal
with it internally. The OS just sits there and waits until
the controller is done with the retries and either drops into
degraded mode or recovers from the disk error.
That's why I initially speculated that there might be a
timeout somewhere in PostgreSQL or FreeBSD that leads to data
loss if the controller is busy for too long.
A somewhat radical way to at least make these failures as
rare an event as possible would be to deliberately fail all
remaining old disk drives, one after the other of course, in
order to get rid of them. And if you are lucky the problem
won't happen with newer drives anyway, in case the root cause
is an incompatibility between the controller and the old drives.
Started that yesterday. I've got one 'old' one left.
Sadly, the one that failed night before last was not one of the
'old' ones, so this is no guarantee :)
From the raidutil -e log, I see this type of info. I'm not sure
what the 'unknown' events are. The 'CRC Failure' is probably the
problem? There's also Bad SCSI Status, unit attention, etc.
Perhaps the driver doesn't deal with these properly?
$ raidutil -e d0
03/31/2005 23:37:59 Level 1
Lock for Channel 0 : Started
03/31/2005 23:37:59 Level 1
Lock for Channel 1 : Started
03/31/2005 23:38:09 Level 1
Lock for Channel 0 : Stopped
03/31/2005 23:38:22 Level 1
Lock for Channel 1 : Stopped
03/31/2005 23:38:22 Level 4
HBA=0 BUS=0 ID=0 LUN=0
Status Change
Optimal = Degraded - Drive Failed
03/31/2005 23:38:22 Level 1
Unknown Event : 56 10 00 08 EE 89 4C 42 00 00 00 00
03/31/2005 23:38:22 Level 1
CRC Failure
Number of dirty blocks = -1
D30A1F2A
03/31/2005 23:38:24 Level 3
HBA=0 BUS=0 ID=0 LUN=0
Bad SCSI Status - Check Condition
28 00 00 00 00 00 00 00 01 00 00 00
03/31/2005 23:38:24 Level 3
HBA=0 BUS=0 ID=0 LUN=0
Request Sense
70 00 06 00 00 00 00 0A 00 00 00 00 29 02 02 00 00 00
Unit Attention
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
on 01.04.2005 16:24 Bob Bishop said the following: I think this is an issue: - As stated, machines running 4.x don't seem to do it - In addition to the mode schizophrenia, undex 5.3 I'm also seeing resets of several seconds which don't happen on identical hardware running 4.11 in the same rack. Yes I know the clock drifts will be different, but ntp.drift is very close on the two boxen. I believe something's broken. More datapoints: - I'm seeing it under 5.3R both on i386 and amd64 but not i386/4.11 on the same LAN - I'm not seeing it on 5.1R on a remote system I can second that. I have never seen anything like this with 5.2.1 as soon as I upgraded to 5.3 I started seeing messages like these: Mar 29 01:19:51 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 06:12:49 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 06:29:53 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 09:03:25 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 09:20:31 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 11:20:04 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 11:37:08 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 14:44:55 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 15:02:01 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 17:52:50 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 18:09:54 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 18:44:03 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 19:54:30 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 22:15:40 oddity ntpd[400]: time reset -0.288522 s Mar 29 22:15:40 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 23:09:19 oddity ntpd[400]: time reset +0.530732 s Mar 29 23:09:19 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 23:35:18 oddity ntpd[400]: time reset -0.165853 s Mar 30 00:41:14 oddity ntpd[400]: time reset -0.199104 s Mar 30 11:21:21 oddity ntpd[400]: kernel time sync enabled 6001 Mar 30 11:38:27 oddity ntpd[400]: kernel time sync enabled 2001 Mar 30 17:22:37 oddity ntpd[400]: time reset -0.392425 s Mar 30 17:22:37 oddity ntpd[400]: kernel time sync enabled 6001 Mar 30 17:26:06 oddity ntpd[400]: kernel time sync enabled 2001 Mar 30 17:28:15 oddity ntpd[400]: time reset +0.309711 s Mar 30 18:07:02 oddity ntpd[400]: time reset +0.164515 s Mar 30 18:41:43 oddity ntpd[400]: time reset -0.391355 s Mar 30 19:00:17 oddity ntpd[400]: time reset +0.598313 s Mar 30 19:47:45 oddity ntpd[400]: time reset -0.276978 s Mar 30 21:26:24 oddity ntpd[400]: time reset +0.158781 s Mar 30 23:18:01 oddity ntpd[400]: time reset +0.160708 s Mar 30 23:18:01 oddity ntpd[400]: kernel time sync enabled 6001 Mar 30 23:19:13 oddity ntpd[400]: kernel time sync enabled 2001 Mar 31 08:36:16 oddity ntpd[400]: kernel time sync enabled 6001 Mar 31 08:53:20 oddity ntpd[400]: kernel time sync enabled 2001 Mar 31 11:44:02 oddity ntpd[400]: kernel time sync enabled 6001 Mar 31 12:18:08 oddity ntpd[400]: kernel time sync enabled 2001 Mar 31 13:26:30 oddity ntpd[400]: kernel time sync enabled 6001 Mar 31 13:43:35 oddity ntpd[400]: kernel time sync enabled 2001 Mar 31 17:32:07 oddity ntpd[400]: kernel time sync enabled 6001 Mar 31 17:49:11 oddity ntpd[400]: kernel time sync enabled 2001 Mar 31 20:22:54 oddity ntpd[400]: kernel time sync enabled 6001 Mar 31 20:39:59 oddity ntpd[400]: kernel time sync enabled 2001 Mar 31 21:14:08 oddity ntpd[400]: kernel time sync enabled 6001 Mar 31 21:31:11 oddity ntpd[400]: kernel time sync enabled 2001 2001-6001 flips do not trouble me a bit (but annoying), time resets are not a good thing definitely. I suppose that it might be possible that the root cause is in my local network conditions, but I must say that it would feel like ntpd (or something that it relies on) became less robust and it would be nice to get to know how to get that robustness back. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DANGER WILL ROBINSON! SERIOUS problem with current5.4-PRERELEASE - UPDATE (real this time) #2
On Thu, Mar 31, 2005 at 12:02:20PM -0500, Matthew N. Dodd wrote:
On Wed, 30 Mar 2005, Karl Denninger wrote:
Removing the FIRST delta, which is:
218a219,221
if (!dumping)
callout_reset(request-callout, request-timeout * hz,
(timeout_t*)ata_timeout, request);
appears to get rid of the crashes while not harming data integrity OR the
reqeueing.
I'd be interested to know if the attached patch does anything.
--
10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00
Index: ata-queue.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-queue.c,v
retrieving revision 1.32.2.6
diff -u -u -r1.32.2.6 ata-queue.c
--- ata-queue.c 23 Mar 2005 04:50:26 - 1.32.2.6
+++ ata-queue.c 31 Mar 2005 17:00:46 -
@@ -217,8 +217,7 @@
}
else {
if (!dumping)
- callout_reset(request-callout, request-timeout * hz,
- (timeout_t*)ata_timeout, request);
+callout_drain(request-callout);
if (request-bio !(request-flags ATA_R_TIMEOUT)) {
ATA_DEBUG_RQ(request, finish bio_taskqueue);
bio_taskqueue(request-bio, (bio_task_t *)ata_completed, request);
Removing the first delta has allowed the system to survive for over 24
hours, albiet while taking retryable errors.
I have not yet attmepted this patch - but will now that I know that the
system is stable with the first delta OUT.
At minimum Matt that first delta has to come out to avoid the pukes and
chokes - whether the above is recommended (by me anyway) I can't say yet -
more as I know it.
--
--
Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist
http://www.denninger.netMy home on the net - links to everything I do!
http://scubaforum.org Your UNCENSORED place to talk about DIVING!
http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME!
http://genesis3.blogspot.comMusings Of A Sentient Mind
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
Hi, At 17:38 01/04/2005, Andriy Gapon wrote: [...] I suppose that it might be possible that the root cause is in my local network conditions, [etc] Unlikely I think. As I said, I've got several machines on the same LAN: the 5.3's misbehave; the others don't. -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
On Fri, Apr 01, 2005 at 02:24:50PM +0100, Bob Bishop wrote: Any suggestions as to why this is happening? (And how I can stop it regularly flipping) I don't think this is really an issue. [etc] I think this is an issue: - As stated, machines running 4.x don't seem to do it - In addition to the mode schizophrenia, undex 5.3 I'm also seeing resets of several seconds which don't happen on identical hardware running 4.11 in the same rack. Yes I know the clock drifts will be different, but ntp.drift is very close on the two boxen. On my amd64 box I also get the mode flipping, but I don't get resets. Roland -- R.F. Smith /\ASCII Ribbon Campaign r s m i t h @ x s 4 a l l . n l \ /No HTML/RTF in e-mail http://www.xs4all.nl/~rsmith/ X No Word docs in e-mail public key: http://www.keyserver.net / \Respect for open standards pgptsRdgdtWzR.pgp Description: PGP signature
Re: Kernel NTP flipping between FLL and PLL modes
Hi, At 18:42 01/04/2005, Roland Smith wrote: On my amd64 box I also get the mode flipping, but I don't get resets. Hmm. I am getting resets on my amd64. -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG_5 problems with Intel 855 (RELENG_4 boots fine)
We are trying out an Intel 855 that is not able to boot RELENG_5. It locks up hard (NUM LOCK doesnt work) on bootup at the same spot. However, RELENG_4 is able to boot just fine. Copyright (c) 1992-2005 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 5.4-PRERELEASE #0: Fri Apr 1 09:06:22 EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/nfs ACPI APIC Table: AOpen AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) M processor 1500MHz (1500.06-MHz 686-class CPU) Origin = GenuineIntel Id = 0x695 Stepping = 5 Features=0xa7e9fbbfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE real memory = 531496960 (506 MB) avail memory = 510435328 (486 MB) ioapic0 Version 2.0 irqs 0-23 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: AOpen AWRDACPI on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU (3 Cx states) on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 and boot -v /boot/kernel/acpi.ko text=0x41520 data=0x1da4+0x112c syms=[0x4+0x7630+0x4+0x9c97] KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=0009f400 SMAP type=02 base=000f len=0001 SMAP type=02 base=fec0 len=0140 SMAP type=03 base=1fae3000 len=d000 SMAP type=04 base=1fae len=3000 SMAP type=02 base=0009f400 len=0c00 SMAP type=02 base=1faf len=0001 SMAP type=01 base=0010 len=1f9e Copyright (c) 1992-2005 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 5.4-PRERELEASE #0: Fri Apr 1 09:06:22 EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/nfs Preloaded elf kernel /boot/kernel/kernel at 0xc0857000. Preloaded elf module /boot/kernel/usb.ko at 0xc085721c. Preloaded elf module /boot/modules/arcmsr.ko at 0xc08572c4. Preloaded elf module /boot/kernel/acpi.ko at 0xc0857370. Table 'FACP' at 0x1fae30c0 Table 'APIC' at 0x1fae6d40 MADT: Found table at 0x1fae6d40 MP Configuration Table version 1.4 found at 0xc00f0c00 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled ACPI APIC Table: AOpen AWRDACPI Calibrating clock(s) ... i8254 clock: 1193068 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1500060146 Hz CPU: Intel(R) Celeron(R) M processor 1500MHz (1500.06-MHz 686-class CPU) Origin = GenuineIntel Id = 0x695 Stepping = 5 Features=0xa7e9fbbfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE real memory = 531496960 (506 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c25000 - 0x1f1c6fff, 509222912 bytes (124322 pages) avail memory = 510435328 (486 MB) bios32: Found BIOS32 Service Directory header at 0xc00faf00 bios32: Entry = 0xfb380 (c00fb380) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb3b0 pnpbios: Found PnP BIOS data at 0xc00fbd70 pnpbios: Entry = f:bda0 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 ioapic0: Routing external 8259A's - intpin 0 ioapic0: intpin 0 - ExtINT (edge, high) ioapic0: intpin 1 - ISA IRQ 1 (edge, high) ioapic0: intpin 2 - ISA IRQ 2 (edge, high) ioapic0: intpin 3 - ISA IRQ 3 (edge, high) ioapic0: intpin 4 - ISA IRQ 4 (edge, high) ioapic0: intpin 5 - ISA IRQ 5 (edge, high) ioapic0: intpin 6 - ISA IRQ 6 (edge, high) ioapic0: intpin 7 - ISA IRQ 7 (edge, high) ioapic0: intpin 8 - ISA IRQ 8 (edge, high) ioapic0: intpin 9 - ISA IRQ 9 (edge, high) ioapic0: intpin 10 - ISA IRQ 10 (edge, high) ioapic0: intpin 11 - ISA IRQ 11 (edge, high) ioapic0: intpin 12 - ISA IRQ 12 (edge, high) ioapic0: intpin 13 - ISA IRQ 13 (edge, high) ioapic0: intpin 14 - ISA IRQ 14 (edge, high) ioapic0: intpin 15 - ISA IRQ 15 (edge, high) ioapic0: intpin 16 - PCI IRQ 16 (level, low) ioapic0: intpin 17 - PCI IRQ 17 (level, low) ioapic0: intpin 18 - PCI IRQ 18 (level, low) ioapic0: intpin 19 - PCI IRQ 19 (level, low) ioapic0: intpin 20 - PCI IRQ 20 (level, low) ioapic0: intpin 21 - PCI IRQ 21 (level, low) ioapic0: intpin 22 - PCI IRQ 22 (level, low) ioapic0: intpin 23 - PCI IRQ 23
RE: RELENG_5 problems with Intel 855 (RELENG_4 boots fine)
Can you try setting hw.pci.enable_io_modes=0 at the loader prompt then booting? I've seen this same problem on a reasonable amount of machines now (mainly toshiba/acer laptops, but not only) Regards, Graham Lilley Ibex Systems (Maidstone) Ltd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Tancsa Sent: 01 April 2005 19:39 To: freebsd-stable@freebsd.org Subject: RELENG_5 problems with Intel 855 (RELENG_4 boots fine) We are trying out an Intel 855 that is not able to boot RELENG_5. It locks up hard (NUM LOCK doesnt work) on bootup at the same spot. However, RELENG_4 is able to boot just fine. Copyright (c) 1992-2005 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 5.4-PRERELEASE #0: Fri Apr 1 09:06:22 EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/nfs ACPI APIC Table: AOpen AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) M processor 1500MHz (1500.06-MHz 686-class CPU) Origin = GenuineIntel Id = 0x695 Stepping = 5 Features=0xa7e9fbbfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE real memory = 531496960 (506 MB) avail memory = 510435328 (486 MB) ioapic0 Version 2.0 irqs 0-23 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: AOpen AWRDACPI on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU (3 Cx states) on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 and boot -v /boot/kernel/acpi.ko text=0x41520 data=0x1da4+0x112c syms=[0x4+0x7630+0x4+0x9c97] KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=0009f400 SMAP type=02 base=000f len=0001 SMAP type=02 base=fec0 len=0140 SMAP type=03 base=1fae3000 len=d000 SMAP type=04 base=1fae len=3000 SMAP type=02 base=0009f400 len=0c00 SMAP type=02 base=1faf len=0001 SMAP type=01 base=0010 len=1f9e Copyright (c) 1992-2005 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 5.4-PRERELEASE #0: Fri Apr 1 09:06:22 EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/nfs Preloaded elf kernel /boot/kernel/kernel at 0xc0857000. Preloaded elf module /boot/kernel/usb.ko at 0xc085721c. Preloaded elf module /boot/modules/arcmsr.ko at 0xc08572c4. Preloaded elf module /boot/kernel/acpi.ko at 0xc0857370. Table 'FACP' at 0x1fae30c0 Table 'APIC' at 0x1fae6d40 MADT: Found table at 0x1fae6d40 MP Configuration Table version 1.4 found at 0xc00f0c00 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled ACPI APIC Table: AOpen AWRDACPI Calibrating clock(s) ... i8254 clock: 1193068 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1500060146 Hz CPU: Intel(R) Celeron(R) M processor 1500MHz (1500.06-MHz 686-class CPU) Origin = GenuineIntel Id = 0x695 Stepping = 5 Features=0xa7e9fbbfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE real memory = 531496960 (506 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c25000 - 0x1f1c6fff, 509222912 bytes (124322 pages) avail memory = 510435328 (486 MB) bios32: Found BIOS32 Service Directory header at 0xc00faf00 bios32: Entry = 0xfb380 (c00fb380) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb3b0 pnpbios: Found PnP BIOS data at 0xc00fbd70 pnpbios: Entry = f:bda0 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 ioapic0: Routing external 8259A's - intpin 0 ioapic0: intpin 0 - ExtINT (edge, high) ioapic0: intpin 1 - ISA IRQ 1 (edge, high) ioapic0: intpin 2 - ISA IRQ 2 (edge, high) ioapic0: intpin 3 - ISA IRQ 3 (edge, high) ioapic0: intpin 4 - ISA IRQ 4 (edge, high) ioapic0: intpin 5 - ISA IRQ 5 (edge, high) ioapic0: intpin 6 - ISA IRQ 6 (edge, high) ioapic0: intpin 7 - ISA IRQ 7 (edge, high) ioapic0: intpin 8 - ISA IRQ 8 (edge, high) ioapic0: intpin 9 - ISA IRQ 9 (edge, high) ioapic0: intpin 10 - ISA IRQ 10 (edge, high) ioapic0: intpin 11 - ISA IRQ 11 (edge, high) ioapic0: intpin 12 - ISA IRQ 12
RE: RELENG_5 problems with Intel 855 (RELENG_4 boots fine) (solved!)
At 01:29 PM 01/04/2005, Gray Lilley wrote: Can you try setting hw.pci.enable_io_modes=0 at the loader prompt then booting? Thanks! That did the trick!! OK set hw.pci.enable_io_modes=0 OK boot /boot/kernel/acpi.ko text=0x41520 data=0x1da4+0x112c syms=[0x4+0x7630+0x4+0x9c97] KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2005 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 5.4-PRERELEASE #0: Fri Apr 1 09:06:22 EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/nfs ACPI APIC Table: AOpen AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) M processor 1500MHz (1500.06-MHz 686-class CPU) Origin = GenuineIntel Id = 0x695 Stepping = 5 Features=0xa7e9fbbfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE real memory = 534642688 (509 MB) avail memory = 513507328 (489 MB) ioapic0 Version 2.0 irqs 0-23 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: AOpen AWRDACPI on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU (3 Cx states) on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: base peripheral at device 0.1 (no driver attached) pci0: base peripheral at device 0.3 (no driver attached) pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 agp0: Intel 82855GME (855GME GMCH) SVGA controller port 0xe300-0xe307 mem 0xed00-0xed07,0xe000-0xe7ff irq 16 at device 2.0 on pci0 agp0: detected 892k stolen memory agp0: aperture size is 128M pci0: display at device 2.1 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 puc0: Lava Computers Quattro-PCI serial port port 0xd300-0xd307,0xd200-0xd207 irq 16 at device 4.0 on pci2 sio4: Lava Computers Quattro-PCI serial port on puc0 sio4: type 16550A sio4: unable to activate interrupt in fast mode - using normal mode sio5: Lava Computers Quattro-PCI serial port on puc0 sio5: type 16550A sio5: unable to activate interrupt in fast mode - using normal mode puc1: Lava Computers Quattro-PCI serial port port 0xd500-0xd507,0xd400-0xd407 irq 16 at device 4.1 on pci2 sio6: Lava Computers Quattro-PCI serial port on puc1 sio6: type 16550A sio6: unable to activate interrupt in fast mode - using normal mode sio7: Lava Computers Quattro-PCI serial port on puc1 sio7: type 16550A sio7: unable to activate interrupt in fast mode - using normal mode pci2: simple comms, UART at device 5.0 (no driver attached) twe0: 3ware Storage Controller. Driver version 1.50.01.002 port 0xd700-0xd70f mem 0xec00-0xec7f irq 18 at device 6.0 on pci2 twe0: 2 ports, Firmware FE7X 1.05.00.068, BIOS BE7X 1.08.00.048 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH4 UDMA100 controller port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_tz0: Thermal Zone on acpi0 fdc0: floppy drive controller port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 pmtimer0 on isa0 orm0: ISA Option ROM at iomem 0xd-0xd0fff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ppc0: parallel port not found. Timecounter TSC frequency 1500059900 Hz quality 800 Timecounters tick every 10.000 msec ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 3100 packets/entry by default ad0: 38166MB ST340014A/3.06 [77545/16/63] at ata0-master UDMA100 acd0: CDROM CD-ROM 48X/AKU/T31 at ata1-master PIO4 twed0: Unit 0, TwinStor, Normal on twe0 twed0: 76318MB (156299440 sectors) Mounting root from ufs:/dev/ad0s1a Pre-seeding PRNG: kickstart. Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point kickstart. kernel dumps on /dev/ad0s1b swapon: adding /dev/ad0s1b as swap device Starting file system checks: /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1a: clean, 331086 free (990 frags, 41262 blocks, 0.2% fragmentation) /dev/ad0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1e: clean, 500291 free (203 frags, 62511 blocks, 0.0%
Re: Adaptec 3210S, 4.9-STABLE, corruption when disk fails
Don Bowman wrote: From: Uwe Doering [mailto:[EMAIL PROTECTED] ... As far as I understand this family of controllers the OS drivers aren't involved at all in case of a disk drive failure. It's strictly the controller's business to deal with it internally. The OS just sits there and waits until the controller is done with the retries and either drops into degraded mode or recovers from the disk error. That's why I initially speculated that there might be a timeout somewhere in PostgreSQL or FreeBSD that leads to data loss if the controller is busy for too long. A somewhat radical way to at least make these failures as rare an event as possible would be to deliberately fail all remaining old disk drives, one after the other of course, in order to get rid of them. And if you are lucky the problem won't happen with newer drives anyway, in case the root cause is an incompatibility between the controller and the old drives. Started that yesterday. I've got one 'old' one left. Sadly, the one that failed night before last was not one of the 'old' ones, so this is no guarantee :) From the raidutil -e log, I see this type of info. I'm not sure what the 'unknown' events are. The 'CRC Failure' is probably the problem? There's also Bad SCSI Status, unit attention, etc. Perhaps the driver doesn't deal with these properly? In my opinion what the log shows in this case is internal communication between the controller and the disk drives. The OS driver is not involved. In the past I've seen CRC errors like these as a result of bad cabling or contact problems. You may want to check the SCSI cables. They have to be properly terminated and there must not be any sharp kinks given the signal frequencies involved these days. Also, pluggable drive bays can cause this. Every electrical contact is a potential source of trouble. Finally, faulty or overloaded power supplies can cause glitches like these. This can be especially hard to debug. When these hardware issues have been taken care of you may want to start a RAID verification/correction run. If it shows any inconsistencies this may be an indication of former hardware glitches. I'm not sure whether you can trigger that process through 'raidutil'. I've always used the X11 'dptmgr' program. You can terminate it after having started the verification. It continues to run in the background (inside the controller). Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers [EMAIL PROTECTED] | http://www.escapebox.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel NTP flipping between FLL and PLL modes
On Fri, 2005-Apr-01 19:38:41 +0300, Andriy Gapon wrote: I can second that. I have never seen anything like this with 5.2.1 as soon as I upgraded to 5.3 I started seeing messages like these: ... Mar 29 22:15:40 oddity ntpd[400]: time reset -0.288522 s Mar 29 22:15:40 oddity ntpd[400]: kernel time sync enabled 6001 Mar 29 23:09:19 oddity ntpd[400]: time reset +0.530732 s Mar 29 23:09:19 oddity ntpd[400]: kernel time sync enabled 2001 Mar 29 23:35:18 oddity ntpd[400]: time reset -0.165853 s Mar 30 00:41:14 oddity ntpd[400]: time reset -0.199104 s Mar 30 11:21:21 oddity ntpd[400]: kernel time sync enabled 6001 Mar 30 11:38:27 oddity ntpd[400]: kernel time sync enabled 2001 Mar 30 17:22:37 oddity ntpd[400]: time reset -0.392425 s Mar 30 17:22:37 oddity ntpd[400]: kernel time sync enabled 6001 Mar 30 17:26:06 oddity ntpd[400]: kernel time sync enabled 2001 Mar 30 17:28:15 oddity ntpd[400]: time reset +0.309711 s Mar 30 18:07:02 oddity ntpd[400]: time reset +0.164515 s Mar 30 18:41:43 oddity ntpd[400]: time reset -0.391355 s Mar 30 19:00:17 oddity ntpd[400]: time reset +0.598313 s Mar 30 19:47:45 oddity ntpd[400]: time reset -0.276978 s Mar 30 21:26:24 oddity ntpd[400]: time reset +0.158781 s Mar 30 23:18:01 oddity ntpd[400]: time reset +0.160708 s ... 2001-6001 flips do not trouble me a bit (but annoying), time resets are not a good thing definitely. I've seen similar reset behaviour in the past. The investigating I did suggested that the PLL could become unstable under some conditions (though I never managed to work out exactly what triggered the mis-behaviour). It would either lock up around +/- 500ppm and regularly jump in one direction to compensate or it would start swinging wildly and regularly jump back and forth with the net time jumped close to zero (in the latter case, looking at the loopstats showed that the frequency offset would start oscillating with the swings getting larger over time). Manually setting ntp.drift to a realistic value and restarting ntpd seemed to cure the problem (at least temporarily). I haven't seen that problem recently - I think it was in the early 4.x period. I suppose that it might be possible that the root cause is in my local network conditions, If it is network conditions, enabling huff-puff might help. If possible, work out what the real drift on that system is and re-initialise ntp.drift as well. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: RELENG_5 problems with Intel 855 (RELENG_4 boots fine)(solved!)
No Problems. Unfortunately, this will disable (at least one) other items of hardware. Sound Cards seem to be the devices which get killed when using this, but if your not needing sound, it doesn't seem to be much of a problem. I'm yet to find anyone who can actually explain what the problem is that causes this? Is there anyone out there who could suggest why this happens at all, and is there a fix, other than this? Thanks Gray -Original Message- From: Mike Tancsa [mailto:[EMAIL PROTECTED] Sent: 01 April 2005 20:00 To: Gray Lilley; freebsd-stable@freebsd.org Subject: RE: RELENG_5 problems with Intel 855 (RELENG_4 boots fine) (solved!) At 01:29 PM 01/04/2005, Gray Lilley wrote: Can you try setting hw.pci.enable_io_modes=0 at the loader prompt then booting? Thanks! That did the trick!! OK set hw.pci.enable_io_modes=0 OK boot /boot/kernel/acpi.ko text=0x41520 data=0x1da4+0x112c syms=[0x4+0x7630+0x4+0x9c97] KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2005 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 5.4-PRERELEASE #0: Fri Apr 1 09:06:22 EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/nfs ACPI APIC Table: AOpen AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) M processor 1500MHz (1500.06-MHz 686-class CPU) Origin = GenuineIntel Id = 0x695 Stepping = 5 Features=0xa7e9fbbfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE real memory = 534642688 (509 MB) avail memory = 513507328 (489 MB) ioapic0 Version 2.0 irqs 0-23 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: AOpen AWRDACPI on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU (3 Cx states) on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: base peripheral at device 0.1 (no driver attached) pci0: base peripheral at device 0.3 (no driver attached) pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 agp0: Intel 82855GME (855GME GMCH) SVGA controller port 0xe300-0xe307 mem 0xed00-0xed07,0xe000-0xe7ff irq 16 at device 2.0 on pci0 agp0: detected 892k stolen memory agp0: aperture size is 128M pci0: display at device 2.1 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 puc0: Lava Computers Quattro-PCI serial port port 0xd300-0xd307,0xd200-0xd207 irq 16 at device 4.0 on pci2 sio4: Lava Computers Quattro-PCI serial port on puc0 sio4: type 16550A sio4: unable to activate interrupt in fast mode - using normal mode sio5: Lava Computers Quattro-PCI serial port on puc0 sio5: type 16550A sio5: unable to activate interrupt in fast mode - using normal mode puc1: Lava Computers Quattro-PCI serial port port 0xd500-0xd507,0xd400-0xd407 irq 16 at device 4.1 on pci2 sio6: Lava Computers Quattro-PCI serial port on puc1 sio6: type 16550A sio6: unable to activate interrupt in fast mode - using normal mode sio7: Lava Computers Quattro-PCI serial port on puc1 sio7: type 16550A sio7: unable to activate interrupt in fast mode - using normal mode pci2: simple comms, UART at device 5.0 (no driver attached) twe0: 3ware Storage Controller. Driver version 1.50.01.002 port 0xd700-0xd70f mem 0xec00-0xec7f irq 18 at device 6.0 on pci2 twe0: 2 ports, Firmware FE7X 1.05.00.068, BIOS BE7X 1.08.00.048 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH4 UDMA100 controller port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_tz0: Thermal Zone on acpi0 fdc0: floppy drive controller port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 pmtimer0 on isa0 orm0: ISA Option ROM at iomem 0xd-0xd0fff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ppc0: parallel port not found. Timecounter TSC frequency 1500059900 Hz quality 800 Timecounters tick every 10.000 msec ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 3100 packets/entry by default ad0: 38166MB
recent 5.4-PRE regression: Could not resync/reset buffers
Hi guys, I'm resending this mail again with the hopes of finding someone who is also seeing this problem. I know that mail isn't the best method perhaps, but before I open a PR, I thought I'd try again... My last recent update revealed a bug perhaps. I'm now running: FreeBSD dakota 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #28: Wed Mar 23 20:38:58 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DAKOTA64 amd64 The system seems to have problems with filedescriptors. It's not otherwise loaded and it's happed enough that I thought I should mention it before 5.4 goes out the door (around 50% of the time). How to repeat: mpg123 -b 1024 --list playlist (where playlist is a simple list of .mp3 files) I get this error message: Could not resync/reset buffers: Interrupted system call and the program simply hangs using 90%+ cpu I've ktraced the hanging binary, but the result is sort of monotonous. The ktrace.out file is filled with this simple set of lines: 94680 mpg123 RET read 0 94680 mpg123 CALL select(0x400,0x7fffe310,0,0,0) 94680 mpg123 RET select 1 94680 mpg123 CALL read(0x5,0x7fffe2ff,0x1) 94680 mpg123 GIO fd 5 read 0 bytes I haven't done the legwork yet to track this down to a closer time period than sometime since my last kernelworld, 25 december 04. (cc: me, I'm not on the list) -- Yours truly, Shaun D. Jurrens [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: Kernel NTP flipping between FLL and PLL modes
On Apr 1, 2005, at 12:56 PM, Bob Bishop wrote: At 18:42 01/04/2005, Roland Smith wrote: On my amd64 box I also get the mode flipping, but I don't get resets. Hmm. I am getting resets on my amd64. On my dual opteron, I get flipping perhaps a handful of times per day (5.4-PRE/amd64 from march 22). On my Xeon EMT64 with hyperthreading (5.3-STABLE/amd64 from Jan 7), it happens every 2-6 hours. My 5.3-REL/i386 Xeon with hyperthreading does it about two or four times per day, no resetting. Neither one shows time step resets. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
burncd/cdrecord don't work anymore with recently RELENG_5..
Hello, Last time, the burncd/cdrecord were work when I had FreeBSD 5.4-PRERELEASE #0: Fri Mar 18 14:28:40 CST 2005.. Later when I updated RELENG_5 to FreeBSD 5.4-PRERELEASE #0: Sun Mar 27 20:11:40 CST 2005 and the burncd/cdrecord don't work anymore. I tried to update RELENG_5 to yesterday and still no go. I still can mount the CD, but I just can't burn anything on CD. I get errors in the /var/log/messages: === Mar 29 21:44:30 mezz kernel: acd0: unknown transfer phase Mar 29 21:44:30 mezz kernel: acd0: DMA limited to UDMA33, non-ATA66 cable or device Mar 29 21:44:30 mezz kernel: acd0: FAILURE - TEST_UNIT_READY timed out Mar 29 21:45:30 mezz kernel: acd0: unknown transfer phase Mar 29 21:45:30 mezz kernel: acd0: DMA limited to UDMA33, non-ATA66 cable or device Mar 29 21:46:00 mezz kernel: acd0: unknown transfer phase Mar 29 21:46:00 mezz kernel: acd0: DMA limited to UDMA33, non-ATA66 cable or device Mar 29 21:46:00 mezz kernel: acd0: FAILURE - PREVENT_ALLOW timed out Mar 29 21:47:00 mezz kernel: acd0: DMA limited to UDMA33, non-ATA66 cable or device Later when I update RELENG_5 yesterday and I get error: Apr 1 16:13:06 mezz kernel: acd0: unknown transfer phase Apr 1 16:13:06 mezz kernel: acd0: DMA limited to UDMA33, non-ATA66 cable or device Apr 1 16:14:06 mezz kernel: acd0: unknown transfer phase Apr 1 16:14:07 mezz kernel: acd0: DMA limited to UDMA33, non-ATA66 cable or device === === Apr 1 16:30:35 mezz kernel: ata1-master: DMA limited to UDMA33, non-ATA66 cable or device Apr 1 16:30:35 mezz kernel: acd0: CDRW LITE-ON COMBO SOHC-5232K/NK07 at ata1-master UDMA33 [...] Apr 1 16:30:35 mezz kernel: cd0 at ata1 bus 0 target 0 lun 0 Apr 1 16:30:35 mezz kernel: cd0: LITE-ON COMBO SOHC-5232K NK07 Removable CD-ROM SCSI-0 device Apr 1 16:30:35 mezz kernel: cd0: 33.000MB/s transfers Apr 1 16:30:35 mezz kernel: cd0: cd present [1 x 2048 byte records] === === # atacontrol list ATA channel 0: Master: ad0 ST3120026A/8.54 ATA/ATAPI revision 6 Slave: no device present ATA channel 1: Master: acd0 LITE-ON COMBO SOHC-5232K/NK07 ATA/ATAPI revision 5 Slave: no device present === If there is something else you need the info, please let me know. P.S. CC to me, I am not in the 'freebsd-stable' list. Thanks. Cheers, Mezz -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Mounting a powered-down HDD renders system unusable
On a 5.4-pre system as of the last few days, If I mount a spun down hard disk (one I am using only for backup): # mount /backup/usr I get ad1: TIMEOUT _ READ DMA retrying (2 retries left) LBA=7340273 ad0: WARNING - removed from configuration ad1: WARNING - removed from configuration at0-slave: FAILURE - READ DMA Timeout mount:/dev/ad1s1g : Input/Output error ata0-slave: timeout state=0 unexpected initiate_write_filepage: already started initiate_write_filepage: already started (repeat until reset is pushed) Nothing works because all of the disks are unmounted. Can't even shut down. This worked great in 4.10, and also 5.3 (where the initial mount generated an error, but I could do the mount again after the disk spun up). Anybody else get the same thing? I'll open a bug report if so... -- Mike Harding [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
mfc of ipf 3.4.35 breaks POLA in 4.11, 4-Stable
IPF in 4.11, 4-Stable breaks the semantics of icmp keep-state rules. This problem was mentioned in http://msgs.securepoint.com/cgi-bin/get/ipfilter-0503/31/1/2/1/1.html I wouldn't make a fuss over this simple matter except that this constitutes a POLA violation. To that end, the following pr was submitted: http://www.freebsd.org/cgi/query-pr.cgi?pr=79416 Incidentially, unless I really misunderstand ipf, there appears to be a genuine bug here. POLA issues aside, a pass-rule is being used to block packets. Thanks, Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: apache+mod_ssl signal 4
On Fri, 1 Apr 2005, Uzi Klein wrote: I Installed a fresh apache-moddssl port (using portinstall www/apache13-modssl) When i start apache using apachectl start everything works just fine, but when i try apachectl startssl i have some errors i have no idea what to do with httpd-error log gives me : [Fri Apr 1 11:40:24 2005] [info] mod_unique_id: using ip addr 127.0.0.1 [Fri Apr 1 11:40:25 2005] [info] (2)No such file or directory: make_sock: for port 443, setsockopt: (SO_ACCEPTFILTER) [Fri Apr 1 11:40:25 2005] [info] (2)No such file or directory: make_sock: for port 80, setsockopt: (SO_ACCEPTFILTER) Those should be OK, you don't have accept filters installed. system logs gives me : pid 62364 (httpd), uid 0: exited on signal 4 (core dumped) Apr 1 11:48:45 www kernel: pid 62364 (httpd), uid 0: exited on signal 4 (core dumped) Signal 4 is SIGABRT, which is a software-initiated abort. i run gdb httpd httpd.core in /usar/local ang got : ... Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x28474fe5 in RSA_new_method () from /lib/libcrypto.so.3 (gdb) where #0 0x28474fe5 in RSA_new_method () from /lib/libcrypto.so.3 #1 0x28474d2e in RSA_new () from /lib/libcrypto.so.3 #2 0x28493aa6 in RSAPrivateKey_asn1_meth () from /lib/libcrypto.so.3 #3 0x284a24e0 in ASN1_item_ex_new () from /lib/libcrypto.so.3 #4 0x284a22c0 in ASN1_item_ex_new () from /lib/libcrypto.so.3 #5 0x2849cf20 in ASN1_item_ex_d2i () from /lib/libcrypto.so.3 #6 0x2849c785 in ASN1_item_d2i () from /lib/libcrypto.so.3 #7 0x28493b25 in d2i_RSAPrivateKey () from /lib/libcrypto.so.3 #8 0x2837bc73 in ssl_init_TmpKeysHandle () from /usr/local/libexec/apache/libssl.so #9 0x2837b752 in ssl_init_Module () from /usr/local/libexec/apache/libssl.so #10 0x08056e50 in ap_init_modules () #11 0x080611a0 in standalone_main () #12 0x08061ab2 in main () This isn't that useful without a debugging copy of libcrypto, unfortunately. It appears something goes wrong in the RSA key generation and it tanks. How did you generate your certificates? www# uname -a FreeBSD www.bmby.co.il 5.3-RELEASE-p5 FreeBSD 5.3-RELEASE-p5 #2: Tue Feb 22 16:47:08 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BMBY-STABLE i386 -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: updating from 5.2.1 to RELENG_5
On Fri, 1 Apr 2005, Phil Brennan wrote: On Apr 1, 2005 12:49 PM, Joan Picanyol i Puig [EMAIL PROTECTED] wrote: * Phil Brennan [EMAIL PROTECTED] [20050401 12:19]: Will it be ok just to cvsup, rebuild kernel and world, mergemaster, (etc) like any normal update? Or do I have to do a reinstall? Read UPDATING (all of it). Read UPDATING (all of it). Yes, I always read it. Did you notice the 20041001 entry? You should be able to use libmap.conf to work around it until you recompile all your ports. Yes, it referrs to compat4x libraries. Not an issue for me, since I'm upgrading from 5.2.1 to RELENG_5. It will also talk about library version bumps for stuff like libm and changes to the thread libraries. I'd strongly suggest checking the list archives for affected applications and workarounds. Be particularly wary of anything built on 5.2.1. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent 5.4-PRE regression: Could not resync/reset buffers
On Fri, 1 Apr 2005, Shaun Jurrens wrote: Hi guys, I'm resending this mail again with the hopes of finding someone who is also seeing this problem. I know that mail isn't the best method perhaps, but before I open a PR, I thought I'd try again... My last recent update revealed a bug perhaps. I'm now running: FreeBSD dakota 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #28: Wed Mar 23 20:38:58 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DAKOTA64 amd64 The system seems to have problems with filedescriptors. It's not otherwise loaded and it's happed enough that I thought I should mention it before 5.4 goes out the door (around 50% of the time). How to repeat: mpg123 -b 1024 --list playlist (where playlist is a simple list of .mp3 files) I get this error message: Could not resync/reset buffers: Interrupted system call and the program simply hangs using 90%+ cpu Try upgrading mpg123, for starters. Not handling ERESTART is generally a bug. That said, I wonder if some syscall that was uninterrupible before is now not. Can you ktrace mpg123 and try to capture one of the ERESTART returns? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: apache+mod_ssl signal 4
On Fri, Apr 01, 2005 at 06:59:11PM -0800, Doug White wrote: pid 62364 (httpd), uid 0: exited on signal 4 (core dumped) Apr 1 11:48:45 www kernel: pid 62364 (httpd), uid 0: exited on signal 4 (core dumped) Signal 4 is SIGABRT, which is a software-initiated abort. Well, no, it's ILL, indicating perhaps code compiled for a different cpu model than it's being run on, or a trashed library. -- Barney Wolff http://www.databus.com/bwresume.pdf I never met a computer I didn't like. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
