Re:RELENG_6 has problems with booting
What happens if you drop ATAPICAM and do you have a good reason why you are including GEOM_BDE? Thanks S. I will try a kernel without ATAPICAM. I need GEOM_BDE for my encrypted disk but I can also try a kernel without it. A kernel without ATAPICAM will also result in a hang during normal/verbose boot. With a kernel without GEOM_BDE I'm able to boot normally but the machine hanged some minutes later. Again no panic, the machine just hangs. When I do a boot in safe mode, everything is ok. Attachted is the dmesg from the verbose boot. Jonathan Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: ACPI PCI Link LNK5 on acpi0 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: ACPI PCI Link LUBA irq 12 on acpi0 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 12 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 12 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: ACPI PCI Link LUBB irq 11 on acpi0 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: ACPI PCI Link LMAC irq 11 on acpi0 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link8: ACPI PCI Link LAPU on acpi0 pci_link8: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link8: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link8: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link9: ACPI PCI Link LACI irq 12 on acpi0 pci_link9: Links after initial probe: Index IRQ Rtd Ref IRQs 0 12 N 0 3 4 5 6 7 10 11 12 14 15 pci_link9: Links after initial validation: Index IRQ Rtd Ref IRQs 0 12 N 0 3 4 5 6 7 10 11 12 14 15 pci_link9: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link10: ACPI PCI Link LMCI on acpi0 pci_link10: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link10: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link10: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link11: ACPI PCI Link LSMB irq 5 on acpi0 pci_link11: Links after initial probe: Index IRQ Rtd Ref IRQs 05 N 0 3 4 5 6 7 10 11 12 14 15 pci_link11: Links after initial validation: Index IRQ Rtd Ref IRQs 05 N 0 3 4 5 6 7 10 11 12 14 15 pci_link11: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link12: ACPI PCI Link LUB2 irq 5 on acpi0 pci_link12: Links after initial probe: Index IRQ Rtd Ref IRQs 05 N 0 3 4 5 6 7 10 11 12 14 15 pci_link12: Links after initial validation: Index IRQ Rtd Ref IRQs 05 N 0 3 4 5 6 7 10 11 12 14 15 pci_link12: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link13: ACPI PCI Link LFIR on acpi0 pci_link13: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link13: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link13: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link14: ACPI PCI Link L3CM on acpi0 pci_link14: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link14: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link14: Links after disable: Index IRQ Rtd Ref IRQs 0
Serious issue with serial console in 5.4
Hi, I reported this before, but I am very surprised that it is still the case: (This is from the last time it happened; this time the box rebooted and cleared the serial console before I had time to cut/paste it. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 00 fault virtual address = 0x1c fault code = supervisor write, page not present instruction pointer = 0x8:0xc0620b5f stack pointer = 0x10:0xdadbd988 frame pointer = 0x10:0xdadbd994 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 51999 (getty) trap number = 12 panic: page fault cpuid = 1 boot() called on cpu#0 Uptime: 66d11h24m50s The above panic will show up occasionally when logging out from a serial console (i.e. ctrl-D, logout, exit, whatever). This is EXTREMELY BAD, as it will crash an otherwise perfectly healthy box at random - and renders the serial console useless. Robert Watson confirmed this to be an issue on the 10th of April. Anyone?? /Eirik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: reducing shutdown time
Marc Santhoff [EMAIL PROTECTED] wrote:
I was searching for a way to shorten the stopping time in general.
Have a look at ``sysctl kern.shutdown''. If you have only
read-only filesystems, you can probably safely set them to
zero. I haven't tried that myself, though.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co KG, Marktplatz 29, 85567 Grafing
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
PI:
int f[9814],b,c=9814,g,i;long a=1e4,d,e,h;
main(){for(;b=c,c-=14;i=printf(%04d,e+d/a),e=d%a)
while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Virus Alert
The mail message (file: [EMAIL PROTECTED]) you sent to [EMAIL PROTECTED] contains a virus. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Kevin Oberman [EMAIL PROTECTED] wrote: [...] I believe that the Windows solution to this problem is to put a really, really long delay between when the system is finished syncing and when the power is turned off. Definitely not. When I compare Windows XP and FreeBSD on the same hardware (notebook with ATA disk), then Windows' shutdown process is a lot faster than FreeBSD's. In fact, when I shut it down under XP for the first time, the power was off so quickly that I thought someting must have gone wrong. But everything was OK and normal. This might be the best solution for FreeBSD, as well, but it will irritate people. It is already irritating that FreeBSD sits there doing nothing for ~ 5 seconds before turning power off. Windows doesn't do that. (Yes I know, there's a sysctl for that, but I suspect that it's not save to modify it in FreeBSD.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. Emacs ist für mich kein Editor. Für mich ist das genau das gleiche, als wenn ich nach einem Fahrrad (für die Sonntagbrötchen) frage und einen pangalaktischen Raumkreuzer mit 10 km Gesamtlänge bekomme. Ich weiß nicht, was ich damit soll. -- Frank Klemm, de.comp.os.unix.discussion ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Matthias Buelow [EMAIL PROTECTED] wrote: Sorry folks, have I somehow dropped into a parallel universe, or is there some serious misunderstanding going on? Seems so. To the OP: There is no sync process that is being killed by shutdown Yes, there is a kernel process called syncer. During shutdown, each of the kernel processes (including the syncer) has 60 seconds to terminate. If it doesn't, timed out is printed on the console. This timeout can be changed using a sysctl tunable (kern.shutdown.kproc_shutdown_wait). The kernel writes out all dirty buffers as part of its shutdown procedure. When you shut down a machine, the kernel flushes all dirty buffers to disk. While it is doing that, it displays the number of remaining buffers, with increasing time intervals between them. If there are still buffers left after a certain number of intervals without change, the kernel gives up. If that is really the problem, then the best solution would be to make the number of flushing intervals and/or the increasing interval a sysctl tunable. They're currently hardcoded at 20 and 50ms, respectively; see the boot() function in src/sys/kern/kern_shutdown.c. That means that the timeout will happen after 10 seconds. Doubling the number of intervals (i.e. 40 instead of 20) will make the timeout happen after 40 seconds, which should be sufficient. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C++ is the only current language making COBOL look good. -- Bertrand Meyer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Oliver Fromme [EMAIL PROTECTED] writes: buffers to disk. While it is doing that, it displays the number of remaining buffers, with increasing time intervals between them. If there are still buffers left after a certain number of intervals without change, the kernel gives up. Why is it doing this? Can't it just enumerate the buffers and write them, one by one? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Strange top(1) output on 5.4-RELEASE
Hi! I have just noticed this strange thing: % top last pid: 50566; load averages: 0.28, 0.26, 0.23 up 1+18:25:52 16:48:31 90 processes: 3 running, 87 sleeping CPU states: 4.3% user, 0.0% nice, 6.2% system, 1.9% interrupt, 87.5% idle Mem: 315M Active, 39M Inact, 120M Wired, 18M Cache, 60M Buf, 984K Free Swap: 512M Total, 31M Used, 480M Free, 6% Inuse PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 48650 root 91 -5 77028K 33408K select 2:34 6.05% 6.05% Xorg 50520 usov 960 28268K 17564K select 0:01 0.93% 0.93% kdeinit . some output skipped ... 49961 usov 960 31600K 18076K RUN 0:08 0.00% 0.00% kdeinit 48740 usov 20 -76 11772K 6560K kserel 0:07 0.00% 0.00% artsd 464 root 960 3080K 844K select 0:06 0.00% 0.00% ntpd Note the -76 as a NICE value for artsd. In the same time ps axl shows NICE value of 0, which is also quite strange as I have artswrapper installes and artsshell status reports real-time status. I observe this on 5.4-RELEASE-p3. Top ps binaries are supposed to be in sync with the kernel I run (I have already tried rebuilding libkvm top, but this changes nothing). Any ideas? -- Best regards, Alexander. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
On Mon, 2005-07-18 at 16:35 +0200, Matthias Buelow wrote: Oliver Fromme [EMAIL PROTECTED] writes: buffers to disk. While it is doing that, it displays the number of remaining buffers, with increasing time intervals between them. If there are still buffers left after a certain number of intervals without change, the kernel gives up. Why is it doing this? Can't it just enumerate the buffers and write them, one by one? Why would that necessarily be more successful? If the outstanding buffers count is not reducing between time intervals, it is most likely because there is some underlying hardware problem (e.g., a bad block). If the count still persists in staying put, it likely means whatever the hardware is doing to try and fix things (e.g., write reallocation) isn't working, and so the kernel may as well give up. You can enumerate the buffers and *try* to write them, but that doesn't guarantee they will be written successfully any more than observing the relative number left outstanding. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FYI - RELENG_6 branch has been created.
Wow thats a big jump from what I got in a test I did a couple of months ago, here is a copy and paste of an older email Are you using AMD64 mode or i386? Dell 1850 Dual CPU with 4 Gigs of ram, thats in idle CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3192.23-MHz 686-class CPU) FreeBSD 5.4-RELEASE-p1 FreeBSD 5.4-RELEASE-p1 #0: Sun May 22 12:23:00 EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386 Ubench CPU: 170748 Ubench MEM: 172775 Ubench AVG: 171761 Claus Guttesen wrote: As a further FYI, a variety of debugging features are still enabled by default in RELENG_6, including INVARINTS, WITNESS, and user space malloc debugging. These will remain enabled through the first snapshot from the Not very scientific but here is my ubench on a dual nocona @ 2.8 GHz and 4 GB RAM on a Dell 2850: Sched_ule: Current from July 6'th 2005: Ubench CPU: 241149 Ubench MEM: 182695 Ubench AVG: 211922 6.0 stable pr. July 12'th 2005: Ubench CPU: 243058 Ubench MEM: 186918 Ubench AVG: 214988 So slight increase in both cpu and ram in stable. SCHED_4BSD and 6.0 stable pr. July 12'th 2005: Ubench CPU: 260315 Ubench MEM: 189686 Ubench AVG: 225000 Here sched_4bsd performs approx. 5 % better on ubench. regards Claus ___ [EMAIL PROTECTED] mailing list [2]http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [3][EMAIL PROTECTED] References 1. mailto:freebsd-stable@freebsd.org 2. http://lists.freebsd.org/mailman/listinfo/freebsd-stable 3. mailto:[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: dangerous situation with shutdown process
Paul Mather [EMAIL PROTECTED] writes: Why would that necessarily be more successful? If the outstanding buffers count is not reducing between time intervals, it is most likely because there is some underlying hardware problem (e.g., a bad block). If the count still persists in staying put, it likely means whatever the hardware is doing to try and fix things (e.g., write reallocation) isn't working, and so the kernel may as well give up. So the kernel is relying on guesswork whether the buffers are flushed or not... You can enumerate the buffers and *try* to write them, but that doesn't guarantee they will be written successfully any more than observing the relative number left outstanding. That's rather nonsensical. If I write each buffer synchronously (and wait for the disk's response) this is for sure a lot more reliable than observing changes in the number of remaining buffers. I mean, where's the sense in the latter? It would be analogous to, in userspace, having to monitor write(2) continuously over a given time interval and check whether the number it returns eventually reaches zero. That's complete madness, imho. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Matthias Buelow [EMAIL PROTECTED] wrote: Oliver Fromme [EMAIL PROTECTED] writes: buffers to disk. While it is doing that, it displays the number of remaining buffers, with increasing time intervals between them. If there are still buffers left after a certain number of intervals without change, the kernel gives up. Why is it doing this? Can't it just enumerate the buffers and write them, one by one? I don't think that the boot() function in kern_shutdown.c can do that. It has got nothing to do with the syncing business itself. It can only trigger the syncing (similar to the sync(8) tool), which basically means performing a vfs_sync with flag MNT_NOWAIT for every mounted filesystem. Then it has to wait for the appropriate kernel process to do its job. See the source. I don't think there's an easy way to change that. If you see such a way, I'd suggest you code it up and use send-pr. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. Python tricks is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure wink. -- Tim Peters ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Matthias Buelow [EMAIL PROTECTED] writes: Lowell Gilbert wrote: Well, break it down a little bit. If an ATA drive properly implements the cache flush command, then none of the ongoing discussion is Are you sure this is the case? Are there sequence points in softupdates where it issues a flush request and by this guarantees fs integrity? No, you're right. I meant write completions, not cache flushes. I don't know of any drives that do one properly and not the other, but they're certainly not the same thing. I've read thru McKusick's paper in search for an answer but haven't found any. All I've read so far on mailing lists and from googling was that softupdates doesn't work if the wb-cache is enabled. On a lot of ATA drives that don't implement the spec properly. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
On Mon, 2005-07-18 at 17:14 +0200, Matthias Buelow wrote: Paul Mather [EMAIL PROTECTED] writes: Why would that necessarily be more successful? If the outstanding buffers count is not reducing between time intervals, it is most likely because there is some underlying hardware problem (e.g., a bad block). If the count still persists in staying put, it likely means whatever the hardware is doing to try and fix things (e.g., write reallocation) isn't working, and so the kernel may as well give up. So the kernel is relying on guesswork whether the buffers are flushed or not... I don't know if you are just deliberately trying to be contentious, but that is a serious misrepresentation of what is happening. Quite obviously the kernel knows whether a buffer has successfully been flushed, otherwise a count of outstanding buffers would be meaningless. (Surely you're not saying the kernel simply guesses if a buffer has been flushed in maintaining its count of outstanding buffers? What would be the point of that?) If you calm down and think about it for a little, you'll realise what you suggest to do and what is actually done amount to the same thing in practical terms. It's all very easy to say to write each buffer synchronously (and wait for the disk's response), but what do you do when the buffer *does* get stuck and won't complete (e.g., because someone removed the floppy or USB disk, or your remote ggate server disappeared, or your hard disk is going bad, etc.)? Do you just bail immediately at that point? Or do you keep retrying in the hope it will complete? In the end, it comes down to waiting a certain amount of time for drivers to do their best and then giving up. The only real question is how long you wait, and maybe whether syncer is not waiting long enough (and hence how to extend the amount of time it is willing to wait until it gives up on buffers being unflushable). I'm not sure why that is fundamentally madness. Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
cua*x naming? [Was: Re: FreeBSD 6.0-BETA1 Available]
Am Sonntag, 17. Juli 2005 21:12 CEST schrieb Robert Watson: (2) /dev/cuaa* has been renamed to /dev/cuad* I saw that cuaa got cuad and ucom0 got cuaU0. Now what is the meaning of cua? tty AFAIK is TeleTYpe... Thanks, -Harry pgp8dSThJXdRN.pgp Description: PGP signature
Re: cua*x naming? [Was: Re: FreeBSD 6.0-BETA1 Available]
On Mon, 2005-07-18 at 18:18 +0200, Emanuel Strobl wrote: Am Sonntag, 17. Juli 2005 21:12 CEST schrieb Robert Watson: (2) /dev/cuaa* has been renamed to /dev/cuad* I saw that cuaa got cuad and ucom0 got cuaU0. Now what is the meaning of cua? tty AFAIK is TeleTYpe... Call(-out) Unit Access, IIRC. -- brandon s. allbery [linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineering, carnegie mellon univ. KF8NH ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rcNG issue
On Mon, 18 Jul 2005 19:58:43 +0200 Kövesdán Gábor [EMAIL PROTECTED] wrote: Hello, I have a problem with my rcNG scripts. There are three scripts: named.sh, apache2.sh and proftpd.sh. Apache and ProFTPd require hostname resolving thus named should start firstly. The headers of my scripts are: named.sh: #!/bin/sh # # PROVIDE: named # REQUIRE: SERVERS # BEFORE: apache2 proftpd mysqld # KEYWORD: FreeBSD shutdown . /etc/rc.subr apache2.sh: #!/bin/sh # # PROVIDE: apache2 # REQUIRE: NETWORKING SERVERS named # BEFORE: DAEMON # KEYWORD: FreeBSD shutdown . /etc/rc.subr proftpd.sh: #!/bin/sh # # PROVIDE: proftpd # REQUIRE: DAEMON # BEFORE: LOGIN # KEYWORD: FreeBSD shutdown . /etc/rc.subr And when I enable all the three scripts in rc.conf, the apache hangs because it can't resolve the computer's hostname. It's really annoying, I have to manually start it after a reboot, or wait for the cronscript that checks whether it is running. What's wrong? I had similar problems these days, and I found out that rcNG seems to be only active for /etc/rc.d/ (see rc.subr(8) and rcorder(8) + files in /etc/). So put your scripts there, and it will do what you want. Thanks in advance, Gábor Kövesdán ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Best regards, Cédric Jonas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing.
On Mon, 18 Jul 2005, Pawel Malachowski wrote: On Mon, Jul 18, 2005 at 04:09:58PM -0400, Matt Juszczak wrote: Correct. IPF is unstable with our SMP (most of the time) - based 5.x boxes. VERY unstable. VERY VERY unstable. Hm, this sounds bad. What is debug.mpsafenet set to? How big is traffic? I have one SMP box with ipnat, routing some megabits (even during night it's more than 30-40Mbps) without problems, however, ipnat is used only for very small group of hosts right now. But we plan to use ipnat more heavily so it sounds a bit scary. ;) From personal experience I can repeat what Matt has stated. It seems to be related to what NIC you have. I have had crashes with fxp (Intel Pro 100MBit) and bge (Broadcom Gigabit) NICs under moderate network load. Removing ipf reduced but did not eliminate the crashes. debug.mpsafe also reduced but did not eliminate the crashes. Another person on the freebsd-amd64 list reported similar network-related crashes until he switched to em (Intel Gigabit Ethernet) NICs. Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
TinyBSD Call For Testers
Hello gentlemen, In the last saturday a new port has been added under sysutils/ category, ports/sysutils/tinybsd. TinyBSD is a tool which was meant to allow an easy way to build embedded systems based on FreeBSD. It is based on userland copying, library dependencies check/copy and kernel build. We did our best to make the embedded system creation an easy and specially fast proccess. The main (default) system generates an embedded system image which is about 20MB in size, which is a very generic approach, with a number of wired NIC support, and also the most popular wireless support (including atheros), divert, bridge, dummynet, firewall, etc; and CPU_ELAN (for soekris devices). If the generic system gets tighten up the final result can be as low as an 8MB embedded system. We are giving you this intro to ask you please to test TinyBSD out, the most that you can, and send every possible feedback regarding it. The main tinybsd goal is to make embedded systems creation a process which must be 1 - fast 2 - easy 3 - 100% functional If you can test it, we would appreciate your thoughts. If you think any of those 3 goals can't be reached for you, or could be improved, also let me know. Thanks for testing -- Atenciosamente Jean Milanez Melo FreeBSD Brasil LTDA. Fone: (31) 3281-9633 http://www.freebsdbrasil.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mpt + gvinum on 6.0-BETA (boot -v)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 15.07.2005 um 15:45 schrieb Matthias Schuendehuette: I tried 6.0-BETA on one of our FUJITSU-SIEMENS RX300 S2 servers and it seems that I have problems with the disk subsystem, even after Scotts major overhaul of the mpt drivers... I'm not able to post detailed dmesg output in the moment (IMHO there isn't anything to notice, mpt0 and mpt1 are attached without any errors) but the symtoms are: - - very slow write performace: 'dd if=/dev/zero of=/dev/da0s2 bs=512 count=32768' reports a throughput of 80 k(!)Bytes/s. Read performance is somewhat better, 'dd' reports here about 2 MB/s... better, but not what I would expect from a RAID1 with two U320 SCSI- disks (Seagate BTW). If I try to 'boot -v', the system ends up in an endless loop with the following messages: Jul 18 11:52:37 blnn204x syslogd: kernel boot file is /boot/kernel/ kernel Jul 18 11:52:37 blnn204x kernel: fset 0x00 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus:0 Jul 18 11:52:37 blnn204x kernel: TargetID0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x0200 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength0x1000 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6]08 04 12 9f 08 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63bf3000 FlagsLength=0xd1001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x00 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus:0 Jul 18 11:52:37 blnn204x kernel: TargetID0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x0200 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength0x0800 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6]08 06 4e 7b 04 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63af6000 FlagsLength=0xd1000800 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x10 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus:0 Jul 18 11:52:37 blnn204x kernel: TargetID0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x0200 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength0x4000 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6]08 06 99 7f 20 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63bc2000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab038: Addr=0x63be3000 FlagsLength=0x90001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT Jul 18 11:52:37 blnn204x kernel: CE32 0xe6bab040: Addr=0x7d745048 NxtChnO=0x0 Flgs=0x30 Len=0x10 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab048: Addr=0x63aa4000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab050: Addr=0x63be5000 FlagsLength=0xd1001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x10 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus:0 Jul 18 11:52:37 blnn204x kernel: TargetID0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x0200 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength0x0001 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6]08 04 65 1f 80 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63cef000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab038: Addr=0x63c3 FlagsLength=0x90001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT Jul 18 11:52:37 blnn204x kernel: CE32 0xe6bab040: Addr=0x7d745048 NxtChnO=0x0 Flgs=0x30 Len=0x58 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab048: Addr=0x63fb1000
rcNG issue
Hello, I have a problem with my rcNG scripts. There are three scripts: named.sh, apache2.sh and proftpd.sh. Apache and ProFTPd require hostname resolving thus named should start firstly. The headers of my scripts are: named.sh: #!/bin/sh # # PROVIDE: named # REQUIRE: SERVERS # BEFORE: apache2 proftpd mysqld # KEYWORD: FreeBSD shutdown . /etc/rc.subr apache2.sh: #!/bin/sh # # PROVIDE: apache2 # REQUIRE: NETWORKING SERVERS named # BEFORE: DAEMON # KEYWORD: FreeBSD shutdown . /etc/rc.subr proftpd.sh: #!/bin/sh # # PROVIDE: proftpd # REQUIRE: DAEMON # BEFORE: LOGIN # KEYWORD: FreeBSD shutdown . /etc/rc.subr And when I enable all the three scripts in rc.conf, the apache hangs because it can't resolve the computer's hostname. It's really annoying, I have to manually start it after a reboot, or wait for the cronscript that checks whether it is running. What's wrong? Thanks in advance, Gábor Kövesdán ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing.
For me, 5 days up time after switching from IPF to PF. Before the switch a couple of hours of uptime was the maximum. Seems like the crashes are caused by ipfilter. Still same for me :) Uptime almost 20 days now after switching to PF. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing.
On Mon, Jul 18, 2005 at 04:09:58PM -0400, Matt Juszczak wrote: Correct. IPF is unstable with our SMP (most of the time) - based 5.x boxes. VERY unstable. VERY VERY unstable. Hm, this sounds bad. What is debug.mpsafenet set to? How big is traffic? I have one SMP box with ipnat, routing some megabits (even during night it's more than 30-40Mbps) without problems, however, ipnat is used only for very small group of hosts right now. But we plan to use ipnat more heavily so it sounds a bit scary. ;) -- Paweł Małachowski ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mpt + gvinum on 6.0-BETA (dmesg)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 15.07.2005 um 15:45 schrieb Matthias Schuendehuette: I tried 6.0-BETA on one of our FUJITSU-SIEMENS RX300 S2 servers and it seems that I have problems with the disk subsystem, even after Scotts major overhaul of the mpt drivers... I'm not able to post detailed dmesg output in the moment (IMHO there isn't anything to notice, mpt0 and mpt1 are attached without any errors) but the symtoms are: - - very slow write performace: 'dd if=/dev/zero of=/dev/da0s2 bs=512 count=32768' reports a throughput of 80 k(!)Bytes/s. Read performance is somewhat better, 'dd' reports here about 2 MB/s... better, but not what I would expect from a RAID1 with two U320 SCSI- disks (Seagate BTW). [...] Here the promised 'dmesg'-output: Jul 18 11:54:41 blnn204x syslogd: kernel boot file is /boot/kernel/ kernel Jul 18 11:54:41 blnn204x kernel: Copyright (c) 1992-2005 The FreeBSD Project. Jul 18 11:54:41 blnn204x kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 18 11:54:41 blnn204x kernel: The Regents of the University of California. All rights reserved. Jul 18 11:54:41 blnn204x kernel: FreeBSD 6.0-BETA #0: Thu Jul 14 10:13:50 CEST 2005 Jul 18 11:54:41 blnn204x kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BLNN204X Jul 18 11:54:41 blnn204x kernel: ACPI APIC Table: PTLTD APIC Jul 18 11:54:41 blnn204x kernel: Timecounter i8254 frequency 1193182 Hz quality 0 Jul 18 11:54:41 blnn204x kernel: CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2800.11-MHz 686-class CPU) Jul 18 11:54:41 blnn204x kernel: Origin = GenuineIntel Id = 0xf41 Stepping = 1 Jul 18 11:54:41 blnn204x kernel: Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR, PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Jul 18 11:54:41 blnn204x kernel: Features2=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 Jul 18 11:54:41 blnn204x kernel: AMD Features=0x2010NX,LM Jul 18 11:54:41 blnn204x kernel: real memory = 2146959360 (2047 MB) Jul 18 11:54:41 blnn204x kernel: avail memory = 2096025600 (1998 MB) Jul 18 11:54:41 blnn204x kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Jul 18 11:54:41 blnn204x kernel: cpu0 (BSP): APIC ID: 0 Jul 18 11:54:41 blnn204x kernel: cpu1 (AP): APIC ID: 6 Jul 18 11:54:41 blnn204x kernel: ioapic0 Version 2.0 irqs 0-23 on motherboard Jul 18 11:54:41 blnn204x kernel: ioapic1 Version 2.0 irqs 24-47 on motherboard Jul 18 11:54:41 blnn204x kernel: ioapic2 Version 2.0 irqs 48-71 on motherboard Jul 18 11:54:41 blnn204x kernel: ioapic3 Version 2.0 irqs 72-95 on motherboard Jul 18 11:54:41 blnn204x kernel: ioapic4 Version 2.0 irqs 96-119 on motherboard Jul 18 11:54:41 blnn204x kernel: npx0: [FAST] Jul 18 11:54:41 blnn204x kernel: npx0: math processor on motherboard Jul 18 11:54:41 blnn204x kernel: npx0: INT 16 interface Jul 18 11:54:41 blnn204x kernel: acpi0: PTLTD XSDT on motherboard Jul 18 11:54:41 blnn204x kernel: acpi0: Power Button (fixed) Jul 18 11:54:41 blnn204x kernel: pci_link0: ACPI PCI Link LNKA irq 11 on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link1: ACPI PCI Link LNKB irq 9 on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link2: ACPI PCI Link LNKC irq 5 on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link3: ACPI PCI Link LNKD irq 10 on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link4: ACPI PCI Link LNKE on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link5: ACPI PCI Link LNKF on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link6: ACPI PCI Link LNKG on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link7: ACPI PCI Link LNKH irq 9 on acpi0 Jul 18 11:54:41 blnn204x kernel: Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Jul 18 11:54:41 blnn204x kernel: acpi_timer0: 24-bit timer at 3.579545MHz port 0xf008- 0xf00b on acpi0 Jul 18 11:54:41 blnn204x kernel: cpu0: ACPI CPU on acpi0 Jul 18 11:54:41 blnn204x kernel: cpu1: ACPI CPU on acpi0 Jul 18 11:54:41 blnn204x kernel: acpi_button0: Power Button on acpi0 Jul 18 11:54:41 blnn204x kernel: pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 Jul 18 11:54:41 blnn204x kernel: pci0: ACPI PCI bus on pcib0 Jul 18 11:54:41 blnn204x kernel: pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0 Jul 18 11:54:41 blnn204x kernel: pci1: ACPI PCI bus on pcib1 Jul 18 11:54:41 blnn204x kernel: pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 Jul 18 11:54:41 blnn204x kernel: pci2: ACPI PCI bus on pcib2 Jul 18 11:54:41 blnn204x kernel: mpt0: LSILogic 1030 Ultra4 Adapter port 0x3000-0x30ff mem 0xde11-0xde11,0xde10-0xde10 irq 24 at device 8.0 on pci2 Jul 18 11:54:41 blnn204x kernel: mpt0: [GIANT-LOCKED] Jul 18 11:54:41 blnn204x kernel: mpt0: MPI Version=1.2.14.0 Jul 18 11:54:41 blnn204x kernel: mpt0: Unhandled Event Notify Frame. Event 0xa. Jul 18 11:54:41 blnn204x kernel: mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE ) Jul 18 11:54:41
Re: FreeBSD -STABLE servers repeatedly crashing.
I find this messages kind of weird. Are you saying your servers only run long periods of uptime with pf and *not* with ipf? I run a server and almost never put it down. IPF performs very well, including a lot of natting for my home network. Correct. IPF is unstable with our SMP (most of the time) - based 5.x boxes. VERY unstable. VERY VERY unstable. -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Oliver Fromme wrote: Definitely not. When I compare Windows XP and FreeBSD on the same hardware (notebook with ATA disk), then Windows' shutdown process is a lot faster than FreeBSD's. In fact, when I shut it down under XP for the first time, the power was off so quickly that I thought someting must have gone wrong. But everything was OK and normal. Yes XP's shutdown time is quicker on a fresh install, but give it a few weeks or months (depending on how you use XP) and you will notice that the shutdown time increases. Right now my XP pro takes about 20 or more seconds to shutdown. I am sure this is due to the MFT under a NTFS installation, FreeBSD does not appear to have this problem over extended use, and there is no way of stopping the MTF growth problem (as far as I know) It is already irritating that FreeBSD sits there doing nothing for ~ 5 seconds before turning power off. Windows doesn't do that. (Yes I know, there's a sysctl for that, but I suspect that it's not save to modify it in FreeBSD.) Best regards Oliver -- Kind regards, Jayton Garnett email: [EMAIL PROTECTED] Main : www.uberhacker.co.uk Test server: jayton.plus.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD -STABLE servers repeatedly crashing.
On Mon, 18 Jul 2005 14:32:09 -0400 (EDT) Matt Juszczak [EMAIL PROTECTED] wrote: For me, 5 days up time after switching from IPF to PF. Before the switch a couple of hours of uptime was the maximum. Seems like the crashes are caused by ipfilter. Still same for me :) Uptime almost 20 days now after switching to PF. I find this messages kind of weird. Are you saying your servers only run long periods of uptime with pf and *not* with ipf? I run a server and almost never put it down. IPF performs very well, including a lot of natting for my home network. -- dick -- http://nagual.st/ -- PGP/GnuPG key: F86289CE ++ Running FreeBSD 4.11-stable ++ FreeBSD 5.4 + Nai tiruvantel ar vayuvantel i Valar tielyanna nu vilja ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Comment from out in left field -- On 2005/07/16, at 6:03, Kevin Oberman wrote: [...] I believe that the Windows solution to this problem is to put a really, really long delay between when the system is finished syncing and when the power is turned off. That's what I vote for. If the system has ATA on it, send a line to the console that says waiting for ATA technology drives to quit lying after the final sync, and then wait 30 seconds to cut power. This might be the best solution for FreeBSD, as well, but it will irritate people. My impression is that in this case irritation is recommended. (I'm half wondering if Microsoft and the drive manufacturer's haven't defined some hidden API for forcing the drive electronics to be truthful.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM xSeries 335 and FreeBSD 5 STABLE. SMP problem
If you unload kernel and load it again at boot manually, can 335 boot? I have one 336 with 5.4 that must use this trick to boot, otherwise it hangs after ipfw2 initialized. On the other hand, I have 3 335 installed with 5.4 running SMP smoothly. Nope, this trick doesn't work for me :-( And btw, do you have LSI Logic SCSI controller on your 335? I'll try to upgrade BIOS today, for it seems to be the only difference between my and people in the list's hardware. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM xSeries 335 and FreeBSD 5 STABLE. SMP problem
boot -v output would be useful. There's a lot of mpt errors, but I don't think this is the hang reason (as I googled, there's performance problems with RAID1 over LSI Logic in FreeBSD due to its driver, but nobody told this resulted in hang) Jul 15 17:00:51 ibm335 syslogd: kernel boot file is /boot/kernel/kernel Jul 15 17:00:51 ibm335 kernel: Copyright (c) 1992-2005 The FreeBSD Project. Jul 15 17:00:51 ibm335 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 15 17:00:51 ibm335 kernel: The Regents of the University of California. All rights reserved. Jul 15 17:00:51 ibm335 kernel: FreeBSD 5.4-STABLE #2: Thu Jul 14 14:20:40 MSD 2005 Jul 15 17:00:51 ibm335 kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP-CUSTOM Jul 15 17:00:51 ibm335 kernel: Preloaded elf kernel /boot/kernel/kernel at 0xc07f1000. Jul 15 17:00:51 ibm335 kernel: Preloaded elf module /boot/modules/acpi.ko at 0xc07f11cc. Jul 15 17:00:51 ibm335 kernel: Calibrating clock(s) ... i8254 clock: 1193191 Hz Jul 15 17:00:51 ibm335 kernel: CLK_USE_I8254_CALIBRATION not specified - using default frequency Jul 15 17:00:51 ibm335 kernel: Timecounter i8254 frequency 1193182 Hz quality 0 Jul 15 17:00:51 ibm335 kernel: Calibrating TSC clock ... TSC clock: 2392253816 Hz Jul 15 17:00:51 ibm335 kernel: CPU: Intel(R) XEON(TM) CPU 2.40GHz (2392.25-MHz 686-class CPU) Jul 15 17:00:51 ibm335 kernel: Origin = GenuineIntel Id = 0xf24 Stepping = 4 Jul 15 17:00:51 ibm335 kernel: Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM Jul 15 17:00:51 ibm335 kernel: real memory = 536850432 (511 MB) Jul 15 17:00:51 ibm335 kernel: Physical memory chunk(s): Jul 15 17:00:51 ibm335 kernel: 0x1000 - 0x0009cfff, 638976 bytes (156 pages) Jul 15 17:00:51 ibm335 kernel: 0x0010 - 0x003f, 3145728 bytes (768 pages) Jul 15 17:00:51 ibm335 kernel: 0x00828000 - 0x1f6cafff, 518664192 bytes (126627 pages) Jul 15 17:00:51 ibm335 kernel: avail memory = 519860224 (495 MB) Jul 15 17:00:51 ibm335 kernel: bios32: Found BIOS32 Service Directory header at 0xc00fd7d0 Jul 15 17:00:51 ibm335 kernel: bios32: Entry = 0xfd7e1 (c00fd7e1) Rev = 0 Len = 1 Jul 15 17:00:51 ibm335 kernel: pcibios: PCI BIOS entry at 0xf+0xd81c Jul 15 17:00:51 ibm335 kernel: pnpbios: Found PnP BIOS data at 0xc00fdf90 Jul 15 17:00:51 ibm335 kernel: pnpbios: Entry = f:5225 Rev = 1.0 Jul 15 17:00:51 ibm335 kernel: Other BIOS signatures found: Jul 15 17:00:51 ibm335 kernel: mem: memory Jul 15 17:00:51 ibm335 kernel: Pentium Pro MTRR support enabled Jul 15 17:00:51 ibm335 kernel: io: I/O Jul 15 17:00:51 ibm335 kernel: null: null device, zero device Jul 15 17:00:51 ibm335 kernel: random: entropy source, Software, Yarrow Jul 15 17:00:51 ibm335 kernel: npx0: [FAST] Jul 15 17:00:51 ibm335 kernel: npx0: math processor on motherboard Jul 15 17:00:51 ibm335 kernel: npx0: INT 16 interface Jul 15 17:00:51 ibm335 kernel: acpi0: IBM SERONYXP on motherboard Jul 15 17:00:51 ibm335 kernel: acpi0: [MPSAFE] Jul 15 17:00:51 ibm335 kernel: pci_open(1): mode 1 addr port (0x0cf8) is 0x80007890 Jul 15 17:00:51 ibm335 kernel: pci_open(1a): mode1res=0x8000 (0x8000) Jul 15 17:00:51 ibm335 kernel: pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=00121166) Jul 15 17:00:51 ibm335 kernel: pcibios: BIOS version 2.10 Jul 15 17:00:51 ibm335 kernel: AcpiOsDerivePciId: bus 0 dev 15 func 2 Jul 15 17:00:51 ibm335 kernel: acpi0: Power Button (fixed) Jul 15 17:00:51 ibm335 kernel: AcpiOsDerivePciId: bus 0 dev 0 func 0 Jul 15 17:00:51 ibm335 kernel: AcpiOsDerivePciId: bus 0 dev 17 func 0 Jul 15 17:00:51 ibm335 kernel: AcpiOsDerivePciId: bus 0 dev 17 func 2 Jul 15 17:00:51 ibm335 kernel: ACPI timer: 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 - 0 Jul 15 17:00:51 ibm335 kernel: Timecounter ACPI-safe frequency 3579545 Hz quality 1000 Jul 15 17:00:51 ibm335 kernel: acpi_timer0: 24-bit timer at 3.579545MHz port 0x488-0x48b on acpi0 Jul 15 17:00:51 ibm335 kernel: unknown: not probed (disabled) Jul 15 17:00:51 ibm335 last message repeated 27 times Jul 15 17:00:51 ibm335 kernel: cpu0: ACPI CPU on acpi0 Jul 15 17:00:51 ibm335 kernel: pcib0: ACPI Host-PCI bridge on acpi0 Jul 15 17:00:51 ibm335 kernel: ACPI PCI link initial configuration: Jul 15 17:00:51 ibm335 kernel: \LP0A irq 0: [10] 10+ low,level,sharable 0.1.0 Jul 15 17:00:51 ibm335 kernel: \LPUS irq 0: [11] 11+ low,level,sharable 0.15.0 Jul 15 17:00:51 ibm335 kernel: pci0: ACPI PCI bus on pcib0 Jul 15 17:00:51 ibm335 kernel: pci0: physical bus=0 Jul 15 17:00:51 ibm335 kernel: found- vendor=0x1166, dev=0x0012, revid=0x13 Jul 15 17:00:51 ibm335 kernel: bus=0, slot=0, func=0 Jul 15 17:00:51 ibm335 kernel: class=06-00-00, hdrtype=0x00, mfdev=1 Jul 15 17:00:51 ibm335 kernel: cmdreg=0x, statreg=0x, cachelnsz=16 (dwords) Jul 15 17:00:51 ibm335 kernel: lattimer=0x00 (0 ns), mingnt=0x00
