Re: Intel I440GX+
Roberto de Iriarte wrote: > > Scott Likens wrote: > > >On Thu, 2003-11-06 at 03:27, Tom wrote: > > > > > >>On Thu, 6 Nov 2003, Scott Likens wrote: > >> > >>... > >> > >> > >>>Onboard SCSI, 1gig of ECC, dual P2-450's. Never had this problem > >>>before. > >>> > >>> > >> I hope you are using P3s, or Xeon CPUs not P2s, since P2s are not able > >>to cache memory above 512MB, which means that things will be real slow. > >> > >> > > > >No, Dual P2 Xeons. > > > > > > > Hmmm ? Are you sure ? I own an L440GX+ and Xeon's do not fit on it. You > might have either > an MS440GX or a C440GX, the former being a workstation board (with AGP), > the later an entry level server board > if there are PII Xeon CPU's on it. Only first PIIs had L2 cache which was unable to store data located beyond 512Mb memory boundary (233-300MHz, Klamath), and some of them even didn't support ECC for L2 cache. All the next PIIs (333-450MHz, Deschutes) had L2 cache with ECC, capable of all 4Gb. So PIIs are not so bad as some people may think. Besides, L2 cache of PIIXeons and some PIIIXeons (Drake & Tanner) is slow because it is off-core, regardless of running at full core speed. --- Regards, Rhett Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi-cd + GEOM
Sascha Holzleiter wrote: > > On Thu, 2003-10-02 at 15:54, Poul-Henning Kamp wrote: > > I wouldn't think the drive take 60-90 seconds to figure out there is > > no disk, but I'm not a scsi-specialist... > > Seems like it does, if there is a disc present or the tray is open there > is no delay only with tray closed and no disc inserted. > Maybe this is only an issue with this drive model or at least my > drive... > The same symptoms are for PX-32TSi, though I doubt there is something wrong with GEOM, because it happens on 4.7 as well... --- Regards, Rhett Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Way Down [The Line] (was: 5.2-RELEASE TODO)
Dan Nelson wrote: > In the last episode (Sep 29), Wilko Bulte said: > > On Mon, Sep 29, 2003 at 12:19:30PM -0700, Marcel Moolenaar wrote: > > > I also mentioned recently (in the last couple of days) that we > > > should worry more about sparc64 than alpha. Simply because I think > > > alpha is on it's way down and should already be a tier 2 platform > > > and sparc64 is still on its way up ... sort of. > > > > In my book sparc64 is also with one foot in the grave. As is Sun > > itself. > > Fujitsu makes sparc-compatible CPUs, too, so it'll be harder to kill > the entire architecture like HP did with the Alpha. Alpha was buried by DEC itself, with a little help from Compaq. Vague marketing policy and the way they supported OEMs led to the disaster. Samsung tried to change something, but it was too late. Besides, it was hard to promote 21264 without an adequate chipset: AMD-751 wasn't able to supply neccessary memory bandwidth, DEC Tsunami and Typhoon were, but Tsunami was offered to OEMs by Compaq for over a thousand USD per set... Unfortunately, AMD-761 appeared too late to help Alpha in its final struggle. HP has only confirmed the lethal issue, thus ceasing this agony. But Alpha will always live in our hearts :( --- Regards, Rhett Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: threading problems
Oh yes, user threading doesn't support multiple CPUs... Thanks for pointing me. Both libkse and libthr work with that code snippet, but Viewperf when linked against any of them locks my machine pretty deadly. With Linuxthreads it just segfaults ;) --- Regards, Rhett Dan Nelson wrote: > > In the last episode (Sep 01), RMH said: > > Hello gentlemen, > > > > I seem to have threading problems with 5.1-RELEASE. Every time I run > > a multithreaded application (linked against libc_r) on a SMP system, > > I get only 1 CPU loaded at any moment given. I tried different > > Correct. libc_r is a userland threading library, which means that all > threads run as a single plain process. Linuxthreads forks a new > process for each thread. Try linking with -lkse or -lthr; both of > these threading libraries allow multiple threads to run simultaneously > on multiple CPUs. > > -- > Dan Nelson > [EMAIL PROTECTED] Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
threading problems
Hello gentlemen, I seem to have threading problems with 5.1-RELEASE. Every time I run a multithreaded application (linked against libc_r) on a SMP system, I get only 1 CPU loaded at any moment given. I tried different software, including Viewperf, but results remain the same. When linked against Linuxthreads, some applications work excellent, some segfault. Here is some kind of a simple multithreaded program for a 2-way SMP system that writes zeros to a memory array as fast as possible; it runs fine with Linuxthreads or directly under Linux. # gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -pthread # ./smp 4Gb per pass mode INTEGER | WRITING 8 Kb block: 1351 Mb/s res0: 674 res1: 677 # gcc -O2 -fomit-frame-pointer -march=i686 -o smp2 smp.c -L/usr/local/lib -llthread # ./smp2 4Gb per pass mode INTEGER | WRITING 8 Kb block: 2697 Mb/s res0: 1349 res1: 1348 --- Regards, Rhett Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ smp.c Description: smp.c ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SMP & CPU_SUSP_HLT
Hello gentlemen, it seems CPU_SUSP_HLT does nothing for SMP kernels. i386/i386/machdep.c: #ifdef SMP static int cpu_idle_hlt = 0; #else static int cpu_idle_hlt = 1; #endif It's noted that when enabled it will result in about 4.2% loss in performance while doing buildworld. I haven't checked with that, but I tested single-threaded applications to suffer for about 2%, what shouldn't be a big difference. Beyond power consumption, suspend on HLT may solve some overheating issues common for multiprocessor systems. At least, it does so in my case. I suggest to remove #ifdef SMP, and place a warning into NOTES. Let people decide. --- Regards, Rhett Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
strange SCSI problem
Hello gentlemen, I've observed a very strange SCSI trouble never seen before. It happened suddenly, under very low system load and disk activity; though it didn't lead to any damage or data loss, but I'm curious what could be a cause. Visually, it appeared like a delay in disk access but at the same time high SCSI bus activity took place, and lasted about for a minute. SCSI controller is a dual-channel UWSCSI AIC-7895, failed HDD is an old IBM UltraStar XP (DFHS) hanging on channel A: ahc0: port 0xe400-0xe4ff mem 0xfebfe000-0xfebfefff irq 11 at device 14.0 on pci0 aic7895C: Ultra Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0xe800-0xe8ff mem 0xfebff000-0xfebf irq 11 at device 14.1 on pci0 aic7895C: Ultra Wide Channel B, SCSI Id=7, 32/253 SCBs da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 2150MB (4404489 512 byte sectors: 255H 63S/T 274C) Full output from stderr is attached. Also I'm sure there was no power failure. It appeared about a week ago and I didn't pay much attention to, but today it happened again (though symptoms were a little different), with the same drive... --- Regards, Rhett (da0:ahc0:0:0:0): SCB 0x17 - timed out ahc0: Dumping Card State in Data-out phase, at SEQADDR 0x7d ACCUM = 0x0, SINDEX = 0x17, DINDEX = 0x52, ARG_2 = 0xff HCNT = 0xe0 SCBPTR = 0x10 SCSIPHASE[0x1f] SCSIBUSL[0x0] LASTPHASE[0x0] SCSISEQ[0x12] SBLKCTL[0x2] SEQCTL[0x10] SEQ_FLAGS[0x20] SSTAT0[0x0] SSTAT1[0x2] SSTAT2[0x10] SSTAT3[0x0] SIMODE0[0x0] SIMODE1[0xac] SXFRCTL0[0x80] DFCNTRL[0x7c] DFSTATUS[0x40] STACK: SCB count = 50 Kernel NEXTQSCB = 15 Card NEXTQSCB = 20 QINFIFO entries: 20 6 8 25 48 5 46 27 26 2 1 Waiting Queue entries: Disconnected Queue entries: QOUTFIFO entries: Sequencer Free SCB List: 12 24 13 28 20 5 29 23 17 25 4 8 7 15 2 22 11 14 26 9 6 1 27 19 3 10 18 0 31 30 21 Sequencer SCB Info: 0 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 1 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 2 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 3 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 4 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 5 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 6 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 7 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 8 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 9 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 10 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 11 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 12 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 13 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 14 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 15 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 16 SCB_CONTROL[0x62] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0x17] 17 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 18 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 19 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 20 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 21 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 22 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 23 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 24 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 25 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 26 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 27 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 28 SCB_CONTROL[0xe2] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 29 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 30 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] 31 SCB_CONTROL[0xe0] SCB_SCSIID[0x7] SCB_LUN[0x0] SCB_TAG[0xff] Pending list: 1 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] 2 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] 26 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] 27 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] 46 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] 5 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] 48 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] 25 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] 8 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] 6 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] 20 SCB_CONTROL[0x62] SCB_SCSIID[0x7] SCB_LUN[0x0] 23 SCB_CONTROL[0x62] SCB_SCSIID[0x7] SCB_LUN[0x0] Kernel Free SCB list: 28 14 12 9 37 21 7 33 49 32 30 31 4 39 0 11 22 24 17 19 35 10 34 36 16 18 3 29 13 47 38 45 44 43 42 41 40 sg[0] - Addr 0x80db000 : Length 4096 sg[1] - Addr 0x7b5c000 : Length 4096 sg[2] - Addr 0x81bd000 : Length 4096 sg[3] - Addr 0x7b1e000 : Length 4096 (da0:ahc0:0:0:0): BDR message in message buffer (da0:ahc0:0:0:0): SCB 0
Re: buildkernel and gcc2
> On Thu, Mar 20, 2003 at 03:21:13AM +0000, RMH wrote: > > I have to note that currently it isn't really possible to compile > > -CURRENT by GCC 2.95.x in the way it has to be. Buildkernel is > > broken in several places by different means, however GCC 3.2.x > > passes them successfully, even with no warnings shown. > > Huh?? What do you mean "in the way it has to be"? We purposely upgraded > from GCC 2.95.x to 3.2.x and part of that upgrade gave us C99 features. Well, I probably had to say "in the way it could [should] be". I've passed through a list of C99 features, but only two things I've seen implemented in kernel: a) macros with a variable number of arguments; b) preprocessor arithmetic done in intmax_t/uintmax_t; Maybe I've missed a couple of extra ones, but anyway I suppose they don't make so much difference to put GCC2 into unsupported list. > > > Namely, first problem is in bsd.kern.mk, because of compiler flag > > -mno-align-long-strings, which is not supported by 2.95.x. Should > > be autodetected. > > The patch for doing this? Since the vast majority of 5-CURRENT's users > are using the stock 3.2.x compiler, making the kernel build with gcc > 2.95.x isn't going to be high on our list of things to do. However, this > doesn't prevent you from making a committable patch. It isn't a problem to export an extra variable and make it known to bsd.kern.mk; the question is, do we want GCC2 to be a supported compiler for -CURRENT or not? If not, all efforts to that way make no sense... > > > Second problem is periods in two macros of sys/eventhandler.h, > > that broke depend: > > > > #define EVENTHANDLER_FAST_INVOKE(name, ...) > > #define EVENTHANDLER_INVOKE(name, ...) > > > > Might be fixed in the way like: > > > > #define EVENTHANDLER_FAST_INVOKE(name) > > #define EVENTHANDLER_INVOKE(name, arg1, arg2, arg3) > > We can certainly put in a #ifdef detection on the GCC version. Please > submit a patch for this and the other nits you point out. Actually I've explained it all before. Those two macros with variable arguments have to be changed towards fixed arguments, __VA_ARGS__ should be replaced with some substitute (out of my present knowledge, so I used NULL), plus "%j" and [u]intmax_t. In other words, #ifdef detection isn't enough, we should decide are C99 features so important to break compatibility, or we can live without them. --- Regards, Rhett __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildkernel and gcc2
Hello gentlemen,
I have to note that currently it isn't really possible to compile
-CURRENT by GCC 2.95.x in the way it has to be. Buildkernel is
broken in several places by different means, however GCC 3.2.x
passes them successfully, even with no warnings shown.
Namely, first problem is in bsd.kern.mk, because of compiler flag
-mno-align-long-strings, which is not supported by 2.95.x. Should
be autodetected.
Second problem is periods in two macros of sys/eventhandler.h,
that broke depend:
#define EVENTHANDLER_FAST_INVOKE(name, ...)
#define EVENTHANDLER_INVOKE(name, ...)
Might be fixed in the way like:
#define EVENTHANDLER_FAST_INVOKE(name)
#define EVENTHANDLER_INVOKE(name, arg1, arg2, arg3)
This quick hack will help to pass depend, but unfortunately fail
later. Note that EVENTHANDLER_INVOKE is called with either 2 or
4 arguments from different places, so this should be taken into
account and fixed:
../../../kern/kern_shutdown.c:260: macro `EVENTHANDLER_INVOKE' used
with only 2 args
../../../kern/kern_shutdown.c:360: macro `EVENTHANDLER_INVOKE' used
with only 2 args
../../../kern/kern_shutdown.c:367: macro `EVENTHANDLER_INVOKE' used
with only 2 args
../../../kern/subr_power.c:105: macro `EVENTHANDLER_INVOKE' used
with only 2 args
../../../vm/vm_pageout.c:687: macro `EVENTHANDLER_INVOKE' used
with only 2 args
NULL arguments may be added.
Third problem is in asm code of i386 loader:
gcc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -march=pentiumpro -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I-
-I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica
-I../../../contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common
-mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../i386/i386/locore.s
{standard input}: Assembler messages:
{standard input}:1752: Warning: rest of line ignored; first ignored character
is `t'
{standard input}:1754: Error: unknown pseudo-op: `.'
{standard input}:1877: Error: missing ')'
{standard input}:1877: Error: missing ')'
{standard input}:1877: Error: junk `tmpstk)- 0xc000)' after expression
*** Error code 1
Not funny.
[...]
1752: .globl . tmpstk
1753: .space 0x2000
1754:. tmpstk :
[...]
1877: movl$(( . tmpstk )- 0xc000 ) ,%esp
[...]
Instead of:
[...]
1752: .globl .tmpstk
1753: .space 0x2000
1754:.tmpstk:
[...]
1877: movl$(( .tmpstk )- 0xc000 ) ,%esp
[...]
Fourth; isn't critical, but has to be fixed too:
../../../dev/drm/mga_dma.c: In function `mga_do_init_dma':
../../../dev/drm/mga_dma.c:522: syntax error before `)'
../../../dev/drm/mga_dma.c:532: syntax error before `)'
../../../dev/drm/mga_dma.c:540: syntax error before `)'
../../../dev/drm/mga_dma.c:548: syntax error before `)'
../../../dev/drm/mga_dma.c:556: syntax error before `)'
../../../dev/drm/mga_dma.c:564: syntax error before `)'
../../../dev/drm/mga_dma.c:572: syntax error before `)'
../../../dev/drm/mga_dma.c:590: syntax error before `)'
../../../dev/drm/mga_dma.c:599: syntax error before `)'
../../../dev/drm/mga_dma.c:608: syntax error before `)'
../../../dev/drm/mga_dma.c:656: syntax error before `)'
../../../dev/drm/drm_context.h: In function `mga_context_switch':
../../../dev/drm/drm_context.h:239: syntax error before `)'
../../../dev/drm/drm_context.h: In function `mga_context_switch_complete':
../../../dev/drm/drm_context.h:270: syntax error before `)'
../../../dev/drm/drm_drv.h: In function `mga_init':
../../../dev/drm/drm_drv.h:782: syntax error before `)'
../../../dev/drm/drm_drv.h:806: syntax error before `)'
../../../dev/drm/drm_drv.h: In function `mga_unlock':
../../../dev/drm/drm_drv.h:1407: syntax error before `)'
*** Error code 1
Broken macro DRM_ERROR. As for now, it's safe to just comment it out.
Fifth; these have probably nothing to do with a particular compiler,
just bugs.
cc1: warnings being treated as errors
../../../dev/pci/pci.c: In function `pci_delete_resource':
../../../dev/pci/pci.c:1341: warning: implicit declaration of function
`rman_get_device'
../../../dev/pci/pci.c:1341: warning: comparison between pointer and integer
--- pci.c.old Wed Feb 19 07:47:09 2003
+++ pci.c Tue Mar 19 18:42:41 2003
@@ -1338,7 +1338,7 @@
rle = resource_list_find(rl, type, rid);
if (rle) {
if (rle->res) {
- if (rman_get_device(rle->res) != dev ||
+ if (rle->res->r_dev != dev ||
rman_get_flags(rle->res) & RF_ACTIVE) {
device_printf(dev, "delete_resource: "
"Resource still owned by child, oops. "
../../../dev/pci/pci_user.c:81: `MAJOR_AUTO' undeclared here (not in a
function)
../../../dev/pci/pci_user.c:81: initializer element is not constant
../../../dev/pci/pci_user.c:81: (near initialization for `pcicdev.d_
