Re: smallest piece of hardware that runs *BSD?
Bernd Walter [EMAIL PROTECTED] writes: On Sat, Oct 11, 2003 at 03:06:18PM +1000, John Birrell wrote: Here's one the size of a credit card: http://www.compulab.co.il/586core.htm. It's a lot bigger than a 'bump in a cable', but it runs FreeBSD. Leaves the question how much of the data on that page is correct. The elan chip is 486 class as we all know from soekris systems. From www.amd.com: The Élan[tm] SC520 microcontroller combines a 32-bit, low-voltage Am5x86 CPU with a complete set of integrated peripherals suitable for both real-time and PC/AT-compatible embedded applications. The device also features a 32-bit PCI bus, a high-performance, 32-bit SDRAM interface and a full-featured, high-performance in-circuit emulation capability, known as the AMDebug[tm] technology. so it's not incorrect, though they might get in trouble with Intel over the use of the Pentium trademark in promotional material for a product based on an AMD microcontroller. Regarding the computer in an ethernet jack devices mentioned elsewhere in this thread: good luck trying to run FreeBSD on a 16-bit microcontroller with no MMU or FPU, 256 kB SRAM and 512 kB DRAM... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: smallest piece of hardware that runs *BSD?
On Sun, Oct 12, 2003 at 01:19:44PM +0200, Dag-Erling Smørgrav wrote: Bernd Walter [EMAIL PROTECTED] writes: On Sat, Oct 11, 2003 at 03:06:18PM +1000, John Birrell wrote: Here's one the size of a credit card: http://www.compulab.co.il/586core.htm. It's a lot bigger than a 'bump in a cable', but it runs FreeBSD. Leaves the question how much of the data on that page is correct. The elan chip is 486 class as we all know from soekris systems. From www.amd.com: The Élan[tm] SC520 microcontroller combines a 32-bit, low-voltage Am5x86 CPU with a complete set of integrated peripherals suitable for both real-time and PC/AT-compatible embedded applications. The device also features a 32-bit PCI bus, a high-performance, 32-bit SDRAM interface and a full-featured, high-performance in-circuit emulation capability, known as the AMDebug[tm] technology. Am5x86 != 586 class. This is what FreeBSD thinks about the SC520: CPU: AMD Enhanced Am486DX4/Am5x86 Write-Back (486-class CPU) Origin = AuthenticAMD Id = 0x494 Stepping = 4 Features=0x1FPU -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
real vs. avail memory
I've gotten used to the fact that there is a small discrepancy between real and available memory, but I was surprised to see the following in dmesg on a new P4 system: real memory = 1073676288 (1023 MB) avail memory = 1037799424 (989 MB) That's a full 40 MB difference... where does that memory go? is it used for page maps or something like that? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: real vs. avail memory
On Sun, 12 Oct 2003, Dag-Erling [iso-8859-1] Smørgrav wrote: dmesg on a new P4 system: real memory = 1073676288 (1023 MB) avail memory = 1037799424 (989 MB) That's a full 40 MB difference... where does that memory go? is it used for page maps or something like that? 34M, as I figure it. Is this an Intel motherboard, or other motherboard with integrated video adapter? That could be shared memory used for the video. -Warren Block * Rapid City, South Dakota USA ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: smallest piece of hardware that runs *BSD?
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : Bernd Walter [EMAIL PROTECTED] writes: : On Sat, Oct 11, 2003 at 03:06:18PM +1000, John Birrell wrote: : Here's one the size of a credit card: http://www.compulab.co.il/586core.htm. : It's a lot bigger than a 'bump in a cable', but it runs FreeBSD. : Leaves the question how much of the data on that page is correct. : The elan chip is 486 class as we all know from soekris systems. : : From www.amd.com: : : The Élan[tm] SC520 microcontroller combines a 32-bit, low-voltage : Am5x86 CPU with a complete set of integrated peripherals suitable : for both real-time and PC/AT-compatible embedded applications. The : device also features a 32-bit PCI bus, a high-performance, 32-bit : SDRAM interface and a full-featured, high-performance in-circuit : emulation capability, known as the AMDebug[tm] technology. : : so it's not incorrect, though they might get in trouble with Intel : over the use of the Pentium trademark in promotional material for a : product based on an AMD microcontroller. I'm not sure what you are saying here. However the Am5x86 core is a 486 class machine... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
md5(1) exit code
Or rather, lack thereof. I was rather astonished to find that `md5 /nonexistant` printed an error message but still returned an exit code of zero; this is, of course, due to the use of warn() instead of err() in response to a receiving a NULL pointer returned from MD5File(3). Is there any reason for this behaviour? Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: md5(1) exit code
On 2003-10-12 16:50 +0100, Colin Percival [EMAIL PROTECTED] wrote:
Or rather, lack thereof. I was rather astonished to find that `md5
/nonexistant` printed an error message but still returned an exit code of
zero; this is, of course, due to the use of warn() instead of err() in
response to a receiving a NULL pointer returned from MD5File(3).
Is there any reason for this behaviour?
Don't think so, and I fixed it many years ago (much earlier
than the dates in the diff seem to indicate) on my system.
Patch attached ...
Regards, STefan
PS: Guess I should just commit this change to -current ...
Index: md5.1
===
RCS file: /usr/cvs/src/sbin/md5/md5.1,v
retrieving revision 1.18
diff -u -r1.18 md5.1
--- md5.1 19 Apr 2002 23:05:25 - 1.18
+++ md5.1 21 Jun 2002 12:53:47 -
@@ -67,6 +67,10 @@
.It Fl x
Run a built-in test script.
.El
+.Sh DIAGNOSTICS
+The
+.Nm
+program exits 0 on success, and 1 if at least one of the input files could not be
read.
.Sh SEE ALSO
.Xr cksum 1
.Rs
Index: md5.c
===
RCS file: /usr/cvs/src/sbin/md5/md5.c,v
retrieving revision 1.30
diff -u -r1.30 md5.c
--- md5.c 3 May 2003 18:41:58 - 1.30
+++ md5.c 4 May 2003 13:11:55 -
@@ -62,7 +62,9 @@
int ch;
char *p;
charbuf[33];
+ int failed;
+ failed = 0;
while ((ch = getopt(argc, argv, pqrs:tx)) != -1)
switch (ch) {
case 'p':
@@ -93,19 +95,24 @@
if (*argv) {
do {
p = MD5File(*argv, buf);
- if (!p)
+ if (!p) {
warn(%s, *argv);
- else
+ failed++;
+ } else {
if (qflag)
printf(%s\n, p);
else if (rflag)
printf(%s %s\n, p, *argv);
else
printf(MD5 (%s) = %s\n, *argv, p);
+ }
} while (*++argv);
} else if (!sflag (optind == 1 || qflag || rflag))
MDFilter(0);
+ if (failed != 0)
+ return (1);
+
return (0);
}
/*
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
return-rst does not work for ipv6 in ipfilter
Hi guys, The 'return-rst' option in ipfilter does not work for ipv6. I sent a problem report and just in case decided to send this patch here too. That option saves a lot of headache and it would be very nice to have it work properly. The patch was originally written by Peter Postma. I edited it a little so it can be applied without problems. I am not really a code guru, so if someone could review this patch, it would be great! Thanks in advance, Andrew Konstantinov --- ip_fil.c.orig Fri Dec 6 12:45:45 2002 +++ ip_fil.cTue Mar 25 17:05:09 2003 @@ -1937,24 +1937,24 @@ struct route_in6 ip6route; struct sockaddr_in6 *dst6; struct route_in6 *ro; - struct ifnet *ifp; + struct ifnet *ifp = (fdp != NULL) ? fdp-fd_ifp : fin-fin_ifp; frentry_t *fr; #if defined(OpenBSD) (OpenBSD = 200211) struct route_in6 *ro_pmtu = NULL; struct in6_addr finaldst; - ip6_t *ip6; #endif + ip6_t *ip6; u_long mtu; int error; - ifp = NULL; ro = ip6route; + ip6 = mtod(m0, struct ip6_t *); fr = fin-fin_fr; bzero((caddr_t)ro, sizeof(*ro)); dst6 = (struct sockaddr_in6 *)ro-ro_dst; dst6-sin6_family = AF_INET6; dst6-sin6_len = sizeof(struct sockaddr_in6); - dst6-sin6_addr = fin-fin_fi.fi_src.in6; + dst6-sin6_addr = ip6-ip6_dst; if (fdp != NULL) ifp = fdp-fd_ifp; pgp0.pgp Description: PGP signature
Re: real vs. avail memory
Warren Block [EMAIL PROTECTED] writes: On Sun, 12 Oct 2003, Dag-Erling [iso-8859-1] Smørgrav wrote: That's a full 40 MB difference... where does that memory go? is it used for page maps or something like that? 34M, as I figure it. Is this an Intel motherboard, or other motherboard with integrated video adapter? That could be shared memory used for the video. It is a Gigabyte motherboard with an Intel ICH4 chipset, but it has no onboard video. I have an ATI Radeon 7500 with 128 MB in the AGP slot. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Determining CPU features / cache organization from userland
All, I came up with the attached text file today to summarize some of my findings, after looking at various open source trees to see how they handle run-time cache geometry detection. Many will find it ironic that i386 is the easiest platform to deal with. [ Andrew: Perhaps you can shed some light on how the necessary information can be gathered on Alpha? My search was incomplete and I could not find a reliable source for DEC's development manuals. ] Jeff Roberson suggested I adopt NetBSD's API, however, on further examination it's clear that NetBSD's approach isn't consistent across all platforms. Darwin takes a similar approach, but it is perhaps too PowerPC-centric. sysctl is a good interface for retrieving this information as it doesn't change during the lifetime of the kernel, and it is small. sysctl is already invoked from within libc to retrieve information in this way. glibc's approach to dealing with situations where knowledge of the cache line size is needed is a bit fractious - it retrieves the information from an 'aux vector' passed to glibc at startup. I think threading libraries should seriously consider becoming consumers of the API once it's finalized. Mutex alignment on cache line boundaries is desirable for userland applications too. However, phk malloc would need to be changed in order to support this specific form of aligned allocation. Perhaps a separate pool or zone could be used for this kind of allocation? This becomes more important and timely when one considers the I/O alignment restrictions we've encountered. Some applications may need to align their buffers on arbitrary boundaries to suit devices, too. BMS all --- NetBSD cache information API(s) are not consistent across platforms. alpha - Cache discovery? Static. 21064, 21064A, 21066, 21066A, 21164 all have line sizes of 32-bytes. The 21264 has a 64-byte line size. 21364: L1 split, 64KB each, 2-way set-associative, Virtual caches can be implemented using PALcode, but this is probably more of a curiosity than anything else. ia64 Cache discovery? Call PAL_CACHE_INFO, I think. No documentation on how to do this at this time. I have emailed [EMAIL PROTECTED] asking for advice. i386 pc98 amd64 --- Cache discovery? CPUID. Earlier chips which don't support it probably don't have a cache, or aren't worth supporting. General rule for x86: split L1, unified L2, optional unified L3. General rule for Intel P5: 2-way, 32 bytes/line General rule for Intel MMX and up: 4-way, 32 bytes/line PPro doesn't have L3. The newer cores have different cache geometry. powerpc --- Cache line discovery? Static. Many core variants. I have not seen any runtime code for this. The POWER clcs instruction is obsolete. OpenDarwin assumes 32-bytes. It has hooks for discovering the cache geometry at runtime but these are not used. NetBSD statically initializes this information according to the discovered CPU model in use, which is the way to go. NetBSD tells uvm to recolor the page queues if required. Linux uses static #define's from IBM people, except in the case of ppc64, which is strikingly similar to the OpenDarwin code except it actually talks to the open firmware. Open Firmware on CHRP should however provide the following for each cpu device node configured in the system: i-cache-size i-cache-sets i-cache-block-size d-cache-size d-cache-sets d-cache-block-size tlb-size tlb-sets l2-cache All are integers except for l2-cache which is the address of an l2-cache device node if the system found one. mips The NetBSD MIPS code for dealing with cache geometry was recently updated. MIPS caches may be split/unified at L1/L2 and unified at L3. Cache detection code is quite voluminous. Swipe NetBSD's if FreeBSD/mips ever kicks off. Many, many core variants. sparc64 --- Cache line discovery? Performed by Open Firmware. Open Firmware property names used are ever so slightly different from Apple's. icache-size icache-line-size icache-associativity dcache-size dcache-line-size dcache-associativity ecache-size ecache-line-size ecache-associativity Already handled within cache.c, but assembly stubs *expect* this information in a certain format. Specifically they need to see the data cache/instruction cache sizes and line sizes. General rule: Split L1, Unified L2. Cores: Spitfire/Blackbird/Cheetah ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
