Re: FreeBSD-4.0 on SMP
Hi,
I have a 4-processor machine but I want to configure FreeBSD-4.0
to only use 1 of the processors for some tests. In addition I want the
local APIC to be enabled. It seems currently that the APIC is only enabled
when the kernel is compiled with the SMP option. However, when I specify
NCPU to be 1, the kernel panics. So the question is - is there a way to
just use one processor and still keep the APIC enabled ?
- Mohit
Try again with the following patch,
Index: i386/mp_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v
retrieving revision 1.112
diff -u -r1.112 mp_machdep.c
--- i386/mp_machdep.c 1999/11/27 12:32:20 1.112
+++ i386/mp_machdep.c 2000/01/05 08:28:40
@@ -1097,7 +1097,7 @@
processor_entry(proc_entry_ptr entry, int cpu)
{
/* check for usability */
- if ((cpu = NCPU) || !(entry-cpu_flags PROCENTRY_FLAG_EN))
+ if (!(entry-cpu_flags PROCENTRY_FLAG_EN))
return 0;
/* check for BSP flag */
@@ -1109,11 +1109,13 @@
}
/* add another AP to list, if less than max number of CPUs */
- else {
+ else if (cpu NCPU) {
CPU_TO_ID(cpu) = entry-apic_id;
ID_TO_CPU(entry-apic_id) = cpu;
return 1;
}
+
+ return 0;
}
Index: include/mpapic.h
===
RCS file: /home/ncvs/src/sys/i386/include/mpapic.h,v
retrieving revision 1.12
diff -u -r1.12 mpapic.h
--- include/mpapic.h1999/08/28 00:44:19 1.12
+++ include/mpapic.h2000/01/05 08:24:58
@@ -98,6 +98,8 @@
static __inline int
all_but_self_ipi(int vector)
{
+ if (mp_ncpus = 1)
+ return 0;
return apic_ipi(APIC_DEST_ALLESELF, vector, APIC_DELMODE_FIXED);
}
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
In [EMAIL PROTECTED], Gergely EGERVARY wrote: I have just upgraded my system to -current w/egcs 2.95.2 and I have several problems with it, especially when using optimizations (-O2 and such) When your code breaks when using -O2 or higher, don't do that, use just -O! Almost all examples I've seen where people claimed newer gcc's broke their code are triggered by unclean C code that isn't strictly ANSI C conformant (also see the other thread about ieeefp and floating point exceptions). As far as I understand, the gcc people try to keep the -O option compatible in a way that it doesn't break code that didn't break in earlier versions of gcc. This is exactly the option you need, it's a service for you and you should use it unless you are absolutely sure your code is valid. There are examples of -O2 or higher breaking valid code, but they are much less common than implied. And such issues were in 2.7.x was well, that's the reason the base system is compiled with -O. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: undefined reference
Sascha Schumann wrote:
Hi,
I've written a new driver for ppbus (yes, I know that
newppbus exists). I've added one line to conf/files, added
"device pcf0" to my kernel configuration file, config'ured
the kernel, and ran make depend all. The driver compiles
cleanly, but then the linker complains about:
isa_compat.o(.data+0xc): undefined reference to `pcfdriver'
pcfdriver is declared in pcf.c:
static struct ppb_driver pcfdriver = {
pcfprobe, pcfattach, PCF_NAME
};
DATA_SET(ppbdriver_set, pcfdriver);
When I removed the static declarator test-wise, the linker
complained about dupe symbols. Is it really impossible to make
this work?
There is another driver called 'pcf' - you'll have to use a different name.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: undefined reference
On Wed, Jan 05, 2000 at 06:15:25PM +0800, Peter Wemm wrote: [..] There is another driver called 'pcf' - you'll have to use a different name. Thanks! I forgot to check i386/files/conf. Now, on to debugging. -- Regards, Sascha Schumann Consultant To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB vs. parallel port
Nick Hibma wrote: By the way, at the moment it is better to have a UHCI controller on your motherboard. Allthough the OHCI controller is much smarter and more efficient, support for it is not as stable as the support for UHCI controllers. Sounds like UHCI = IDE, OHCI = SCSI ? (only 1/2 :-). Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
P.S. Actually, although Martin Cracauer's suggested replacement for the existing Mozilla code is certainly better than what Mozilla is using now, it may perhaps need to be slightly augmented with an additional check to see if the value of `d' is a NaN prior to per- forming the range check. But I'm not even sure about that. I'd have to go and dredge my copy of IEEE 754 out of my files again to find out what the results of = and = are in cases where one of the operands is a NaN. I think however that those operations are perhaps required to return False in that case, in which case Martin Cracauer's suggested Mozilla replacement code is just fine as it is. And in any case, that is all a moot point anyway if it is known in advance that `d' will not be a NaN. I don't believe the C89 standard doesn't have a way to test for NaN - so, if we're talking portability here - you can't test for NaN. I think C99 does have some library functions to do tests for NaN and Inf. This is interesting because the 390 HFP format doesn't have NaN or Inf. Why would that matter to Mozilla - well, there's a LINUX port now for the mainframe and Mozilla might want to run there. [I don't know if that port is using the old-style HFP format or the new-style IEEE format.] - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
In [EMAIL PROTECTED], Ronald F. Guilmette wrote:
The alternative to this hack is a normal range check...
...
static inline int cra_is_int(const double d, int *const i)
{
if (d = (double)INT_MAX d = (double)INT_MIN) {
*i = (int)d;
return 1;
} else
return 0;
}
The function shown above is indeed the correct solution/approach for
what Mozilla is trying to do here, for the reasons cited above.
But having said that, I also want to reiterate what I said before...
Yes, the existing Mozilla code should be fixed to perform the range
check in the manner that Martin Cracauer [EMAIL PROTECTED] has
shown above. However the can-of-worms opened up by this whole
thread/discussion has revealed *two* bugs... one in the Mozilla
code (which Martin Cracauer [EMAIL PROTECTED] has correctly
described, diagnosed, and provided a solution for) and also, there
is still that annoying little deviation from the IEEE FP standard
that results from FreeBSD's failure to disable all IEEE FP traps
upon entry to main.
_Both_ bugs should be fixed.
As I said in the other message: This case is not covered by the IEEE
exceptions that may be disabled.
This case is a conversion of double - int, it is not covered by
ieee754, but by ANSI C. And the ANSI C standard has its own paragraph
for exactly this case and its own sentense that if the the double is
out of range the behaviour is undefined.
Really, what else do you want? The issue would be different if we'd
talk about float devision by zero or a pure FP overflow, but we don't.
We don't talk floating point arthmetic here, we talk floating point
conversion and a case that is directly covered by ANSI C.
P.S. Actually, although Martin Cracauer's suggested replacement for
the existing Mozilla code is certainly better than what Mozilla is
using now, it may perhaps need to be slightly augmented with an
additional check to see if the value of `d' is a NaN prior to per-
forming the range check. But I'm not even sure about that. I'd
have to go and dredge my copy of IEEE 754 out of my files again to
find out what the results of = and = are in cases where one of
the operands is a NaN. I think however that those operations are
perhaps required to return False in that case, in which case Martin
Cracauer's suggested Mozilla replacement code is just fine as it is.
I test of = and = against NaN always returns nil.
Martin
--
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
Martin Cracauer [EMAIL PROTECTED] wrote in list.freebsd-hackers: You will not be able to use all features of FreeBSD, of course. Calling functions that take long long arguments doesn't work, these should be masked out when compiling struct ansi code. It may get painful quickly, as such basic things like seek() are amoung them. ``long long'' is part of the C9x standard (or whatever it is called now, I'm not an expert). If TenDRA (or lcc) supports the latest C standard, then there should be no problem. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
In message [EMAIL PROTECTED], Martin Cracauer [EMAIL PROTECTED] wrote: Others already said that replacing the system compiler will be difficult. However, you should be able to use any FreeBSD include file that is supposed to be used by userlevel code with any ANSI C conforming compiler. People like Bruce Evans once took great care to guarantee that. It seems this has gone under the wheel by less careful committers since around 3.0, but the goal is nontheless to keep this capability. If you have examples where it breaks, send them to me, please. Well, if you are interested in doing some *serious* QA and ANSI/ISO conformance testing on the system include files... For hours of enjoyment, try running the following simple script: --- #!/bin/csh cd /usr/include set hfiles=(`find * -follow \( -name g++ -prune \) -o \( -type f -name \*.h -print \)`) cd /tmp foreach hfile ($hfiles) echo '--- Checking '$hfile echo '#include '$hfile'' includer.c gcc -Wall -pedantic-errors -Wstrict-prototypes -c includer.c end --- NOTES: [1] In an Ideal Universe, the above script should run to completion while yielding ZERO errors and also ZERO warnings from the compiler. [2] We do not live in an Ideal Universe. [3] The ANSI C standard, at least, contains the requirement that each individual system include file specified by that standard should be usable all by itself, without the programmer being required to explicitly include any OTHER system include files, prior to the one he/she is actually interested in using. This is, I believe, a Good Thing. However few are the systems where this sort of elegance pervades ALL of the available system include files, which is a pity, because if this `feature' were in fact pervasive, it would make QA'ing the whole complete set of system include files much easier. [4] Even if one does not accept the advisability of having each and every system include file be ``includable'' all on its own, it should, in theory, still be possible to work out a proper partial ordering of the entire set of system include files, taking into account which ones must be included before which other ones. Using that partial order then, it should be trivially possible to construct a single .c file which just includes each and every one of the system include files in an order consistant with the partial ordering imposed by their interdependences, and THAT file should be able to be compiled (with the gcc command line shown in the script above) with zero errors and warnings. (I will volunteer to determine/document the partial ordering if anyone else is willing to then get in and fix all of the header files bugs which will be revealed by compiling the hypothesized .c file, but I won't waste my time doing this if nobody gives a damn.) [5] Taking the ordered list of #include statements generated as per [4] above, another potentially useful QA test is to attempt to compile a .c file containing that ordered set of #include's followed by another copy of that same set. This will flush out all cases of system include files that cannot be included twice in a given compilation without incuring `multiple definition' errors, e.g. isofs/cd9660/iso.h. Once again, I use the ANSI/ISO C standard as my guide - It requires that each and every system include file which *it* mandates must be capable of being included twice into the same single compilation WITHOUT incuring compile-time errors. [6] For extra credit, take the script shown above and replace "gcc" with "g++' and then re-run. In this case also, neither errors nor warnings should ensue. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
Warner Losh writes: : This is explained in more detail in section 7.1.1.4 of the August 3, : 1998 committee draft: Sorry to followup on my own message, but this is in section 7.1.2.4. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CD-RW long filenames/rw filesystem.
it, is grab a bunch of stuff you want to backup/record and use mkisofs and Use mkhybrid instead of mkisofs. It allows long filenames. the CD-RW and then delete it later if you want to. Would it be possible, or even feasible, to implement something like this in FreeBSD? Probably, but is there really much demand for this in a server OS? You can blank the CD-RW medium, with wormcontrol... - marius To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
syscons: SC_MOUSE_CHAR value rationale
Is there any _particular_ reason why this is #define'd to (0xd0) in /sys/dev/syscons/syscons.c? Nearly everyone who wants to set up their national locale needs to recompile the kernel, since some important characters are hidden under mouse cursor. I sure that at least these are affected: (from /usr/share/syscons/font) iso-8859-2-8x16.fnt iso02-8x8.fnt koi8-r-8x8.fnt iso02-8x14.fnt koi8-r-8x14.fnt koi8-rb-8x16.fnt iso02-8x16.fnt koi8-r-8x16.fnt koi8-rc-8x16.fnt Will changing it to 0x08 break anything? -- Marcin Cieslak // [EMAIL PROTECTED] - SYSTEM Internet Provider http://www.system.pl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cdrecord Pioneer DVR-S201?
On Thu, Jan 06, 2000 at 00:39:35 -0500, John W. DeBoskey wrote: Hi, The subject pretty much asks the question. I'm looking for anyone who has used or tried to use the new Pioneer DVR-S201 2nd Generation 4.7GB DVD-Writer on FreeBSD/cdrecord. I've looked at the current cdrecord support page and I don't see this drive listed. I've also search deja for any references to this drive and cdrecord and could not find any. From perusing the cdrecord pages, it looks like it should be possible to simply create a very large iso9660 filesystem and then burn it... Basically, a really big cdrom. I'm currently only interested in disk-at-once writing. The main question is probably what interface does the drive use? Does it use the same sort of write/fixate process that CD-R's use? DVD-RAM drives use a standard read/write interface, but they're more like a standard optical drive in interface. My guess is that it acts kinda like a CD-R, but it's hard to say without specs of some sort. I'd suggest that you contact Joerg Schilling [EMAIL PROTECTED] and see what he has to say about it. He may ask for at least a loner drive and specs from Pioneer in order to support it. If it does use the standard read/write interface, and not a CD-R type interface, let me know, and I can probably get you up and running. BTW, the suggested retail price is amazingly high -- $5400. I suppose it could be to discourage people from copying movies, or it could just be because it's the only DVD-R drive on the market. (is it?) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AIO was Re: Kernel threads
With respect to AIO... we run a data server which multiplexes
on the select() function, and uses AIO to do all it's I/O. This
has been a very stable system.
system : 4.0-19990827-SNAP
start time : 1999/12/24 11:14:44
up time (days hh:mm:ss): 12 13:32:53
Current/Max/Total connections: 0 / 2 / 244
Total requests:6228
Total aio bytes written: 573499989 (546.9M)
Current/Max stat daemons: 0 / 1
Current/Max Queued for stat: 0 / 0
Current/Maxcp daemons: 0 / 2
Current/Max Queued for cp: 0 / 0
Current/Max aio_write daemons: 0 / 2
Current/Max Queued for write: 0 / 0
Current/Max/ telnets: 1 / 1
The above is a sample of the stats kept by the daemon. The numbers
are very low due to the holidays. Basically, this thing hands raw data
to applications running on NT, where the data is kept on Network
Appliance fileservers attached to FreeBSD boxes. Direct CIFS attachment
to the data from the NT system does not come close to the through-put
we attain using this process.
I would very much like to see these patches applied also. At a
minimum, it means that the following type of code loop can be
removed since we would know immediately which aio operation completed.
The marked loop below becomes relatively hot as the max number of
outstanding aio processes is increased and the number of simultanious
hits on the server grows.
/*--+
| ST_AIO |
| |
| A task in the ST_AIO state means that one of our |
| aio_writes has finished. we will loop thru all |
| outstanding aio_writes to see which one completed. |
| |
*--*/
case ST_AIO:
... code deleled ...
/*-+
| we know we have a completed process. let's find out |
| which one it is.|
*-*/
--- for (j=0; jMAX_WRITERS; j++) {
---if (aio[j].task aio_error(aio[j].iocb) != EINPROGRESS)
--- break;
}
... code deleted ...
/*-+
| Get the actual return code, check length, decrement |
| active count, send message |
+-*/
t = aio[j].task;
rc = aio_return(aio[j].iocb);
Since we are getting ready to bring this process forward and integrate
the new signal handling code, now would be a great time for these
patches to be applied and have some heavy testing done on them.
Thanks!
John
In article [EMAIL PROTECTED] you
write:
The best fix I've thought of thus far (other than async I/O, which I
understand isn't ready for prime time) would be to have a number of kernel
Speaking of AIO, which I would really like to use if possible, how
actively maintained is it? The copyright on vfs_aio.c is 1997, suggesting
to me that John Dyson has moved onto other things.
Yep, that's right.
Quite recently Christopher Sedore has done some work on vfs_aio.c, to
make it work better with sockets and he also added a very useful
aio_waitcomplete system call which returns the first aiocb (AIO control
block) from the 'completed' queue. I would be nice if these patches
could be added to FreeBSD-current.
About AIO not ready for prime time: I did some experiments recently by
throwing up to 256 aio requests on one fd (a raw disk device) into the
system and it worked without any problems. The only time I got a panic
was when (I think) I had a negative aiocb-offset (I still need to
reproduce this). See http://www.iae.nl/users/devet/freebsd/aio/ for my
aiotest.c program.
I'm thinking about using AIO for a faster Squid file system by using raw
disk devices instead of UFS which has too much overhead for Squid.
Arjan
- --
Arjan de Vet, Eindhoven, The Netherlands [EMAIL PROTECTED]
URL: http://www.iae.nl/users/devet/ for PGP key: finger [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of
Re: AIO was Re: Kernel threads
This is very interesting data and I was just wondering about the actual state of functionality in our AIO code just the other day, oddly enough. Does anyone have a PR# for the mentioned patches? - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
