Re: PAE does not give any ram increase, why?
Artem Kuchin wrote: Hello! I've upgraded one of my servers today. Now it is Asus P5p800-VM Pentium D 3.0Ghz 4GB RAM (4x1 GB) 3WARE raid5 FreebSD 6.2 cvsed today compiled from sources. after that i decided to try PAE. It runs just fine but when i compare available memory with and without pae i do not see any difference. At kernel boot with PAE it says: pr 21 18:01:30 osiris kernel: ACPI APIC Table: Apr 21 18:01:30 osiris kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Apr 21 18:01:30 osiris kernel: CPU: Intel(R) Pentium(R) D CPU 3.00GHz (3000.33-MHz 686-class CPU) Apr 21 18:01:30 osiris kernel: Origin = "GenuineIntel" Id = 0xf64 Stepping = 4 Apr 21 18:01:30 osiris kernel: Features=0xbfebfbff Apr 21 18:01:30 osiris kernel: Features2=0xe49d,> Apr 21 18:01:30 osiris kernel: AMD Features=0x2000 Apr 21 18:01:30 osiris kernel: AMD Features2=0x1 Apr 21 18:01:30 osiris kernel: Cores per package: 2 Apr 21 18:01:30 osiris kernel: real memory = 4017881088 (3831 MB) Apr 21 18:01:30 osiris kernel: avail memory = 3933429760 (3751 MB) The real and avail memory sizes are the same w/o PAE. Then i do sysctl -a | grep hw | grep mem and i always see hw.physmem: 4012244992 hw.usermem: 3861307392 hw.realmem: 4017881088 hw.pci.host_mem_start: 2147483648 the number do not change with or without PAE Maybe i look in the wrong place? I'm not going to waste my time explaining for the hundredth time how the x86 memory layout works. If you want to recover the missing 256MB, go look in your BIOS for an option about memory hole remapping. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PAE does not give any ram increase, why?
On 4/22/07, Artem Kuchin <[EMAIL PROTECTED]> wrote: Andrew Pantyukhin wrote: > On 4/21/07, Artem Kuchin <[EMAIL PROTECTED]> wrote: >> Hello! >> >> I've upgraded one of my servers today. >> Now it is >> Asus P5p800-VM >> Pentium D 3.0Ghz >> 4GB RAM (4x1 GB) >> 3WARE raid5 >> >> FreebSD 6.2 cvsed today compiled from sources. >> >> after that i decided to try PAE. It runs just fine but >> when i compare available memory with and without >> pae i do not see any difference. >> >> At kernel boot with PAE it says: >> >> pr 21 18:01:30 osiris kernel: ACPI APIC Table: >> Apr 21 18:01:30 osiris kernel: Timecounter "i8254" frequency 1193182 >> Hz quality 0 >> Apr 21 18:01:30 osiris kernel: CPU: Intel(R) Pentium(R) D CPU >> 3.00GHz (3000.33-MHz 686-class CPU) Apr 21 18:01:30 osiris kernel: >> Origin = "GenuineIntel" Id = 0xf64 Stepping = 4 >> Apr 21 18:01:30 osiris kernel: >> Features=0xbfebfbff> Apr 21 18:01:30 osiris kernel: >> Features2=0xe49d,> >> Apr 21 18:01:30 osiris kernel: AMD Features=0x2000 >> Apr 21 18:01:30 osiris kernel: AMD Features2=0x1 >> Apr 21 18:01:30 osiris kernel: Cores per package: 2 >> Apr 21 18:01:30 osiris kernel: real memory = 4017881088 (3831 MB) >> Apr 21 18:01:30 osiris kernel: avail memory = 3933429760 (3751 MB) >> >> The real and avail memory sizes are the same w/o PAE. >> >> Then i do >> sysctl -a | grep hw | grep mem >> >> and i always see >> hw.physmem: 4012244992 >> hw.usermem: 3861307392 >> hw.realmem: 4017881088 >> hw.pci.host_mem_start: 2147483648 >> >> the number do not change with or without PAE >> >> Maybe i look in the wrong place? > > What number do you expect to see? 8Gb? I expect to see DIFFERENCE (in particular INCREASE) in amount of memory with PAE comparing to kernel w/o PAE. And 4 GB = 1024*4 MB = 1024*1024*4 KB = = 1024*1024*1024*4=4294967296 So, where is my 277086208 bytes? (ieven is built-in video eats 128MB for AGP aperture then still whene is my another almost 120MB?) Oh, I see. This is what I get on my laptop running 7.x/amd64: usable memory = 1998807040 (1906 MB) avail memory = 1928650752 (1839 MB) It has 2Gb RAM. Your trouble is a FAQ, search the lists for a bunch of complete answers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PAE does not give any ram increase, why?
Andrew Pantyukhin wrote: On 4/21/07, Artem Kuchin <[EMAIL PROTECTED]> wrote: Hello! I've upgraded one of my servers today. Now it is Asus P5p800-VM Pentium D 3.0Ghz 4GB RAM (4x1 GB) 3WARE raid5 FreebSD 6.2 cvsed today compiled from sources. after that i decided to try PAE. It runs just fine but when i compare available memory with and without pae i do not see any difference. At kernel boot with PAE it says: pr 21 18:01:30 osiris kernel: ACPI APIC Table: Apr 21 18:01:30 osiris kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Apr 21 18:01:30 osiris kernel: CPU: Intel(R) Pentium(R) D CPU 3.00GHz (3000.33-MHz 686-class CPU) Apr 21 18:01:30 osiris kernel: Origin = "GenuineIntel" Id = 0xf64 Stepping = 4 Apr 21 18:01:30 osiris kernel: Features=0xbfebfbff,> Apr 21 18:01:30 osiris kernel: AMD Features=0x2000 Apr 21 18:01:30 osiris kernel: AMD Features2=0x1 Apr 21 18:01:30 osiris kernel: Cores per package: 2 Apr 21 18:01:30 osiris kernel: real memory = 4017881088 (3831 MB) Apr 21 18:01:30 osiris kernel: avail memory = 3933429760 (3751 MB) The real and avail memory sizes are the same w/o PAE. Then i do sysctl -a | grep hw | grep mem and i always see hw.physmem: 4012244992 hw.usermem: 3861307392 hw.realmem: 4017881088 hw.pci.host_mem_start: 2147483648 the number do not change with or without PAE Maybe i look in the wrong place? What number do you expect to see? 8Gb? I expect to see DIFFERENCE (in particular INCREASE) in amount of memory with PAE comparing to kernel w/o PAE. And 4 GB = 1024*4 MB = 1024*1024*4 KB = = 1024*1024*1024*4=4294967296 So, where is my 277086208 bytes? (ieven is built-in video eats 128MB for AGP aperture then still whene is my another almost 120MB?) -- Regards, Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PAE does not give any ram increase, why?
On 4/21/07, Artem Kuchin <[EMAIL PROTECTED]> wrote: Hello! I've upgraded one of my servers today. Now it is Asus P5p800-VM Pentium D 3.0Ghz 4GB RAM (4x1 GB) 3WARE raid5 FreebSD 6.2 cvsed today compiled from sources. after that i decided to try PAE. It runs just fine but when i compare available memory with and without pae i do not see any difference. At kernel boot with PAE it says: pr 21 18:01:30 osiris kernel: ACPI APIC Table: Apr 21 18:01:30 osiris kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Apr 21 18:01:30 osiris kernel: CPU: Intel(R) Pentium(R) D CPU 3.00GHz (3000.33-MHz 686-class CPU) Apr 21 18:01:30 osiris kernel: Origin = "GenuineIntel" Id = 0xf64 Stepping = 4 Apr 21 18:01:30 osiris kernel: Features=0xbfebfbff,> Apr 21 18:01:30 osiris kernel: AMD Features=0x2000 Apr 21 18:01:30 osiris kernel: AMD Features2=0x1 Apr 21 18:01:30 osiris kernel: Cores per package: 2 Apr 21 18:01:30 osiris kernel: real memory = 4017881088 (3831 MB) Apr 21 18:01:30 osiris kernel: avail memory = 3933429760 (3751 MB) The real and avail memory sizes are the same w/o PAE. Then i do sysctl -a | grep hw | grep mem and i always see hw.physmem: 4012244992 hw.usermem: 3861307392 hw.realmem: 4017881088 hw.pci.host_mem_start: 2147483648 the number do not change with or without PAE Maybe i look in the wrong place? What number do you expect to see? 8Gb? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PAE does not give any ram increase, why?
Martin Nilsson wrote: Artem Kuchin wrote: Apr 21 18:01:30 osiris kernel: CPU: Intel(R) Pentium(R) D CPU 3.00GHz (3000.33-MHz 686-class CPU) Why bother with PAE on a CPU that is 64-bit capable and can run the amd64 version of FreeBSD 6.2? Do you know a RELIABLE way to migrade a production server with a bunch of jails and a dozen of webserver from x86 to amd64 without going into full system reinstall from scratch? If yes, then, please, give the procedure and will do it. -- Regards, Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sio0: port may not be enabled
At 12:42 PM 4/21/2007, Marcel Moolenaar wrote: ports are swapped but this is probably because I swap them in bios, but this is ok. Serial is working and now I can start working on the main problem :) So it's not acpi problem, but instead problem with sio? So it appears. I have been using uart by default on a number of boards in RELENG_6 for a while now, I have had far better luck with it than sio. Especially for dialup applications, sio always seems to have overflow issues as opposed to uart ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sio0: port may not be enabled
On Apr 21, 2007, at 1:07 AM, Stefan Lambrev wrote: Some systems apparently tie the serial port to ACPI functionality in a different way. For example, I have a couple boxes which have sio0 attached to acpi0 that work fine. In some other cases, I have ones which result in a non-working serial port unless I disable ACPI (thus sio0 shows up as being attached to isa0). Could you try uart(4) instead. It seems quite excessive to have to disable ACPI just to get a serial port working. I'd like to know if this is related to the sio(4) driver or something else. This did the trick: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ports are swapped but this is probably because I swap them in bios, but this is ok. Serial is working and now I can start working on the main problem :) So it's not acpi problem, but instead problem with sio? So it appears. -- Marcel Moolenaar [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: HEADS UP: Recompile milters after sendmail 8.14 upgrade
> For those of us with RELENG_[456] servers do we just need to buildworld and > installworld? Yes, after the new code is committed (I'll post at that time). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PAE does not give any ram increase, why?
Artem Kuchin wrote: Apr 21 18:01:30 osiris kernel: CPU: Intel(R) Pentium(R) D CPU 3.00GHz (3000.33-MHz 686-class CPU) Why bother with PAE on a CPU that is 64-bit capable and can run the amd64 version of FreeBSD 6.2? /Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PAE does not give any ram increase, why?
Hello! I've upgraded one of my servers today. Now it is Asus P5p800-VM Pentium D 3.0Ghz 4GB RAM (4x1 GB) 3WARE raid5 FreebSD 6.2 cvsed today compiled from sources. after that i decided to try PAE. It runs just fine but when i compare available memory with and without pae i do not see any difference. At kernel boot with PAE it says: pr 21 18:01:30 osiris kernel: ACPI APIC Table: Apr 21 18:01:30 osiris kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Apr 21 18:01:30 osiris kernel: CPU: Intel(R) Pentium(R) D CPU 3.00GHz (3000.33-MHz 686-class CPU) Apr 21 18:01:30 osiris kernel: Origin = "GenuineIntel" Id = 0xf64 Stepping = 4 Apr 21 18:01:30 osiris kernel: Features=0xbfebfbff Apr 21 18:01:30 osiris kernel: Features2=0xe49d,> Apr 21 18:01:30 osiris kernel: AMD Features=0x2000 Apr 21 18:01:30 osiris kernel: AMD Features2=0x1 Apr 21 18:01:30 osiris kernel: Cores per package: 2 Apr 21 18:01:30 osiris kernel: real memory = 4017881088 (3831 MB) Apr 21 18:01:30 osiris kernel: avail memory = 3933429760 (3751 MB) The real and avail memory sizes are the same w/o PAE. Then i do sysctl -a | grep hw | grep mem and i always see hw.physmem: 4012244992 hw.usermem: 3861307392 hw.realmem: 4017881088 hw.pci.host_mem_start: 2147483648 the number do not change with or without PAE Maybe i look in the wrong place? -- Regards, Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [kde-freebsd] problem hal - k3b ?
On Friday 20 April 2007 01:05:17 Michael Nottebrock wrote: > I forwarded my mail to gnome@ (the HAL maintainers) after sending it and > Joe Marcus Clarke from gnome@ had this to say on the issue: > > --- snip > > This should have been fixed a while ago by jylefort when he set the > default device for ATAPI access to be the ATAPICAM device (as opposed to > the ATA device). Assuming you have not undone that change, and are > running the latest version of HAL, these panics should not be occurring. > > Even still, you're right that these are not HAL bugs, but rather an > issue in the kernel. I use nautilus-cd-burner to burn CDs in GNOME, and > I have never had such a panic on 6-STABLE. n-c-b uses cdrecord, cdrao, > and dvd-utils under the covers to do the actual device work. Not sure > what k3b is using, but maybe it diddles something it shouldn't. > > Joe > > --- snip > > Beni, Robert, Ganbold, are you all in fact running the latest version of > the hal port and do you all have atapicam enabled in your kernel? If not, > making sure of both might help avoiding the problem. I'm having both # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering and # scsi-emulatie voor atatpi-cd device atapicam in my kernel. My version of hal : [EMAIL PROTECTED] ~]$ hald --version HAL package version: 0.5.8 [EMAIL PROTECTED] ~]$ Thanks Adriaan for looking into this ! Beni. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [kde-freebsd] problem hal - k3b ?
On Friday 20 April 2007 03:55:56 Ganbold wrote: > Michael Nottebrock wrote: > > I forwarded my mail to gnome@ (the HAL maintainers) after sending it and > > Joe Marcus Clarke from gnome@ had this to say on the issue: > > > > --- snip > > > > This should have been fixed a while ago by jylefort when he set the > > default device for ATAPI access to be the ATAPICAM device (as opposed to > > the ATA device). Assuming you have not undone that change, and are > > running the latest version of HAL, these panics should not be occurring. > > > > Even still, you're right that these are not HAL bugs, but rather an > > issue in the kernel. I use nautilus-cd-burner to burn CDs in GNOME, and > > I have never had such a panic on 6-STABLE. n-c-b uses cdrecord, cdrao, > > and dvd-utils under the covers to do the actual device work. Not sure > > what k3b is using, but maybe it diddles something it shouldn't. > > > > Joe > > > > --- snip > > > > Beni, Robert, Ganbold, are you all in fact running the latest version of > > the hal port and do you all have atapicam enabled in your kernel? If not, > > making sure of both might help avoiding the problem. > > I see. I know I have updated my system last Saturday (14th April 2007) and > I think I updated both hal and kdelibs ports. I have atapicam enabled in > kernel. > Let me double check it this weekend and I will let you know. > > thanks, > > Ganbold > > > > > > > Subject: > > Re: Fwd: Re: [kde-freebsd] problem hal - k3b ? > > From: > > Joe Marcus Clarke <[EMAIL PROTECTED]> > > Date: > > Thu, 19 Apr 2007 12:49:26 -0400 > > To: > > Michael Nottebrock <[EMAIL PROTECTED]> > > > > To: > > Michael Nottebrock <[EMAIL PROTECTED]> > > CC: > > [EMAIL PROTECTED] > > > > Michael Nottebrock wrote: > >> I forgot to cc gnome@ on my reply. I don't think this is a HAL bug, but > >> just FYI. > >> > >> > >> > >> > >> > >> Subject: > >> Re: [kde-freebsd] problem hal - k3b ? > >> From: > >> Michael Nottebrock <[EMAIL PROTECTED]> > >> Date: > >> Thu, 19 Apr 2007 18:12:46 +0200 > >> To: > >> [EMAIL PROTECTED] > >> > >> To: > >> [EMAIL PROTECTED] > >> CC: > >> Beni <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], > >> [EMAIL PROTECTED] > >> > >> On Wednesday, 18. April 2007, Beni wrote: > >>> Hi List, > >>> > >>> I think I have a problem with hal(d) and k3b (version 1.0 from ports) : > >>> my whole system freezes when starting up k3b. I get the splash screen > >>> and then it all stops and a ctrl-alt-del is the only way out. > >> > >> Other people have reported kernel panics. It looks to me like k3b's > >> device probing and hald's device probing at the same time manages to > >> tickle a bug in ata(4). > >> > >> Ref: > >> http://lists.freebsd.org/pipermail/freebsd-current/2007-April/070753.htm > >>l > >> http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034486.html > >> > >> I'm afraid a true kernel hacker will have to inconvenince themselves > >> with running k3b and hal in order to have this one fixed. FWIW, I > >> haven't seen in happening on 5.5. > > > > This should have been fixed a while ago by jylefort when he set the > > default device for ATAPI access to be the ATAPICAM device (as opposed to > > the ATA device). Assuming you have not undone that change, and are > > running the latest version of HAL, these panics should not be occurring. > > > > Even still, you're right that these are not HAL bugs, but rather an > > issue in the kernel. I use nautilus-cd-burner to burn CDs in GNOME, and > > I have never had such a panic on 6-STABLE. n-c-b uses cdrecord, cdrao, > > and dvd-utils under the covers to do the actual device work. Not sure > > what k3b is using, but maybe it diddles something it shouldn't. > > > > Joe Could it all be related to this : http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034553.html and the "solution" from Shane Bell in http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034602.html : "I believe the culprit is somewhere in a recent MFC to atapi-cam.c (rev 1.42.2.3) reverting to rev 1.42.2.2 fixes both the k3b system hangs and "INQUIRY ILLEGAL REQUEST" errors here." Beni. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01
On Fri, 20 Apr 2007 09:27 pm Andrei V. Lavreniyuk wrote: > > Adding to my report: > > > Test 1: > > To start k3b with a disk in the device of reading/record. A start takes a > place normally. > > Test 2: > > To start k3b without a disk in the device of reading/record. At a start the > k3b system hangs up and overloaded. > > > > PS: My pkg_list attached. > > > > Best regards, Andrei V. Lavreniyuk. I believe the culprit is somewhere in a recent MFC to atapi-cam.c (rev 1.42.2.3) reverting to rev 1.42.2.2 fixes both the k3b system hangs and "INQUIRY ILLEGAL REQUEST" errors here. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sio0: port may not be enabled
Marcel Moolenaar wrote: On Apr 20, 2007, at 8:23 AM, Jeremy Chadwick wrote: Look closely at the dmesg line, note what device sio0 is claiming to be associated with (acpi0, not isa0): sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 This is one of the drawbacks to using ACPI. Could you try uart(4) instead. It seems quite excessive to have to disable ACPI just to get a serial port working. I'd like to know if this is related to the sio(4) driver or something else. Just a note that I get exactly the same issues with my BIOS/ACPI but *my serial port works*. I have not needed to disable ACPI nor to use uart(4). The sio0 line has an IRQ associated with it (4) and I think if there were really a problem there would be no IRQ here. IIRC, the issue is something to do with ACPI presenting the serial ports backwards wrt the BIOS. I know I got concerned about this when I first encountered it, and tried stuff to swap the two ports I have over, but nothing I did made the initial "ACPI probed irqs" error go away so I just tried the serial port and it worked. --Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2-RELEASE does not use second CPU?
+1 i'm using IPSec with out such limitations ... fix it. than we will continue conversation about your CPU troubles 2007/4/20, Kris Kennaway <[EMAIL PROTECTED]>: - Скрыть цитируемый текст - On Fri, Apr 20, 2007 at 12:08:57PM -0700, Kevin Oberman wrote: > > Date: Fri, 20 Apr 2007 22:54:52 +0400 > > From: "Alexey Karagodov" <[EMAIL PROTECTED]> > > Sender: [EMAIL PROTECTED] > > > > and what is this, i mean why: > > WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant > > WARNING: MPSAFE network stack disabled, expect reduced performance. > > I thought it was pretty clear. > > ipsec is not multi-processor safe and requires the use of GIANT. If you > have IPSEC in your kernel the network stack will also be giant locked > which will cut performance. Yep, google for extensive discussion (hint: FAST_IPSEC) Kris 2007/4/19, Alex Povolotsky <[EMAIL PROTECTED]>: Hello! On the Pentium-D box, kernel detects both CPUs, but it seems like scheduler use only one. (from dmesg) Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE-p3 #2: Thu Apr 19 00:19:54 MSD 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/P4D WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2808.41-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf64 Stepping = 4 Features=0xbfebfbff Features2=0xe49d,> AMD Features=0x2010 AMD Features2=0x1 Logical CPUs per core: 2 real memory = 1046757376 (998 MB) avail memory = 1015095296 (968 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 SMP: AP CPU #1 Launched! (from top) last pid: 12408; load averages: 4.99, 4.91, 4.08up 0+01:08:02 19:26:23 265 processes: 8 running, 256 sleeping, 1 zombie CPU states: 35.0% user, 0.0% nice, 14.1% system, 0.9% interrupt, 50.0% idle Mem: 267M Active, 503M Inact, 171M Wired, 29M Cache, 109M Buf, 1636K Free Swap: 2006M Total, 2006M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1399125 1 1090 4684K 2808K RUN0 11:20 18.85% qmgr 1819300 1 40 33552K 30824K select 0 8:58 13.57% perl5.8.8 1821300 1 40 33364K 30644K select 0 9:15 6.05% perl5.8.8 12398125 1 40 3588K 2524K select 0 0:00 2.00% cleanup 1394 root1 1040 3444K 1596K RUN0 1:58 1.66% master 10601125 1 970 3580K 1728K select 0 0:18 0.83% trivial-rewri 10051125 1 970 4536K 2688K RUN0 0:13 0.63% scache All processes runs on CPU0, and I did not see less than 50% idle cpu. What can be wrong? Alex. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[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: sio0: port may not be enabled
On Sat, 21 Apr 2007, Stefan Lambrev wrote: [..] > This did the trick: > > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0 > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > > ports are swapped but this is probably because I swap them in bios, but > this is ok. FWIW: Not swapped; these are the standard ports & irqs for "com1 & com2" Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sio0: port may not be enabled
Hello, Marcel Moolenaar wrote: On Apr 20, 2007, at 8:23 AM, Jeremy Chadwick wrote: Look closely at the dmesg line, note what device sio0 is claiming to be associated with (acpi0, not isa0): sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 This is one of the drawbacks to using ACPI. This is not a drawback. It's partly why ACPI was designed and implemented: to describe legacy hardware. Some systems apparently tie the serial port to ACPI functionality in a different way. For example, I have a couple boxes which have sio0 attached to acpi0 that work fine. In some other cases, I have ones which result in a non-working serial port unless I disable ACPI (thus sio0 shows up as being attached to isa0). Could you try uart(4) instead. It seems quite excessive to have to disable ACPI just to get a serial port working. I'd like to know if this is related to the sio(4) driver or something else. This did the trick: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ports are swapped but this is probably because I swap them in bios, but this is ok. Serial is working and now I can start working on the main problem :) So it's not acpi problem, but instead problem with sio? Thank you very much for your help! Thanks, --Marcel Moolenaar [EMAIL PROTECTED] -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Recompile milters after sendmail 8.14 upgrade
At 12:21 AM 4/20/2007, Gregory Shapiro wrote: sendmail has been updated from version 8.13.8 to 8.14.1 in the HEAD and RELENG_[456] branches. This upgrade includes a new libmilter library which requires all dynamically linked milters to be recompiled (no source code changes are required). Unfortunately, this problem (the need to recompile filters) was found after the MFC. The release engineering team has asked for this notice instead of doing a full backout of sendmail 8.14 in the RELENG_[456] branches. I'm sorry for the adverse effects from the change and will be more careful with future sendmail commits. For those of us with RELENG_[456] servers do we just need to buildworld and installworld? -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
